Master

TechnologyRadar

Una guía con opiniones sobre las tecnologías de vanguardia
Volumen 24

Descarga el Radar Tecnológico Volumen 24

English| Español| Português| 中文| ไทย|

Temas para esta edición

Con más frecuencia, las organizaciones están adoptando el concepto de equipos de plataforma: armar un grupo dedicado que crea y da soporte a las capacidades internas de la plataforma, para luego aprovecharlas para acelerar el desarrollo de aplicaciones, reducir la complejidad operacional y mejorar los tiempos de salida al mercado.
Hemos visto un aumento — particularmente en el espacio de la nube — de integración de herramientas para desarrolladores, con la agregación de herramientas para repositorios de artefactos, el control de código fuente, los pipeline de CI/CD, las wikis y otros. Este conjunto de herramientas consolidadas ofrecen una mayor comodidad para el desarrollador y menos rotación. Pero el conjunto de herramientas puede no representar la mejor opción posible.
Muchos de los temas complejos discutidos en el Radar terminan siendo catalogados como “TCTB — muy complejo para ser un blip” (del inglés “too complex to blip”). Y con frecuencia, estos temas se repiten perennemente; esto incluye monorepos, pautas de orquestación para arquitecturas distribuidas y modelos de ramificación. Como muchos temas en el desarrollo de software, existen demasiados aspectos que equilibrar para poder emitir consejos claros e inequívocos.
Una discusión que se repite prácticamente en todas nuestras reuniones el nivel adecuado de acoplamiento en la arquitectura de software entre microservicios, componentes, API gateways, centros de integración (integration hubs), front-ends, y demás... prácticamente en cualquier lugar en el que dos piezas de software puedan conectarse. Pero no hay una sola respuesta correcta: estas decisiones deben tomarse según caso por caso, en lugar de buscar una solución genérica pero inadecuada.

Equipos de plataforma impulsan la velocidad de salida al mercado


Con más frecuencia, las organizaciones están adoptando el concepto de equipos de plataforma: armar un grupo dedicado que crea y da soporte a las capacidades internas de la plataforma (nativa a la nube, entrega continua, observabilidad moderna, patrones de autenticación/authorización, mallas de servicio, etc), para luego aprovecharlas para acelerar el desarrollo de aplicaciones, reducir la complejidad operacional y mejorar los tiempos de salida al mercado. Esta madurez creciente es bienvenida y presentamos esta técnica en el Radar en 2017. Pero con el incremento de la madurez, también hemos descubierto antipatrones que las organizaciones deben evitar. Por ejemplo, "una plataforma para gobernar a todas" puede no ser óptima, una "plataforma grande desde el inicio" puede tomar años para entregar valor y "constrúyela y ellos vendrán" puede terminar como un esfuerzo desperdiciado. En cambio, usar un enfoque con orientación al producto puede ayudar a esclarecer qué deben proveer cada una de las plataformas internas, dependiendo de sus clientes. Las compañías que arman sus equipos de plataforma utilizando un sistema de tickets como silos de operaciones a la vieja usanza, encuentran las mismas desventajas de una priorización mal alineada: lentitud en la retroalimentación y en las respuestas, contención en la asignación de recursos y otros problemas bien conocidos por el uso de silos. También hemos visto aparecer un gran número de nuevas herramientas y patrones de integración para equipos y tecnologías, lo que permite un particionamiento más efectivo entre ambas.

Comodidades consolidadas frente a lo mejor de su clase


