El estilo arquitectónico de microservicios está tomando el mundo por asalto. El pasado mes de marzo, O'Reilly acogió su primera 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.
Los microservicios cumplen esta definición por su principio de contexto fuertemente cerrado, convirtiendo la división lógica descrita en el 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.
[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).
[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.
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
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. . 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 ºÚÁÏÃÅ 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.Â
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.
´¡°ù±ç³Ü¾±³Ù±ð³¦³Ù³Ü°ù²¹Ìý·¡±¹´Ç±ô³Ü³Ù¾±±¹²¹
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 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 , 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.·¡³æ±è±ð°ù¾±³¾±ð²Ô³Ù²¹³¦¾±Ã³²Ô
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, , 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
°ä´Ç²Ô³¦±ô³Ü²õ¾±Ã³²Ô
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. . 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 ºÚÁÏÃÅ 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.Â
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 ºÚÁÏÃÅ.