Enable javascript in your browser for better experience. Need to know to enable it? Go here.

Técnicas

Adoptar ?

  • Para medir el rendimiento en la entrega de software, cada vez más organizaciones recurren a las cuatro métricas clave definidas por el programa DORA research : el tiempo de espera de un cambio, la frecuencia de despliegue, el tiempo medio de restauración (MTTR) y tasa de fallo de cambio. Esta investigación y sus análisis estadísticos han demostrado una clara relación entre el alto rendimiento de entrega y estas métricas, lo cual proporciona un magnífico indicador de cómo un equipo, o incluso toda una organización, lo está haciendo.

    Aún somos partidarios de estas métricas, sin embargo hemos aprendido algunas lecciones desde la primera vez que empezamos a monitorearlas. Cada vez vemos más enfoques de medición erróneos en herramientas que ayudan a los equipos a medir estas métricas basándose puramente en sus pipelines de entrega continua (CD). En particular, cuando se trata de métricas de estabilidad (MTTR y tasa de fallo de cambio), únicamente los datos recogidos de las pipelines de entrega continua (CD)no proveen suficiente información para determinar qué es un fallo en el despliegue con un impacto real en el usuario. Las métricas de estabilidad sólo tienen sentido si incluyen datos sobre los incidentes reales que degradan el servicio para los usuarios.

    Y como todas las métricas, recomendamos tener siempre presente el objetivo principal que está detrás de la medición y usarlas para reflexionar y aprender. Por ejemplo, antes de estar semanas construyendo sofisticadas herramientas con tableros, considere incluir y revisar regularmente el DORA quick check en las retrospectivas del equipo. Esto da al equipo la oportunidad de reflexionar en que capabilities podrían trabajar para mejorar sus métricas, lo que puede ser mucho más eficaz que las herramientas que ya están hechas y sobre-detalladas.

  • Seguimos viendo a los equipos de producto de ingeniería de plataformas como una opción sensata, con la idea principal de que no son más que otro equipo de producto, aunque centrado en los clientes internos de la plataforma. Por lo tanto, es fundamental tener clientes y productos claramente definidos y utilizar las mismas disciplinas de ingeniería y formas de trabajo que cualquier otro equipo de producto (centrado en el exterior); los equipos de plataforma no son especiales en este sentido. Advertimos que no hay que limitarse a cambiar el nombre de los equipos internos existentes por el de "equipos de plataforma" sin cambiar los métodos de trabajo ni las estructuras organizativas. Seguimos siendo grandes seguidores del uso de los conceptos de Team Topologies cuando pensamos en la mejor manera de organizar los equipos de plataforma. Consideramos que los equipos de productos de ingeniería de plataformas son un enfoque estándar y un importante facilitador de la TI de alto rendimiento.

  • Seguimos sabiendo de empresas que descubren que su seguridad ha sido gravemente comprometida debido a una dependencia excesiva del perímetro de red "seguro". Una vez que se viola este perímetro externo, los sistemas internos demuestran estar mal protegidos y los atacantes pueden implementar rápida y fácilmente herramientas de extracción de datos automatizadas y ataques de ransomware que, con demasiada frecuencia, permanecen sin ser detectados durante largos períodos. Esto nos lleva a recomendar la arquitectura de confianza cero (ZTA) como un estándar sensato.

    ZTA es un cambio de paradigma en la arquitectura y la estrategia de seguridad. Se basa en la suposición de que un perímetro de red ya no es representativo de un límite seguro y que no se debe otorgar confianza implícita a los usuarios o servicios basándose únicamente en su ubicación física o de red. La cantidad de recursos, herramientas y plataformas disponibles para implementar aspectos de ZTA sigue creciendo e incluye la imposición de políticas como código basadas en los principios de privilegio mínimo y lo más granular posible y en el monitoreo continuo y la mitigación automatizada de amenazas; usando una malla de servicios para imponer el control de seguridad entre aplicación-servicio y servicio-servicio; implementando atestación binaria para verificar el origen de los binarios; e incluyendo enclaves seguros además del cifrado tradicional para hacer cumplir los tres pilares de la seguridad de los datos: en tránsito, en reposo y en memoria. Para más información, consulte la publicación NIST ZTA y el artículo de Google sobre BeyondProd.

