Microservicios, dibujados con honestidad

No "qué servicios hay": eso lo hace una lista, y esa lista suele estar en los nombres de los repositorios. La pregunta es: ¿puede desplegarse cualquiera de ellos por su cuenta? Todo lo que la gente espera de los microservicios - versiones independientes, escalado independiente, un equipo que puede entregar sin una reunión de coordinación - se sigue de que la respuesta sea sí, y ninguna otra propiedad del dibujo importa si es no.

Un diagrama de componentes la responde, siempre que dibujes las cosas correctas. Cada servicio desplegable es un componente; cada contrato publicado, una interfaz; cada evento, una «signal». Después tapa un servicio con la mano: si lo que queda especifica del todo su reemplazo, ese servicio puede liberarse a su propio ritmo.

En la figura de arriba, la pasarela depende de IOrders: un contrato síncrono, porque la pasarela no puede responder al usuario sin un pedido. Shipping y billing apuntan a OrderPlaced, una señal que el order service envía y a la que no espera.

Dibujar las dos de forma distinta es todo el valor de la imagen. Las aristas síncronas son donde la disponibilidad se compone: si el order service está caído, la pasarela devuelve un error. Las aristas de evento son donde no: que shipping esté caído retrasa un paquete y no se lleva nada más por delante. Un diagrama que dibuja ambas como flechas simples ha borrado la distinción que decide cómo falla el sistema.

Esto es un monolito distribuido, y es la forma más común en producción. Nada en él es ilegal, nada está mal nombrado, y pasará la revisión porque se parece a cualquier otro diagrama de microservicios. Lo que dice, si lees las flechas en vez de las cajas, es que los cuatro servicios tienen que desplegarse juntos, probarse juntos y estar en pie juntos: así que el equipo ha asumido todos los costes de la distribución y ha conservado todas las restricciones de un monolito.

La señal se puede contar: el número de saltos síncronos en una petición. Uno está bien. Dos suele estar bien. Tres o más y la disponibilidad del conjunto es el producto de las partes, así que cuatro servicios al 99,9 % cada uno dan alrededor del 99,6 % juntos: tres horas al mes en las que nadie puede pedir nada.

Los arreglos se ven en el mismo dibujo. Deja que orders publique un evento y que pricing e inventory reaccionen a él. O fusiona dos de las cajas, que es una respuesta legítima que rara vez se propone. O cachea lo que pricing necesita, para que el salto deje de estar en la ruta de la petición. Las tres son ediciones de este diagrama, y por eso los veinte minutos de dibujarlo antes de construir valen la pena.

La notación está cubierta en la guía del diagrama de componentes, y cinco disposiciones más - incluido el ciclo de dos sentidos que este artículo no repite - están en los ejemplos de diagramas de componentes.