A medida que las prácticas de ingeniería que ofrecen automatización, escala y otros objetivos modernos se vuelven más comunes en los equipos de desarrollo, vemos la correspondiente integración de herramientas de desarrollo en muchas plataformas, particularmente en el espacio de la nube. Por ejemplo, los repositorios de artefactos, el control de código fuente, los pipelines de CI/CD, las wikis y demás herramientas similares eran escogidas a mano e individualmente por los equipos de desarrollo y ensambladas a la carta. Ahora, plataformas de entrega como Azure DevOps y ecosistemas como GitHub han integrado muchas de estas categorías de herramientas. Si bien el nivel de madurez varía según las ofertas de cada plataforma, el atractivo de tener "todo en un mismo lugar" con respecto a las herramientas de entrega es innegable. En general, parece que el equilibrio radica en tener un conjunto de herramientas consolidadas que ofrecen una mayor comodidad para el desarrollador y menos rotación, a pesar que estas herramientas rara vez representan lo mejor posible.

“Muy complejo para ser un blip”, lo perenne del radar


En la nomenclatura del Radar, el estado final luego de discutir sobre varios temas complejos es "muy complejo para ser un blip" o "TCTB" (del inglés "too complex to blip"): son elementos que desafían nuestros parámetros de clasificación porque ofrecen una serie de pros y contras, una gran cantidad de matices en cuanto a la aplicabilidad del consejo o la herramienta, o por otros motivos que nos impiden resumir nuestras opiniones en pocas frases. Con frecuencia, estos temas se tratarán como artículos, podcasts y en otros medios que no son el Radar. Algunas de nuestras mejores conversaciones se centran en estos temas: son importantes pero complejas, e impiden llegar a un único, y resumido, punto de vista. Numerosos temas se repiten reunión tras reunión (además de que los vemos frecuentemente con nuestros clientes) que terminan siendo catalogados como TCTB, como los monorepos, pautas de orquestación para arquitecturas distribuidas y modelos de ramificación, entre otros. Si alguien se preguntan por qué estos temas importantes no aparecen en el Radar, no es por falta de conciencia o deseo de nuestra parte. Como muchos temas en el desarrollo de software, existen demasiados aspectos que equilibrar para poder emitir consejos claros e inequívocos. A veces encontramos elementos más pequeños de los temas más importantes sobre los que si podemos ofrecer consejo, y llegan a estar en el Radar; pero los temas más importantes siguen perpetuamente inestables, con demasiados matices, para el Radar.

Discernir el contexto para el acoplamiento de arquitectura


Una discusión que se repite prácticamente en todas nuestras reuniones (revisa el tema denominado "'Muy complejo para ser un blip', lo perenne del radar") tiene que ver con el nivel adecuado de acoplamiento en la arquitectura de software entre microservicios, componentes, API gateways, centros de integración (integration hubs), front-ends, etc.; las personas de arquitectura y de desarrollo luchan por encontar el nivel correcto de acoplamiento prácticamente en todos los lugares donde se pueden conectar dos elementos de software, considerando que muchos consejos comunes fomentan el desacoplamiento extremo, aunque eso dificulta la creación de flujos de trabajo. El acoplamiento en la arquitectura pasa por muchas consideraciones importantes: la forma en que se conectan las cosas, comprender el acoplamiento semántico inherente dentro de cada dominio del problema, cómo se invocan las cosas entre sí o el funcionamiento de la transaccionalidad (a veces en combinación con otras características complicadas como la escalabilidad). El software no puede existir sin algún nivel de acoplamiento por fuera de los sistemas monolíticos singulares; encontrar el balance correcto para determinar los tipos y niveles de acoplamiento se convierte en una habilidad crítica con las arquitecturas modernas. Vemos malas prácticas específicas como la generación de código para bibliotecas cliente, y buenas prácticas como el uso juicioso de los patrones BFF. Sin embargo, brindar consejos generales en este ámbito es inútil y tampoco existen soluciones mágicas. Se debe invertir tiempo y esfuerzo en comprender los factores en juego al tomar estas decisiones caso por caso, en lugar de buscar una solución genérica pero inadecuada.

Visita nuestro archivo para leer edición anteriores

Suscríbete. Sigue informado/a

Publicamos artículos relacionados al Technology Radar durante todo el año.

¡Gracias!

Te has suscrito al contenido de nuestro Technology Radar. Mantente atento a tu bandeja de entrada, nos pondremos en contacto pronto.