Probar ?

  • Aunque ha existido por un tiempo, estamos viendo cada vez más casos donde el usar la especificación CBOR para el intercambio de datos, tiene sentido, especialmente en entornos que contienen múltiples tipos de aplicaciones que se comunican entre sí: servicio a servicio, navegador a servicio, etc. Algo que hemos encontrado útil con Borer — una implementación a Scala de un codificador/decodificador CBOR — es la capacidad de los clientes para negociar el contenido entre la representación binaria y el antiguo formato JSON. Es muy útil tener una versión de texto visible en un navegador, así como el formato binario conciso. Prevemos que los protocolos bilingües CBOR/JSON cobrarán popularidad con el aumento continuo de IoT, Edge Computing y otras situaciones en las que el entorno es muy restringido.

  • Cada vez más, vemos una falta de coincidencia entre lo que las organizaciones basadas en datos quieren lograr y lo que permiten las arquitecturas de datos y las estructuras organizativas actuales. Las organizaciones quieren integrar la toma de decisiones basada en datos, machine learning y la analítica en muchos aspectos de sus productos y servicios y en cómo operan internamente; esencialmente, quieren aumentar todos los aspectos de su panorama operativo con inteligencia basada en datos. Sin embargo, todavía nos queda mucho camino por recorrer antes de que podamos integrar datos analíticos, acceder a ellos y cómo se administran en los dominios y operaciones comerciales. Hoy en día, todos los aspectos de la gestión de datos analíticos se externalizan fuera de los dominios comerciales operativos al equipo de datos y a los monolitos de gestión de datos: lagos de datos y almacenes de datos. Data mesh es un enfoque sociotécnico descentralizado para eliminar la dicotomía de datos analíticos y operaciones comerciales. Su objetivo es integrar el intercambio y el uso de datos analíticos en cada dominio comercial operativo y cerrar la brecha entre los planos operativo y analítico. Se basa en cuatro principios: propiedad de los datos de dominio, datos como producto, plataforma de datos de autoservicio y gobernanza federada computacional.

    Nuestros equipos han estado implementando la arquitectura de data mesh; han creado nuevas abstracciones arquitectónicas, como el cuanto de producto de datos para encapsular código, la política de datos como una unidad autónoma de intercambio de datos analíticos incrustada en dominios operativos; y han creado capacidades de plataforma de datos de autoservicio para administrar el ciclo de vida de los cuantos de productos de datos de manera declarativa, como se describe en Data Mesh. A pesar de nuestros avances técnicos, todavía estamos experimentando fricciones con el uso de las tecnologías existentes en una topología de data mesh, sin mencionar la resistencia de los dominios comerciales a aceptar el uso compartido y el uso de datos como una responsabilidad de primera clase en algunas organizaciones.

  • La documentation viva, que proviene desde la comunidad de behavior-driven development (BDD), es frecuentemente considerada un privilegio aplicable para aquellas bases de código que incluyen especificaciones ejecutables. Nosotros encontramos que esta técnica puede ser aplicada también a sistemas legados. La falta de conocimiento de negocio es un obstáculo común que encuentran los equipos cuando están realizando modernización de los sistemas. El código es usualmente la única fuente confiable de verdad debido a las rotaciones de personal y la falta de actualización de la documentación existente. Por lo tanto, es muy importante restablecer la asociación entre la documentación y el código y esparcir el conocimiento del negocio en el equipo cuando se toma a cargo un sistema legado. En práctica, podríamos primero acudir al código y profundizar nuestro conocimiento del negocio simplemente a través de una limpieza o refactorización segura del mismo. Durante el proceso, necesitaremos agregar anotaciones al código para ser capaces de generar automáticamente documentación viva más tarde. Esto es muy diferente a hacer BDD en proyectos green-field, pero es un buen inicio en sistemas legados. Basados en la documentación generada podríamos tratar de convertir algunas de las especificaciones en pruebas de automatización ejecutables de alto nivel. Haz esto iterativamente y eventualmente puedes obtener una documentación viva en sistemas legados que está estrechamente asociada con el código y es parcialmente ejecutable.

  • Desde su introducción en el Radar de 2016, hemos visto una amplia adopción de los micro frontends para interfaces de usuario (UIs) web. Sin embargo, recientemente, hemos visto proyectos que extienden este estilo de arquitectura para incluir también micro frontends para aplicaciones móviles. Cuando la aplicación se vuelve suficientemente grande y compleja, es necesario distribuir su desarrollo entre múltiples equipos. Esto presenta el reto de mantener la autonomía de dichos equipos, mientras se integra su trabajo en una única aplicación. Algunos equipos escriben sus propios frameworks para habilitar este estilo de desarrollo, y, en el pasado, hemos mencionado a Atlas and Beehive como posibles maneras de simplificar el problema de integrar el desarrollo de apps en múltiples equipos. Más recientemente, hemos visto a equipos utilizando React Native para lograr lo mismo. Cada micro frontend de React Native se mantiene en su propio repositorio, donde puede ser compilado, probado y desplegado por separado. El equipo responsable de la aplicación completa puede después consolidar todos estos micro frontends, desarrollados por diferentes equipos, en una sola aplicación terminada.

  • Seguimos viendo a muchos equipos trabajando y colaborando de forma remota; para estos equipos la programación en grupo es una técnica que merece la pena probar. La programación en grupo en remoto permite a equipos colaborar rápidamente en un problema o pieza de código sin la limitación física de poder acomodar solamente a cierto número de personas alrededor de una estación de trabajo en pareja. Los equipos pueden colaborar de manera rápida en un problema o pieza de código usando sus herramientas de videoconferencia sin tener que conectar una gran pantalla, reservar una sala de reuniones física o encontrar una pizarra blanca.

  • Con el creciente uso de equipos remotos distribuidos, una de las cosas que escuchamos es que las personas echan de menos el tablero físico del equipo. Este es un lugar único en el que se pueden mostrar todas las tarjetas de historias y tareas, con su correspondiente estado y progreso, que actúa como un irradiador de información y punto de encuentro para el equipo. A menudo el tablero era un punto de integración con los datos reales almacenados en varios sistemas diferentes. A medida que los equipos se han vuelto remotos, han tenido que volver a buscar en cada uno de los sistemas de origen, y lograr una mirada "de un vistazo" de un proyecto se ha vuelto muy difícil. Un tablero remoto de un equipo es una técnica simple para reintroducir el tablero del equipo virtualmente. Si bien puede haber un costo extra para mantenerlo actualizado, creemos que los beneficios para el equipo valen la pena. Para algunos equipos, la actualización del tablero físico formaba parte de las "ceremonias" diarias que el equipo realizaba en conjunto, y lo mismo se puede hacer con un tablero remoto.

  • La arquitectura de un sistema imita la estructura organizativa y su comunicación. No es una gran novedad que debamos ser intencionales sobre cómo interactúan los equipos - véase, por ejemplo, Inverse Conway Maneuver. La interacción de los equipos es una de las variables que determinan la rapidez y la facilidad con la que los equipos pueden aportar valor a sus clientes. Nos alegramos de encontrar una forma de medir estas interacciones; utilizamos la evaluación del autor de Team Topologies, brinda un mejor entendimiento de lo fácil o difícil que les resulta a los equipos construir, probar y mantener sus servicios. Al medir la carga cognitiva del equipo , podemos asesorar de mejor manera a nuestros clientes sobre cómo cambiar la estructura de sus equipos y hacer evolucionar sus interacciones.

