Microservicios como una Arquitectura Evolutiva

El estilo arquitectónico de microservicios está tomando el mundo por asalto. El pasado mes de marzo, O'Reilly acogió su primera Conferencia de Arquitectura de Software y un porcentaje enorme de las ideas que el comité del programa recibió tocaban algún aspecto de microservicios. ¿Por qué está este estilo arquitectónico causando furor de repente?

Los microservicios son la primera revolución de estilo arquitectónico tras DevOps y los primeros que abarcan completamente las prácticas de ingeniería de Entrega Continua en su totalidad. Son también un ejemplo de arquitectura evolutiva, que dan soporte al cambio incremental sin romper nada como un principio primario a lo largo de múltiples dimensiones a nivel estructural de la aplicación. Sin embargo, es sólo una del grupo de arquitecturas que soportan ciertos comportamientos evolutivos. Este artículo investiga algunas características y principios de esta familia de estilos de arquitectura.

Arquitectura Evolutiva

La sabiduría popular del software sostenía que los elementos arquitectónicos eran "difíciles de cambiar después". Una arquitectura evolutiva plantea, como principio primario, un diseño para que haya cambios incrementales en la arquitectura. Las arquitecturas evolutivas son atractivas porque históricamente el cambio ha sido difícil de anticipar y costoso de readaptar. Si el cambio evolutivo se construye desde dentro de la arquitectura, se convierte en algo más fácil y menos costoso, permitiendo cambios en las prácticas de desarrollo, despliegue y agilidad en general.

Los microservicios cumplen esta definición por su principio de contexto fuertemente cerrado, convirtiendo la división lógica descrita en el Diseño Guidado por el Dominio de Evans en una separación física. Los microservicios consiguen esta separación a través de prácticas avanzadas de DevOps como el aprovisionamiento de máquinas, pruebas y despliegues automáticos. Como cada servicio está desacoplado de todos los demás (a nivel estructural), reemplazar un microservicio por otro se parece a cambiar un bloque de Lego por otro.

Características de la Arquitectura Evolutiva

Las arquitecturas evolutivas presentan varias características comunes. Hemos identificado un gran número de ellas para el libro que próximamente será publicado sobre Arquitectura Evolutiva. Aquí pueden encontrar algunas de ellas.

Modularidad y Acoplamiento

La habilidad de separar componentes con fronteras bien definidas tiene un beneficio innegable si el desarrollador necesita realizar un cambio que no rompa el funcionamiento del sistema. La ausencia de elementos de arquitectura, la legendaria Gran Bola de Lodo, no soporta la evolución por su falta de compartimentación.


[El acoplamiento entre clases (los puntos en el perímetro) en la Gran Bola de Lodo, tomado del proyecto de un cliente no nombrado]

El acoplamiento inapropiado inhibe la evolución al propagar cambios en caminos difíciles de predecir. Las Arquitecturas Evolutivas siempre soportan algún nivel de modularidad, típicamente, a nivel de arquitectura técnica (por ejemplo, la clásica arquitectura por capas).

Organización Alrededor de Competencias del Negocio

Cada vez más las arquitecturas modernas y exitosas promueven también modularidad a nivel de dominio, inspiradas en el Diseño Guiado por el Dominio. Las arquitecturas basadas en servicios se diferencian de las tradicionales Arquitecturas Orientadas a Servicios (SOA),  mayormente en la estrategia de particionamiento: SOA está estrictamente particionado en capas técnicas, mientras que las arquitecturas basadas en servicios tienden hacia la partición de dominio inspirada en microservicios.

Experimentación

La experimentación es uno de los superpoderes que las arquitecturas evolutivas le entregan al negocio. Cambios operacionales triviales y sin costo son posibles por prácticas comunes de Entrega Continua como pruebas A/B, Canary Releases, entre otras. A menudo, las arquitecturas de microservicios están diseñadas alrededor de enrutamientos entre servicios para definir las aplicaciones, permitiendo la existencia de distintas versiones de un mismo servicio dentro del ecosistema. Esto a su vez permite la experimentación y reemplazo gradual de las funcionalidades existentes.  Por último, esta capacidad habilita que tu negocio gaste menos tiempo en especulaciones sobre el conjunto de historias a realizar del negocio y en su lugar aborden en un desarrollo guiado por hipótesis.

Principios de las Arquitecturas Evolutivas

Una manera de pensar en las arquitecturas evolutivas es a través de principios. Los principios describen varias características de las arquitecturas y de las formas de diseñarlas. Algunos de ellos se concentran en el momento en que algunas decisiones de arquitecturas son tomadas como parte del proceso.

Funciones de Aptitud

Hacemos una importante distinción entre arquitectura emergente y arquitectura evolutiva. Muy parecido a las técnicas de computación evolutiva como los algoritmos genéticos, una función de aptitud de arquitectura especifica cómo debe ser la arquitectura a la que queremos llegar. Por ejemplo, algunos sistemas necesitan un alto tiempo de actividad mientras otros están más preocupados por el rendimiento o la seguridad.



