Introducción
La elección de un estilo arquitectónico es una de las soluciones técnicas fundamentales en la construcción de un sistema de información. En esta serie de artículos, propongo desmontar los estilos arquitectónicos más populares para aplicaciones de construcción y responder a la pregunta de cuándo es el estilo arquitectónico más preferido. En el proceso, intentaré dibujar una cadena lógica que explique el desarrollo de estilos arquitectónicos desde los monolitos hasta los microservicios.
La última vez hablamos sobre los diferentes tipos de monolitos y cómo usar los componentes para construirlos, tanto los de ensamblaje como los de implementación. Nos hemos ocupado de la arquitectura orientada a servicios.
Ahora finalmente definiremos las principales características de una arquitectura de microservicio.
Relación de arquitecturas
Debe entenderse que, según los datos de los artículos de definiciones anteriores, cualquier servicio es un componente, pero no todos los servicios son un microservicio.
Características de una arquitectura de microservicio
Las principales características de una arquitectura de microservicio son:
- Organizado en torno a las capacidades comerciales
- Productos, no proyectos
- Puntos finales inteligentes y tuberías tontas
- Gobernanza descentralizada
- Gestión de datos descentralizada
- Automatización de infraestructura
- Diseño para el fracaso
- Diseño evolutivo
El primer punto proviene de la Arquitectura Orientada a Servicios, porque los microservicios son un caso especial de servicios. Otros puntos merecen un examen aparte.
Organizado en torno a las capacidades comerciales
Ahora es necesario recordar la ley de Conway: las organizaciones que crean sistemas organizan su arquitectura, copiando la estructura de interacción dentro de estas organizaciones. Como ejemplo, podemos recordar el caso de la creación de un compilador: un equipo de siete personas desarrolló un compilador de siete pasos y un equipo de cinco desarrolló un compilador de cinco pasos.
Si hablamos de monolitos y microservicios, entonces si el desarrollo está organizado por departamentos funcionales (backend, frontend, administradores de bases de datos), obtenemos un monolito clásico.
Para obtener microservicios, los equipos deben organizarse por oportunidad comercial (pedido, envío, equipo de catálogo). Esta organización permite que los equipos se concentren en crear partes específicas de la aplicación.
Productos, no proyectos
Un enfoque de proyecto en el que el equipo transfiere la funcionalidad desarrollada a otros equipos en el caso de una arquitectura de microservicio es completamente inadecuado. El equipo debe respaldar el sistema durante todo su ciclo de vida. Amazon, uno de los buques insignia de la adopción de microservicios, declaró: “tú construyes, lo ejecutas”. El enfoque de producto permite que el equipo sienta las necesidades del negocio.
Puntos finales inteligentes y tuberías tontas
La arquitectura SOA ha prestado mucha atención a los canales de comunicación, en particular al Enterprise Service Bus (bus de servicio empresarial). Lo que a menudo conduce a la caja de espagueti errónea, es decir, la complejidad del monolito se convierte en la complejidad de las conexiones entre los servicios. La arquitectura de microsevicios usa solo métodos de comunicación simples.
Gobernanza descentralizada
Las decisiones clave para los microservicios deben tomarlas las personas que realmente desarrollan microservicios. Aquí, las decisiones clave significan la elección
de lenguajes de programación, metodología de implementación, contratos de interfaz pública, etc.
Gestión de datos descentralizada
El enfoque estándar, en el que una aplicación se basa en una única base de datos, no puede tener en cuenta las características específicas de cada servicio específico. MSA asume la gestión de datos descentralizada, hasta el uso de diversas tecnologías.
Automatización de infraestructura
MSA admite procesos de implementación y entrega continuos. Esto solo se puede hacer automatizando procesos. Al mismo tiempo, el despliegue de una gran cantidad de servicios ya no parece algo aterrador. El proceso de implementación debería volverse aburrido. El segundo aspecto está relacionado con la gestión de servicios en el entorno del producto. Sin automatización, la gestión de procesos que se ejecutan en diferentes entornos operativos se vuelve imposible.
Diseño para el fracaso
Numerosos servicios de MSA son propensos a fallar. Al mismo tiempo, el manejo de errores en un sistema distribuido no es una tarea trivial. La arquitectura de la aplicación debe ser resistente a tales fallas. Rebecca Parsons cree que es muy importante que ya no usemos la comunicación en proceso entre servicios, sino que usamos HTTP para la comunicación, que no es tan confiable.
Diseño evolutivo
La arquitectura del sistema MSA debe evolucionar. Es deseable limitar los cambios necesarios a los límites de un servicio. También es necesario considerar el impacto en otros servicios. El enfoque tradicional es intentar solucionar este problema con el control de versiones, pero MSA sugiere usar el control de versiones como
último recurso.
Conclusión
Después de todo lo anterior, podemos formular qué son los microservicios. La arquitectura de microservicio es un enfoque para desarrollar una aplicación individual como una colección de pequeños servicios, cada uno de los cuales se ejecuta en su propio proceso e interactúa a través de mecanismos ligeros, a menudo una API de recursos HTTP. Estos servicios se basan en capacidades comerciales y se pueden implementar de forma independiente mediante un
motor de implementación totalmente 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 diferentes tecnologías de almacenamiento. Leer parte 2