Evaluar ?

  • Muchas aplicaciones de realidad aumentada (RA) necesitan conocer la ubicación y orientación del dispositivo del usuario. Por defecto, se utilizan soluciones basadas en GPS, pero también vale la pena considerar los anclajes espaciales , una nueva técnica para resolver este requisito. Los anclajes espaciales funcionan con la imagen grabada por la cámara del dispositivo, utilizando las características de la imagen y su posición relativa en el espacio 3D para reconocer una ubicación del mundo real. Para esta ubicación, se crea un ancla correspondiente en el espacio RA. Aunque los anclajes espaciales no pueden reemplazar todos los anclajes basados ​​en marcadores y GPS, brindan más precisión que la mayoría de las soluciones basadas en GPS y son más resistentes a diferentes ángulos de visión que los anclajes basados ​​en marcadores. Nuestra experiencia actualmente se limita a Cloud Anchors for Android de Google, que funcionó bien para nosotros. De forma algo inusual, Google también ofrece Cloud Anchors for iOS y con Azure Spatial Anchors Microsoft soporta aún más plataformas.

  • Después del exitoso lanzamiento de su aplicación de correo HEY como una aplicación del lado del servidor, Basecamp ha reportado estar migrando su producto insignia, Basecamp 3 a Hotwire este verano. Viendo cómo las organizaciones cada vez más seleccionan por defecto hacer Aplicaciones de Página Única para sus nuevos desarrollos web, nosotros nos emocionados por ver a Hotwire nadando contra corriente. A diferencia de las Aplicaciones de Página Única, las aplicaciones Hotwire conservan la mayoría de la lógica y navegación en el servidor, dependiendo de una mínima cantidad de Javascript en el navegador. Hotwire modulariza las páginas HTML dentro de un conjunto de componentes (llamados Turbo Frames) que pueden ser cargados de forma perezosa, provee contextos independientes y envía actualizaciones de HTML a esos contextos basándose en acciones del usuario. Las Aplicaciones de Página Única ofrecen una innegable capacidad de respuesta al usuario, pero la simpleza de la programación web tradicional del lado del servidor combinada con las herramientas de los navegadores modernos proveen una alternativa refrescante en cuanto al balance entre la efectividad del desarrollador y la capacidad de respuesta al usuario.

  • Estamos viendo un incremento en el uso del patrón de Kubernetes Operator para propósitos distintos a la gestión de aplicaciones desplegadas en el cluster. El uso del patrón de operación para recursos no clusterizados aprovecha las definiciones de recursos personalizadas y el mecanismo de programación basado en eventos implementado en el plano de control de Kubernetes para administrar actividades relacionadas aún fuera del clúster. Esta técnica se construye sobre la idea de Kube-managed cloud services y se extiende a otras actividades, como despliegue continuo o reacción a los cambios en repositorios externos. Una ventaja de esta técnica sobre una herramienta específicamente construida es que abre una amplia gama de herramientas que o bien vienen con Kubernetes o son parte del ecosistema más amplio. Puede usar comandos como diff, dry-run o apply para interactuar con los recursos personalizados del operador. El mecanismo de programación Kube hace el desarrollo más fácil al eliminar la necesidad de orquestar actividades en el orden correcto. Las herramientas de código abierto como Crossplane, Flux y ArgoCD toman ventaja sobre esta técnica y esperamos ver más emerger con el tiempo.

  • Estamos viendo una innovación continua en las herramientas de colaboración remota. La nueva función Huddles de Slack ofrece una experiencia similar a la de Discord, con llamadas de audio persistentes en las que los usuarios pueden entrar y salir en cualquier momento. Gather ofrece una forma creativa de emular una oficina virtual con avatares y vídeo. Los IDEs ofrecen funciones de colaboración directa para el emparejamiento y la depuración: ya hemos hecho saltar a Visual Studio Live Share y ha incluido JetBrains Code With Me a la lista en esta edición. A medida que las herramientas siguen evolucionando en cuanto a modalidades de colaboración, además de las videoconferencias, cada vez vemos más equipos que participan en remote spontaneous huddling , recreando la espontaneidad de las conversaciones informales por encima de la intencionalidad de programar una reunión de Zoom o Microsoft Teams. No esperamos recrear por completo la complejidad de la comunicación cara a cara a través de las herramientas digitales, pero sí vemos una mejora en la eficacia de los equipos remotos al ofrecerles múltiples canales de colaboración en lugar de depender de una cadena de herramientas para todo.

  • En mayo del 2021, la Casa Blanca de los Estados Unidos publicó la Orden Ejecutiva sobre la Mejora de la Ciberseguridad de la Nación. El documento propone varios mandatos técnicos que se relacionan a ítems que hemos presentado en Radares anteriores, como es la Arquitectura de Confianza Cero y el Escaneo Automatizado de Cumplimiento usando la política de seguridad como código. Gran parte del documento está dedicado a mejorar la seguridad del software de la cadena de suministro. Un ítem en particular que llamó nuestra atención fue el requerimiento de que el software del gobierno debería contener un lista de materiales de software (SBOM) legible por máquina, definido como “un registro formal conteniendo los detalles y las relaciones de la cadena de suministro de varios componentes utilizados en la construcción de software.” En otras palabras, debería detallar no solamente los componentes enviados sino también las herramientas y marcos utilizados para entregar el software. Esta orden ejecutiva tiene el potencial de marcar el comienzo de una nueva era de transparencia y apertura en el desarrollo de software. Esto indudablemente tendrá un impacto en aquellos de nosotros que producimos software como una forma de vida. Muchos, sino todos los productos de software producidos hoy contienen componentes open source o los utilizan en el proceso de desarrollo. A menudo, el consumidor no tiene forma de saber cuál versión de cuál paquete podría tener un impacto en la seguridad de su producto. En cambio, ellos deben confiar en las alertas de seguridad y parches proporcionados por el proveedor minorista. Esta orden ejecutiva asegurará que una descripción explícita de todos los componentes se ponga a disposición del consumidor, empoderándolos para implementar sus propios controles de seguridad, y como el SBOM es legible por máquina, esos controles pueden ser automatizados. Sentimos que este movimiento también representa un cambio hacia adoptar software open source y prácticamente considerando ambos, los riesgos y los beneficios de seguridad que este provee.

