Características de una arquitectura de microservicios

El estilo arquitectónico de microservicio es un enfoque para desarrollar una sola aplicación como un conjunto de servicios pequeños, cada uno que se ejecuta en su propio proceso y se comunica con mecanismos ligeros, a menudo una API de recursos HTTP.
Estos servicios se basan en las capacidades del negocio y se pueden implementar de forma independiente mediante maquinaria de implementación totalmente automatizada.
Hay un mínim de gestión centralizada de estos servicios, que puede escribirse en diferentes lenguajes de programación y utilizar diferentes tecnologías de almacenamiento de datos.

Es mejor utilizar algún paradigma del mundo real, como un usuario se refiere a un "Sistema estéreo". Lo mueven, lo fijan en otro lugar. Mueva, quite y conecte diferentes altavoces.
Básicamente un componente es algo que es actualizable y reemplazable de forma independiente.
La diferencia es simplemente que los servicios no se incorporan directamente a su código base, sino que se llaman a través de llamadas remotas.

Muchas organizaciones estructuran sus equipos en torno a la tecnología: especialistas de interfaz de usuario, equipo de middleware, DBAs.
Más bien, con los microservicios, las personas deben organizarse en torno a las capacidades empresariales dentro de los equipos multifuncionales: como el "equipo de envío", el "equipo de pedidos".
Microservicios se trata mucho más de la organización del equipo que de la arquitectura de software. La arquitectura y la organización del equipo siemper están muy unidas.

Es una práctica común utilizar infraestructura de red inteligente como ESB que contiene lógica sobre cómo tratar ciertos mensajes de red y cómo entutarlos.
En su lugar, los microservicios facilitan los pipes tontos y los endpoints/aplicaciones inteligentes.
El problema es que los pipes inteligentes (es decir, ESB) conducen a problemas con la entrega continua, ya que no se pueden controlar o integrar fácilmente en un pipe grande.
Además, crea dependencias con la propia aplicación, lo que significa que cuando decide actualizar el endpoint o servicio, a menudo también tiene que realizar algún trabajo en el ESB.

Normalmente, en un sistema monolito hay una enorme base de datos donde se almacenan todos los datos. A menudo incluso hay varios monolitos que se conectan a la misma base de datos.
En un enfoque orientado a servicios, cada servicio obtiene su propia base de datos y los datos no se comparten directamente con otros. Compartir tiene que pasar por el servicio que envuelve los datos. Esto conduce a una gran flexibilidad beneficiosa por parte del servicio, ya que puede decidir qué tecnología adoptar, qué sistema DBMS, etc.

La entrega continua es una necesidad, así como mecanimos automatizados para el aprovisionamiento de máquinas, para implementación, pruebas, etc.

Inevitablemente se tiene que diseñar para el error, ya que los microservicios fallarán, incluso con frecuencia.
Netflix es famoso por llevar esto al extremo. Tienen un "Chaos Monkey" que se ejecuta sobre su sistema de producción durante el día y cierra al azar los servicios.
Aunque muchas personas tienden a abstraer y ocultar llamadas remotas, no puede esperar que funcionen como llamadas normales. Espere que fracasen en lugar de tener éxito. Ley de Murphy.

La mayoría de los esfuerzos de desarrollo de aplicaciones que vemos utilizan un modelo de proyecto: donde el objetivo es entregar algún software que luego se considera completado. Al finalizar, el software se entrega a una organización de mantenimiento y el equipo del proyecto que lo creó se disuelve.
Los defensores de microservicios tienden a evitar este modelo, prefiriendo en su lugar la noción de que un equipo debe poseer un producto a lo largo de toda su vida útil.
Una inspiración común para esto es la noción de Amazon de "usted construye, usted lo ejecuta" donde un equipo de desarrollo asume toda la responsabilidad por el software en producción. Esto lleva a los desarrolladores al contacto diario con el modoen que su software se comporta en producción y aumenta el contacto con sus usuarios, ya que tienen que asumir al menos parte de la carga de soporte.

Una de las consecuencias de la gobernanza centralizada es la tendencia a estandarizarse en plataformas tecnológicas únicas. La experiencia demuestra que este enfoque es restrictivo - no todos los problemas son un clavo y no todas las soluciones un martillo.
En lugar de utilizar un conjunto de estándares definidos escritos en algún lugar en papel prefieren la idea de producir herramientas útiles que otros desarrolladores pueden utilizar para resolver problemas similares a los que están enfrentando. No tenemos que amarrarnos a única tecnología.

Cada vez que intenta dividir un sistema de software en componentes, se enfrenta a la decisión de cómo dividir las piezas ¿cúales son los principios sobre los que decidimos cortar nuestra aplicación? La propiedad clave de un componente es la noción de reemplazo independiente y capacidad de actualización.
Este énfasis en la reemplazabilidad es un caso especial de un principio más general del diseño modular. Si se encuentra cambiando repetidamente dos servicios juntos, eso es una señal de que deben combinarse.

Javier Guerrero