Hemos preparado una traducción de un artículo de Neil Ford, arquitecto de sistemas y autor intelectual ideológico de ThoughtWorks, una compañía de desarrollo de software que automatiza las pruebas de software y los procesos de implementación.
Neil es un reconocido experto en desarrollo de software que trabaja en la encrucijada del diseño ágil y la arquitectura de sistemas. Es autor de numerosos artículos, libros, docenas de presentaciones en video, habla en las principales conferencias de desarrolladores. Puedes ver su trabajo en
nealford.com .
Microservicios como arquitectura evolutiva
La arquitectura de microservicios está conquistando rápidamente el mundo. En marzo, la editorial O'Reilly organizó su primera Conferencia de Arquitectura de Software O'Reilly. Y casi el 60% de los informes se dedicaron a ciertos aspectos del uso de microservicios. ¿Por qué este estilo arquitectónico particular de repente se hizo tan popular?
La arquitectura de microservicios es un nuevo estilo de diseño arquitectónico que surgió después de DevOps e incorpora prácticas continuas de entrega de software. También es un ejemplo de una arquitectura evolutiva que sigue el principio de cambios graduales y continuos en varias dimensiones a nivel estructural de una aplicación. Este artículo analiza algunas de las características y principios más destacados de esta familia de estilos arquitectónicos.
Arquitectura evolutiva
Anteriormente se creía que los elementos de la arquitectura "son muy difíciles de cambiar después de su creación". El cambio gradual es el principio principal de la arquitectura evolutiva. Atrae la atención general precisamente porque los cambios en la arquitectura siempre han sido difíciles de prever y muy costosos de realizar. Si la posibilidad de cambios evolutivos se integra en la arquitectura misma, entonces su implementación se vuelve mucho más simple y económica, lo que contribuye a los cambios en el desarrollo de software y las prácticas de lanzamiento, así como a aumentar el nivel de flexibilidad general del proceso.
La arquitectura de microservicios es totalmente coherente con esta idea porque tiene
contextos limitados que se asignan lógicamente de acuerdo con el diseño impulsado por dominio de Eric Evans y se implementan como componentes físicamente separados. Esta separación se logra mediante la implementación de prácticas de DevOps como el aprovisionamiento de máquinas virtuales, las pruebas y la implementación automatizada. Dado que cada servicio está separado de todos los demás servicios (a nivel estructural), reemplazar un microservicio por otro es tan fácil como intercambiar cubos de lego.
Características de la arquitectura evolutiva.
Las arquitecturas evolutivas tienen una serie de características comunes. Todas estas características se describirán en un próximo libro sobre arquitectura evolutiva. En este artículo damos solo algunos de ellos.
Modularidad y conectividad.
La capacidad de compartir componentes dentro de límites bien definidos ofrece a los desarrolladores el beneficio de un cambio continuo si es necesario. Si la arquitectura no fue diseñada y el sistema se ve como una gran bola de lodo (
arquitectura Big Ball of Mud ), entonces los cambios evolutivos son imposibles, ya que no hay partes distinguidas en dicha estructura.
[La relación entre las clases (puntos alrededor del perímetro) en un gran fajo de tierra de un proyecto de cliente sin nombre.]La interconexión incorrecta de componentes impide la evolución del sistema debido al hecho de que realizar cambios puede afectar de manera impredecible a otras partes del sistema. Todas las arquitecturas evolutivas proporcionan cierto nivel de modularidad, generalmente a nivel de arquitectura técnica (por ejemplo, arquitectura en capas).
Organización en torno a oportunidades de negocio.
Influenciado por los principios del diseño orientado a temas en arquitecturas modernas y exitosas, la modularidad a nivel de dominio se usa cada vez más. Una arquitectura basada en servicios difiere de una arquitectura tradicional orientada a servicios (SOA) principalmente en su estrategia de asignación de servicios. La arquitectura orientada a servicios está estrictamente dividida por niveles técnicos, mientras que las arquitecturas basadas en servicios se construyen principalmente en partes del área temática definida por microservicios.
Los experimentos
La realización de experimentos es una de las ventajas significativas que la arquitectura evolutiva brinda a las empresas. La capacidad de realizar fácilmente pequeños cambios en las aplicaciones proporciona el uso de prácticas comunes de implementación continua, como pruebas A / B, pruebas para un grupo limitado de usuarios (lanzamiento de Canary) y otros. Las arquitecturas de microservicios a menudo se construyen sobre la base de llamadas de servicio de enrutamiento, lo que hace posible utilizar varias versiones del servicio dentro de un ecosistema completo. Esto a su vez abre grandes oportunidades para la experimentación y los cambios en la funcionalidad existente. En última instancia, al desarrollar aplicaciones comerciales, se dedica menos tiempo a discutir planes y retrasos, y el desarrollo se lleva a cabo principalmente en el modo de prueba rápida de hipótesis.
Principios de la arquitectura evolutiva
Se puede obtener una imagen más completa de la arquitectura evolutiva al familiarizarse con sus principios básicos. Estos principios se relacionan con diversas características tanto de la arquitectura en sí como de sus métodos de diseño. Parte de los principios se relaciona con la elección del momento de tomar decisiones arquitectónicas en el proceso de diseño de un sistema.
Función de la aptitud
Es necesario distinguir entre arquitectura emergente (formada como resultado del proceso de diseño) y evolutiva; esto es extremadamente importante. Al igual que los métodos de cálculo evolutivo (como los algoritmos genéticos), la función de adecuación arquitectónica establece un objetivo en el diseño arquitectónico. Para algunos sistemas, el requisito principal es un tiempo de actividad prolongado, para otros, alto rendimiento o seguridad.
[La tabla de radar se usa para resaltar funciones importantes de acondicionamiento físico relevantes para este sistema de software.]
Si predetermina la función de aptitud para un sistema en particular, esto ayudará en el futuro a tomar las decisiones correctas de manera oportuna. Para diferentes soluciones arquitectónicas, puede calcular las funciones físicas, y si su valor mejora, esto significa que la arquitectura se está desarrollando en la dirección correcta.
Atención a los puntos de dolor.
Muchos de los métodos de trabajo utilizados en el suministro continuo de software y el desarrollo de una arquitectura en evolución se basan en el principio de "atención a los puntos débiles" formulado por la comunidad de programación eXtreme. Cuando surgen momentos en el trabajo de diseño que pueden convertirse en fuentes de problemas (puntos débiles), es necesario prestarles atención lo antes posible. Esto ayudará a identificar posibles problemas de antemano y eliminarlos en un orden de trabajo. Al diseñar una arquitectura evolutiva, las prácticas comunes de entrega continua, como la canalización de implementación, el aprovisionamiento automático de máquinas virtuales y la migración de bases de datos, simplifican enormemente la eliminación de los puntos débiles durante la fase de cambio.
Punto de decisión
La principal diferencia entre la arquitectura tradicional y la evolutiva es cuando se toman decisiones importantes. Estas decisiones pueden estar relacionadas con la estructura de la aplicación, la pila de tecnología, las herramientas individuales o los patrones de comunicación. En el caso de diseñar una arquitectura tradicional, tales decisiones se toman en la etapa inicial, antes de escribir el código. En el proceso de desarrollo de la arquitectura evolutiva, las decisiones se toman lo más tarde posible, en el último momento, cuando aún es aceptable. La ventaja de la toma de decisiones posterior es que puede haber información adicional disponible en este momento. Los costos de este método incluyen los costos de un posible refinamiento de la arquitectura después de tomar una decisión. Estos costos pueden reducirse utilizando abstracciones adecuadas, pero aún pueden ocurrir. Sin embargo, los costos de tomar decisiones en la etapa inicial también son bastante reales. Tome, por ejemplo, la decisión de elegir una herramienta de mensajería. Diferentes herramientas admiten diferentes funciones. Si elegimos una herramienta más poderosa de la necesaria, obtenemos una arquitectura mal concebida que inevitablemente requerirá un mayor desarrollo. Esta "deuda técnica", que surge de la selección de la herramienta incorrecta, será una carga adicional para los desarrolladores.
Por supuesto, el principal problema con el último momento posible de tomar una decisión es determinar cuándo llega. Para hacer esto, concéntrate en la función de fitness. En primer lugar, es necesario tomar decisiones que puedan tener un impacto significativo en la elección de elementos de arquitectura o diseño, así como decisiones que afecten significativamente el éxito general del proyecto. El impacto negativo de retrasar tal decisión a menudo supera los posibles beneficios de una decisión posterior.
Conclusión
Los arquitectos de software deben explicar las decisiones tomadas sobre el diseño de los sistemas que se están desarrollando, por regla general, utilizando varios tipos de diagramas. Los desarrolladores de arquitectura a menudo caen en la trampa de presentar la arquitectura de software como la ecuación que necesitan resolver. Muchas herramientas comerciales que ofrecen los arquitectos de software le permiten describir formalmente la arquitectura en forma de cuadrados, líneas y flechas. Aunque estos diagramas pueden ser útiles, ofrecen solo una visualización bidimensional, una instantánea del mundo ideal, pero vivimos en una realidad tetradimensional.
Para llenar tal diagrama bidimensional de vida, es necesario especificarlo. La etiqueta
ORM en un diagrama bidimensional se convierte en
Hibernate v4.2.17 , haciendo que el mundo en
cuestión sea tridimensional. Cuando tenga un plan para su implementación en producción y actualizaciones seis meses después de la inevitable versión de
Hibernate v4.3.0.1 , estará listo para el mundo de cuatro dimensiones. Muchos arquitectos no se dan cuenta de que una visión estática de la arquitectura tiene una vida útil corta. El universo del software existe en un estado continuo; es dinámico, no estático. La arquitectura no es una ecuación, sino más bien una instantánea de un proceso en curso.
Las prácticas de entrega continua de software y DevOps han mostrado problemas derivados de la falta de comprensión de los esfuerzos necesarios para implementar y soportar la arquitectura. Implementar la arquitectura es solo el primer paso.
La arquitectura sigue siendo una abstracción hasta que se pone en práctica. En otras palabras, la viabilidad de cualquier arquitectura a largo plazo se puede juzgar solo cuando no solo la implementó, sino que también la modificó al menos una vez. Y tal vez lograron hacer frente a las sorpresas en el camino.
La comprensión de un arquitecto de software de las capacidades operativas es fundamental para desarrollar una arquitectura evolutiva. El desarrollo evolutivo de la arquitectura afecta las características de su implementación y, por lo tanto, deben tenerse en cuenta en el proceso de finalización. Los requisitos del proceso de entrega continua para la arquitectura tienen como objetivo mejorar su visualización y simplificar los cambios. De esta manera, la entrega continua mejora las capacidades de la arquitectura evolutiva.
El 19 de noviembre, Neil Ford llega a Moscú con una clase magistral
sobre creación de arquitectura de software evolutiva .