Resistir ?

  • Algunas organizaciones parecen pensar que la revisión por pares equivale a pull request; han adoptado el punto de vista de que la única manera de lograr una revisión por pares del código es a través de un pull request. Hemos visto que este enfoque crea importantes cuellos de botella en el equipo, así como también degrada significativamente la calidad de la retroalimentación en los comentarios, ya que los revisores al verse sobrecargados comienzan simplemente a rechazar las solicitudes. Aunque se podría argumentar que esta es una forma de demostrar el "cumplimiento normativo" de la revisión del código, a uno de nuestros clientes se le dijo que esto no era válido, ya que no había pruebas de que el código fuera realmente leído por alguien antes de su aceptación. Los pull requests son sólo una forma de gestionar el flujo de trabajo de la revisión de código; instamos a la gente a considerar otros enfoques, especialmente cuando hay una necesidad de entrenar y pasar la retroalimentación cuidadosamente.

  • Seguimos percibiendo a la producción de datos en entornos de prueba como un área de preocupación. En primer lugar, muchos ejemplos de esto han resultado en daños a la reputación, por ejemplo, cuando se ha enviado una alerta incorrecta desde un sistema de prueba a toda una población de clientes. En segundo lugar, el nivel de seguridad, específicamente en torno a la protección de datos privados, tiende a ser menor para los sistemas de prueba. No tiene mucho sentido tener controles elaborados sobre el acceso a los datos de producción si esos datos se copian en una base de datos de prueba a la que pueden acceder todos los desarrolladores y QA. Aunque puede ocultar los datos, esto tiende a aplicarse sólo a campos específicos, por ejemplo, números de tarjetas de crédito. Por último, copiar datos de producción en sistemas de prueba puede infringir las leyes de privacidad, por ejemplo, cuando los sistemas de prueba se alojan o se accede a ellos desde un país o región diferente. Este último escenario es especialmente problemático con implementaciones complejas en la nube. Los datos falsos son un enfoque más seguro y existen herramientas para ayudar en su creación. Reconocemos que existen razones para copiar elementos

 
Nuevo
Modificado
Ningún cambio

¿No encontraste algo que esperabas ver?

Cada edición del Radar presenta noticias que reflejan lo que hemos encontrado durante los seis meses anteriores. Es posible que ya hayamos cubierto lo que buscas en un Radar anterior. A veces seleccionamos cosas simplemente porque hay demasiadas de las que hablar. También es posible que falte algún dato porque el Radar refleja nuestra experiencia, no se basa en un análisis exhaustivo del mercado.

 

¿No encontraste algo que esperabas ver?

Cada edición del Radar presenta noticias que reflejan lo que hemos encontrado durante los seis meses anteriores. Es posible que ya hayamos cubierto lo que buscas en un Radar anterior. A veces seleccionamos cosas simplemente porque hay demasiadas de las que hablar. También es posible que falte algún dato porque el Radar refleja nuestra experiencia, no se basa en un análisis exhaustivo del mercado.

 

Radar

Descarga el Radar Tecnológico Volumen 25

English | Español | Português | 中文

Radar

Mantente informado sobre Tecnología

 

Suscríbete ahora

Visita nuestro archivo y nuestros volúmenes previos