Siempre que publicamos un Radar Tecnológico, echo un vistazo a las grandes tendencias dentro de la industria de la tecnología, que no necesariamente llegan a incluirse como blips o temas del radar. Crear el Radar es una excelente oportunidad para analizar qué es lo que está pasando dentro del mundo del software, estas son las novedades:
Sin embargo, estamos empezando a ver problemas cuando la facilidad de uso de una herramienta en una situación determinada se convierte en un “anti-paradigma” para otro caso de uso. Por ejemplo, tenemos Productionizing Jupyter notebooks en Resistir. Consideramos que Jupyter es una excelente herramienta de análisis de datos para llegar a conclusiones y extraer ideas, pero si quieres utilizar Jupyter directamente en producción (en lugar de llevar el código a un lenguaje más orientado a producción como Python), puedes generar un gran problema para ti misma/o.
De igual manera, es sencillo soltar un archivo en un repositorio de Amazon S3, conectar esto al Servicio Simple de Notificaciones (Simple Notification Service SNS) y disparar una función Lambda para procesar su contenido, pero el embrollo de infraestructura asociada puede causar más problemas de lo que merece la pena.
En realidad, esta es la última encarnación de la regla del 80% y la necesidad de entenderla. Muchas herramientas te darán una gran aceleración en el 80% de casos de uso. Estas simplemente funcionan. Para el siguiente 10%, probablemente puedas hacer que hagan lo que tu quieras. Pero para el 10% final, es posible que te hayas metido en una esquina y estés en el estado de “paga después”. ¿Realmente puedes superar la complejidad para llegar a tener ese 10% final? Muchos equipos harían mejor en dar un paso atrás, separándose del problema de vez en cuando, y preguntarse: ¿Deberíamos trabajar para superar esas dificultades, o deberíamos considerar una herramienta diferente para nuestro caso de uso?
Con la continua popularidad de los microservicios, estamos viendo una creciente madurez entorno a su ejecución con una “adecuada” gestión de servicios. Antiguas técnicas de operación han sido reinventadas con nuevos nombres como “Presupuestos de Errores”. Los SLO dan a los equipos métricas claras para usar cuando deben determinar si un enfoque de “tu lo construyes, tu lo corres” está funcionando. Las Mallas de Servicio, como Istio, soportan directamente estos conceptos de gestión de servicios. Observabilidad es un término que está en boca de todos, y los equipos están trabajando duro para asegurarse de que la salud de sus sistemas sea adecuadamente visible para las herramientas de monitorización.
Un verdadero “Modelo operativo de microservicios” también incluye cambios en el diseño del equipo y responsabilidades e impactos organizacionales asociados. Estos modelos están empezando a aparecer, pero creemos que deberían estar basados en identificar una serie de capacidades de negocio y plataforma, para luego alinear equipos de larga duración que planifican, construyen y ejecutan productos para ofrecer estas capacidades. Debemos tener precaución con respecto a la idea de crear un equipo de ‘plataforma’ monolítica o simplemente debemos esperar que las capacidades de negocio compartidas aparezcan por casualidad y sean asimiladas por ósmosis.
Existen abundantes ejemplos de ello. Taiko es una librería de node para automatizar el navegador Chrome que pretende ofrecer una API clara y concisa. No es que nunca antes hayamos intentado realizar tests en el navegador, pero es algo que va mejorando en cada paso. Deno, un motor seguro de JavaScript y TypeScript en el servidor, es del creador original de Node.js, y fue creado como respuesta directa a áreas que, este consideraba, eran las más problemáticas de Node. Gremlin es un lenguaje para recorrer grafos que implementa mejoras con respecto a sus predecesores. Immer.js ganó el premio “innovación del año” por su progresión del estado del arte en árboles de estado inmutable. Micronaut es un framework para construir microservicios y aplicaciones serverless que nos permite avanzar un paso considerable en este espacio.
Estos pasos individuales de hoy nos conducen a las innovaciones de mañana, que como ya hemos dicho, son fundamentalmente impredecibles (un principio básico de la Arquitectura Evolutiva es construir sistemas sabiendo que no podemos predecir estos cambios de manera eficaz).
Kief Morris, autor de Infrastructure as Code, cree que el problema subyacente es que estamos fallando a la hora de mantener límites claros entre lo que es configuración y lo que es lógica. En su opinión, no deberíamos probar ficheros de configuración, ni deberíamos definir un estado objetivo con lógica programable. El hacer cualquiera de las dos, es un indicio de que esos límites no están bien definidos.
Morris sugiere que los lenguajes declarativos necesitan hacer más fácil su extensión, añadiendo lógica en componentes separados y que puedan ser probados. Dice: “Si quiero añadir una nueva cosa que puedo declarar, extiendo el lenguaje declarativo para añadir una definición, y entonces implement la lógica del ‘como’ que dispara esta definición usando un lenguaje apropiado, con pruebas.”
Neal Ford, citando deliberadamente de manera equivocada a Dijkstra durante nuestra reciente reunión del Radar, dice: “Hemos desacoplado tanto las cosas que casi hemos terminado teniendo un espagueti, y ahora necesitamos juntarlo para hacer algo útil con él.”
Es importante recordar que la orquestación por sí misma no es mala. Es como el acoplamiento. Necesitas una cierta cantidad para que el sistema realmente funcione y proporcione valor. Si la orquestación es algo malo o no, depende de cuán abundante es en una aplicación y cuán extendida está por la misma.
Para ser un poco más precisos, la lógica de negocio es posiblemente solo lo que hace los cálculos. Pero existen decisiones relevantes para el negocio que hay que tomar.¿Qué deberíamos hacer si necesitamos escalar de esta forma?¿Cómo debería degradarse el sistema en condiciones de carga? Estas son preguntas para un Product Owner, y son lógica de negocio, aunque no en el sentido tradicional. Nos hemos decidido por la expresión “comportamiento de negocio” para englobar a estas clases de características.
Nuestro consejo es que los equipos primero reconozcan que esta diseminación ha ocurrido. En la arquitectura de la vieja escuela, todo lo que fuera significativo habría estado en la capa de dominio del negocio. Pero eso ya no es así, la lógica equivalente impregna una combinación de infraestructura, configuración, microservicios, e integraciones. Dirección por eventos, funciones serverless, ficheros en un bucket de S3 disparando una lambda — es muy difícil seguir el flujo de la lógica a través de un sistema. Los equipos deben esforzarse por usar patrones que hagan que el comportamiento global sea más fácil de entender, posiblemente incluso (¡ejem!) reduciendo el número de tecnologías empleadas en un solo sistema.
Traducción realizada por: Iván Ortega y Jesús Cardenal
Compra ahora, paga después
En los últimos años, hemos visto un mayor énfasis en la “experiencia de la persona desarrolladora” en herramientas y plataformas. Ya sea un IDE, una librería de código abierto o alguna clase de plataforma en la nube, la facilidad con la cual las/os desarrolladoras/es pueden usarlas o adoptarlas es cada vez más importante. Esto es algo bueno y frecuentemente un motor de innovación. Tratar a las/os desarrolladoras/es como clientes de su producto puede darles una ventaja.Sin embargo, estamos empezando a ver problemas cuando la facilidad de uso de una herramienta en una situación determinada se convierte en un “anti-paradigma” para otro caso de uso. Por ejemplo, tenemos Productionizing Jupyter notebooks en Resistir. Consideramos que Jupyter es una excelente herramienta de análisis de datos para llegar a conclusiones y extraer ideas, pero si quieres utilizar Jupyter directamente en producción (en lugar de llevar el código a un lenguaje más orientado a producción como Python), puedes generar un gran problema para ti misma/o.
De igual manera, es sencillo soltar un archivo en un repositorio de Amazon S3, conectar esto al Servicio Simple de Notificaciones (Simple Notification Service SNS) y disparar una función Lambda para procesar su contenido, pero el embrollo de infraestructura asociada puede causar más problemas de lo que merece la pena.
En realidad, esta es la última encarnación de la regla del 80% y la necesidad de entenderla. Muchas herramientas te darán una gran aceleración en el 80% de casos de uso. Estas simplemente funcionan. Para el siguiente 10%, probablemente puedas hacer que hagan lo que tu quieras. Pero para el 10% final, es posible que te hayas metido en una esquina y estés en el estado de “paga después”. ¿Realmente puedes superar la complejidad para llegar a tener ese 10% final? Muchos equipos harían mejor en dar un paso atrás, separándose del problema de vez en cuando, y preguntarse: ¿Deberíamos trabajar para superar esas dificultades, o deberíamos considerar una herramienta diferente para nuestro caso de uso?
El modelo operativo de microservicios
Mi antiguo colega, Aaron Erickson, solía describir los microservicios como la primera arquitectura verdaderamente “nativa en la nube”, y nosotros ciertamente creemos que es una elección razonable para sistemas modernos. Los equipos deben tener cuidado de la microservice envy (envidia del microservicio) y entender que los microservicios intercambian la reducción en la complejidad del desarrollo por el incremento de la complejidad operativa (increased operational complexity). Es decir, mientras cada servicio es más simple, la coreografía requerida para que todas/os trabajen juntos es más compleja que en una arquitectura monolítica.
Con la continua popularidad de los microservicios, estamos viendo una creciente madurez entorno a su ejecución con una “adecuada” gestión de servicios. Antiguas técnicas de operación han sido reinventadas con nuevos nombres como “Presupuestos de Errores”. Los SLO dan a los equipos métricas claras para usar cuando deben determinar si un enfoque de “tu lo construyes, tu lo corres” está funcionando. Las Mallas de Servicio, como Istio, soportan directamente estos conceptos de gestión de servicios. Observabilidad es un término que está en boca de todos, y los equipos están trabajando duro para asegurarse de que la salud de sus sistemas sea adecuadamente visible para las herramientas de monitorización.
Un verdadero “Modelo operativo de microservicios” también incluye cambios en el diseño del equipo y responsabilidades e impactos organizacionales asociados. Estos modelos están empezando a aparecer, pero creemos que deberían estar basados en identificar una serie de capacidades de negocio y plataforma, para luego alinear equipos de larga duración que planifican, construyen y ejecutan productos para ofrecer estas capacidades. Debemos tener precaución con respecto a la idea de crear un equipo de ‘plataforma’ monolítica o simplemente debemos esperar que las capacidades de negocio compartidas aparezcan por casualidad y sean asimiladas por ósmosis.
Mejora constante
Si hay algo que diferencia a las/os tecnólogas/os ‘buenas/os’ de las/os ‘excelentes’ (sin importar su área de especialidad), es que la gente que es excelente en algo, nunca está contenta con la solución actual, y siempre trabaja para crear una mejor respuesta. Como sector, mejoramos de manera implacable nuestros antiguos diseños. Puede ya existir una buena solución para un problema, pero siempre hay alguien que crea una solución mejor, y entonces iteramos.Existen abundantes ejemplos de ello. Taiko es una librería de node para automatizar el navegador Chrome que pretende ofrecer una API clara y concisa. No es que nunca antes hayamos intentado realizar tests en el navegador, pero es algo que va mejorando en cada paso. Deno, un motor seguro de JavaScript y TypeScript en el servidor, es del creador original de Node.js, y fue creado como respuesta directa a áreas que, este consideraba, eran las más problemáticas de Node. Gremlin es un lenguaje para recorrer grafos que implementa mejoras con respecto a sus predecesores. Immer.js ganó el premio “innovación del año” por su progresión del estado del arte en árboles de estado inmutable. Micronaut es un framework para construir microservicios y aplicaciones serverless que nos permite avanzar un paso considerable en este espacio.
Estos pasos individuales de hoy nos conducen a las innovaciones de mañana, que como ya hemos dicho, son fundamentalmente impredecibles (un principio básico de la Arquitectura Evolutiva es construir sistemas sabiendo que no podemos predecir estos cambios de manera eficaz).
Simplemente no sabemos cómo, dentro de dos años, se combinarán las mejoras continuas de un solo paso para producir algo revolucionario.
Llevando la configuración demasiado lejos
Nuestras conversaciones del Radar dedicaron un tiempo significativo a tratar el problema de la “codificación en la configuración” y el terreno resbaladizo que se crea cuando un mero lenguaje de configuración finalmente crece y crece, hasta que terminamos con un “XML Turing-completo” que resulta muy difícil de probar y analizar. Esto parece ocurrir en muchas situaciones, desde ficheros de construcción de software a plantillas de configuración de Terraform. Los equipos a menudo terminan decidiendo que es más fácil simplemente hacer código probado en un lenguaje de programación que utilizar una herramienta que hemos retorcido hasta convertirla en configuración programable.Kief Morris, autor de Infrastructure as Code, cree que el problema subyacente es que estamos fallando a la hora de mantener límites claros entre lo que es configuración y lo que es lógica. En su opinión, no deberíamos probar ficheros de configuración, ni deberíamos definir un estado objetivo con lógica programable. El hacer cualquiera de las dos, es un indicio de que esos límites no están bien definidos.
Morris sugiere que los lenguajes declarativos necesitan hacer más fácil su extensión, añadiendo lógica en componentes separados y que puedan ser probados. Dice: “Si quiero añadir una nueva cosa que puedo declarar, extiendo el lenguaje declarativo para añadir una definición, y entonces implement la lógica del ‘como’ que dispara esta definición usando un lenguaje apropiado, con pruebas.”
La complejidad de la orquestación va en aumento
Una tendencia general en el paisaje tecnológico es el incremento de la complejidad total, que podemos ver en el incremento de orquestación necesaria entre componentes. Luigi es una nueva herramienta en el área de datos que nos ayuda a construir pipelines complejos de trabajos en lotes. Apache Airflow nos permite de manera programática crear, planificar y monitorizar flujos de trabajo. Ahora tenemos toda clase de cosas nuevas entrando en nuestros sistemas — funciones-como-servicio, flujos de trabajo, procesos Python, etc.Neal Ford, citando deliberadamente de manera equivocada a Dijkstra durante nuestra reciente reunión del Radar, dice: “Hemos desacoplado tanto las cosas que casi hemos terminado teniendo un espagueti, y ahora necesitamos juntarlo para hacer algo útil con él.”
Es importante recordar que la orquestación por sí misma no es mala. Es como el acoplamiento. Necesitas una cierta cantidad para que el sistema realmente funcione y proporcione valor. Si la orquestación es algo malo o no, depende de cuán abundante es en una aplicación y cuán extendida está por la misma.
Diseminación del Comportamiento de Negocio
Organizaciones que se encuentran con problemas al llevar la configuración demasiado lejos y con la complejidad de la orquestación son síntomas de una tendencia más grande: la lógica de negocio ya no está confinada en pequeños trozos de código, sino que está diseminada por todo el sistema. La lógica de negocio se encuentra en el modo en que configuramos los pods de Kubernetes, y el modo en que orquestamos nuestras funciones lambda. Scott Shaw lo expresa así: “Existe la noción anticuada de que tienes una ‘carga de trabajo’ y que puedes mover esa carga de trabajo a diferentes sitios. Existen responsabilidades para escribir la carga de trabajo, alojar la carga de trabajo y el plano de control y la aplicación están claramente separados. Y eso ha dejado de ser cierto.”Para ser un poco más precisos, la lógica de negocio es posiblemente solo lo que hace los cálculos. Pero existen decisiones relevantes para el negocio que hay que tomar.¿Qué deberíamos hacer si necesitamos escalar de esta forma?¿Cómo debería degradarse el sistema en condiciones de carga? Estas son preguntas para un Product Owner, y son lógica de negocio, aunque no en el sentido tradicional. Nos hemos decidido por la expresión “comportamiento de negocio” para englobar a estas clases de características.
Nuestro consejo es que los equipos primero reconozcan que esta diseminación ha ocurrido. En la arquitectura de la vieja escuela, todo lo que fuera significativo habría estado en la capa de dominio del negocio. Pero eso ya no es así, la lógica equivalente impregna una combinación de infraestructura, configuración, microservicios, e integraciones. Dirección por eventos, funciones serverless, ficheros en un bucket de S3 disparando una lambda — es muy difícil seguir el flujo de la lógica a través de un sistema. Los equipos deben esforzarse por usar patrones que hagan que el comportamiento global sea más fácil de entender, posiblemente incluso (¡ejem!) reduciendo el número de tecnologías empleadas en un solo sistema.
Traducción realizada por: Iván Ortega y Jesús Cardenal
Aviso legal: Las declaraciones y opiniones expresadas en este artículo son las del autor/a o autores y no reflejan necesariamente las posiciones de Thoughtworks.