[Un gráfico de tipo radar utilizado para resaltar la importancia de las funciones de aptitud apropiadas para este sistema.]

El análisis previo de qué función de aptitud pudiera existir para un sistema en particular, proporciona direccionamiento en la toma de decisiones y su planificación en el tiempo. Las decisiones de arquitectura son evaluadas en relación a las funciones de aptitud de tal manera que podamos ver que la arquitectura está evolucionando en la dirección correcta.

Visibilizar los puntos de dolor

Muchas de las prácticas en la entrega continua y la arquitectura evolutiva ejemplifican el principio de visibilizar los puntos de dolor, inspirado por la comunidad de Programación eXtrema. Cuando algo en un proyecto tiene el potencial de causar dolor, oblígate a realizarlo más a menudo y más temprano, lo que a su vez te alentará a automatizar la parte que causa dolor e identificar los problemas temprano. Prácticas comunes de entrega continua como los pipelines de despliegue, aprovisionamiento de máquinas, y migraciones de base de datos hacen más simple el desarrollo de arquitectura evolutiva eliminando los puntos comunes de dolor frente al cambio.

Último momento responsable

Una de las mayores diferencias entre la arquitectura tradicional y la arquitectura evolutiva es el cuándo ocurren las decisiones. Estas decisiones podrían ser sobre la estructura de la aplicación, la pila tecnológica, herramientas específicas o patrones de comunicación. En una arquitectura tradicional, estas decisiones se manifiestan temprano, antes de escribir código. En una arquitectura evolutiva, esperamos al último momento responsable para tomar decisiones. El beneficio de retrasar una decisión es la información adicional disponible para tomarla. El costo es el cualquier posible retrabajo que tiene que ocurrir una vez que una decisión ha sido tomada, que puede ser mitigado a través de las abstracciones apropiadas (pero el coste es todavía real). Sin embargo, el coste de tomar una decisión demasiado pronto es también real. Considera la elección de una herramienta de mensajería. Si elegimos una herramienta más pesada de lo que finalmente necesitamos, hemos introducido una fuente de deuda técnica en nuestro proyecto. Esta deuda viene en la forma de echar por tierra el desarrollo debido a la utilización de la herramienta equivocada. Esto no es una excusa para "abstraer todas las cosas" anticipadamente (todavía apoyamos el principio ágil YAGNI, You Ain't Gonna Need It) sino para optar por un intento informado de tomar la decisión en el momento adecuado.

Por supuesto, la pregunta inmediata cuando pensamos acerca del último momento responsable es decidir cuándo es dicho momento. Las funciones de aptitud proporcionan la guía para esa decisión. Las decisiones que tendrán una influencia decisiva en otras opciones de arquitectura o diseño o decisiones que tienen impacto en un factor crítico de éxito para el proyecto deberían ser tomadas antes. El impacto para el proyecto de retrasar dicha decisión es a menudo mayor que el beneficio de espera

Conclusión

Los arquitectos y arquitectas de software tienen la responsabilidad de aclarar las decisiones acerca de cómo encajan los sistemas juntos, a menudo creando diagramas. Demasiados arquitectos fallan en darse cuenta de que una imagen bidimensional y estática de la arquitectura tiene una duración corta. El universo del software existe en un estado de flujo constante; dinámico más que estático. La arquitectura no es una ecuación sino una foto de un proceso en curso.

Los movimientos de Entrega Contínua y DevOps ilustraron las trampas de ignorar el esfuerzo requerido para implementar una arquitectura y mantenerla al día. No hay nada de malo en modelar la arquitectura y capturar dichos esfuerzos, pero la implementación es sólo el primer paso. La arquitectura es abstracta hasta que se hace operativa. En otras palabras, no se puede juzgar la viabilidad a largo plazo de ninguna arquitectura hasta que no sólo la has implementado sino también actualizado. Y quizá incluso preparado para resistir eventos poco usuales.

La preocupación por los aspectos operativos de los arquitectos es crítica para las arquitecturas evolutivas. La evolución impacta en los detalles específicos de la implementación, por lo que los detalles de implementación no pueden ser ignorados. Los requerimientos que la Entrega Continua impone sobre la arquitectura hace su implementación más sencilla y facilita su evolución. Por lo tanto, la Entrega Continua es una habilitador importante para cualquier arquitectura evolutiva.

Traducción al español realizada por: Ana Tellería y Jorge Agudo

Recursos adicionales: 

En este episodio de Thoughtworks Tech Leaders Podcast, Rebecca y Neal discuten sobre el significado de las arquitecturas evolutivas y cómo las organizaciones pueden usarlo como ventaja para el negocio. 



Mira el webinar reciente de Arquitectura evolutiva presentando por Neal.