Hola, Habr. Hoy continuo la serie de publicaciones que escribí especialmente para el inicio de un nuevo flujo del curso. .
Introducción
La elección del estilo arquitectónico es una de las decisiones técnicas fundamentales al construir un sistema de información. En esta serie de artículos, propongo analizar los estilos arquitectónicos más populares para la construcción de aplicaciones y responder a la pregunta de cuándo es preferible un estilo arquitectónico en particular. A lo largo de la exposición, intentaré establecer una cadena lógica que explique el desarrollo de estilos arquitectónicos desde monolitos hasta microservicios.
La vez pasada hablamos sobre los diferentes tipos de monolitos y sobre el uso de componentes para su construcción, tanto de componentes de ensamblaje como de despliegue. Analizamos la arquitectura orientada a servicios.
Ahora finalmente definiremos las características principales de la arquitectura de microservicios.
Relación de arquitecturas
Es necesario entender que, según los datos de los artículos anteriores, cualquier servicio es un componente, pero no cualquier servicio es un microservicio.
Características de la arquitectura de microservicios
Las características principales de la arquitectura de microservicios son:
- Organización en torno a las capacidades del negocio (Organized around Business Capabilities)
- Productos, no proyectos (Products not Projects)
- Puntos de entrada inteligentes y canales tontos (Smart endpoints and dumb pipes)
- Gobernanza descentralizada (Decentralized Governance)
- Gestión descentralizada de datos (Decentralized Data Management)
- Automatización de la infraestructura (Infrastructure Automation)
- Diseño para la falla (Design for failure)
- Arquitectura con desarrollo evolutivo (Evolutionary Design)
El primer punto proviene de la arquitectura orientada a servicios, porque los microservicios son un caso particular de los servicios. Los otros puntos merecen consideración aparte.
Organización en torno a las capacidades del negocio (Organized around Business Capabilities)
Ahora es necesario recordar la ley de Conway: las organizaciones que crean sistemas organizan su arquitectura de manera que imita la estructura de interacción dentro de esas organizaciones. Como ejemplo, podemos recordar el caso de la creación de un compilador: un equipo de siete personas desarrolló un compilador de siete pasadas, mientras que un equipo de cinco hizo uno de cinco pasadas.
Si hablamos de monolitos y microservicios, en el caso de que el desarrollo esté organizado por departamentos funcionales (backend, frontend, administradores de bases de datos), se obtiene un monolito clásico.
Para obtener microservicios, es necesario organizar los equipos en torno a las capacidades del negocio (equipo de pedidos, envíos, catálogo). Esta organización permitirá a los equipos centrarse en la creación de partes específicas de la aplicación.
Productos, no proyectos (Products not Projects)
El enfoque de proyecto en el que un equipo transfiere funcionalidad desarrollada a otros equipos en el caso de una arquitectura de microservicios no es adecuado. El equipo debe mantener el sistema a lo largo de todo su ciclo de vida. Amazon, uno de los pioneros en la implementación de microservicios, declaró: «usted construye el producto y también lo lanza» («you build, you run it»). Este enfoque centrado en el producto permite al equipo sentir las necesidades del negocio.
Puntos de entrada inteligentes y canales tontos (Smart endpoints and dumb pipes)
La arquitectura SOA prestaba mucha atención a los canales de comunicación, en particular a la Enterprise Service Bus (autobús de servicio empresarial). Esto a menudo conduce a un Erroneous Spaghetti Box, es decir, la complejidad del monolito se transforma en la complejidad de las relaciones entre servicios. En una arquitectura de microservicios se utilizan únicamente métodos simples de interacción.
Gobernanza descentralizada (Decentralized Governance)
Las decisiones clave sobre los microservicios deben ser tomadas por las personas que realmente desarrollan los microservicios. Aquí, las decisiones clave se refieren a la elección
de lenguajes de programación, metodología de implementación, contratos de interfaces públicas, etc.
Gestión descentralizada de datos (Decentralized Data Management)
El enfoque estándar, en el que una aplicación se basa en una única base de datos, no puede tener en cuenta las particularidades de cada servicio específico. MSA implica una gestión descentralizada de los datos, incluso utilizando diferentes tecnologías.
Automatización de la infraestructura (Infrastructure Automation)
MSA apoya procesos de despliegue y entrega continua. Esto solo es posible mediante la automatización de procesos. De este modo, el despliegue de una gran cantidad de servicios ya no se percibe como algo aterrador. El proceso de despliegue debe volverse rutinario. El segundo aspecto está relacionado con la gestión de servicios en un entorno de producción. Sin automatización, la gestión de procesos en diferentes entornos operativos se vuelve inviable.
Diseño para la falla (Design for failure)
Los numerosos servicios de MSA son propensos a fallos. Sin embargo, el manejo de errores en un sistema distribuido es una tarea bastante no trivial. La arquitectura de las aplicaciones debe ser resistente a tales fallos. Rebecca Parsons considera muy importante que ya no utilicemos ni siquiera la interacción dentro del proceso entre servicios; en su lugar, recurrimos a HTTP, que no es ni de cerca tan confiable.
Arquitectura con desarrollo evolutivo (Evolutionary Design)
La arquitectura del sistema MSA debe evolucionar de manera gradual. Es preferible limitar los cambios necesarios a los límites de un solo servicio. También es importante considerar el impacto en otros servicios. El enfoque tradicional consiste en intentar resolver este problema mediante la gestión de versiones, pero MSA sugiere utilizar la gestión de versiones como
una medida extrema.
Conclusión
Después de todo lo anterior, se puede definir qué son los microservicios. La arquitectura de microservicios es un enfoque para el desarrollo de una aplicación individual como un conjunto de pequeños servicios, cada uno de los cuales funciona en su propio proceso e interactúa a través de mecanismos ligeros, a menudo mediante una interfaz de programación de aplicaciones (API) sobre recursos HTTP. Estos servicios están construidos sobre capacidades comerciales y pueden ser desplegados de manera independiente utilizando un mecanismo de despliegue completamente
automatizado. Existe un nivel mínimo de gestión centralizada de estos servicios, que pueden estar escritos en diferentes lenguajes de programación y utilizar diversas tecnologías de almacenamiento de datos.
Fuente: habr.com
