La gestión de los sistemas distribuidos siempre es difícil, con cada adición en el número de microservicios las posibilidades de fallas se incrementan de forma exponencial.
Supongamos que un viejo sistema monolítico estaba funcionando con un 99.0% de disponibilidad SLO (Service Level Objective) – con sólo un 1% de fallas permitidas.
Cuando este sistema monolítico se desintegra en 10 microservicios, los números en la disponibilidad simplemente se reducen al 90.0% con un 10% de posibilidades de fallas, estos no son números que se puedan considerar buenos.
Y no sólo se trata de la reducción de la disponibilidad si el monolito falla, sino que las fallas también suelen impactar a toda la aplicación, provocando que el sistema congele todas sus operaciones.
Afortunadamente, los pasos de restauración han sido bastante sencillos sin afectar al estado de los datos de la aplicación.
Hay miles de artículos que ilustran todas las cuestiones relacionadas con los microservicios y cómo mejorarlos. A continuación presento algunas observaciones de mi experiencia personal hasta el momento.
El costo de la disponibilidad
Las comunicaciones entre los sistemas en los microservicios se realizan principalmente mediante mensajes, y por lo general hay dos maneras de tratar los mensajes, ya que cada mensaje añade un retraso al sistema debido a que requiere procesamiento:
- Rápido pero poco fiable – Se envían las copias de mensajes a varios suscriptores que pueden ser enviados rápidamente. Aunque los sistemas recibirán mensajes duplicados de estados fallidos y mensajes faltantes, es una forma de comunicación poco fiable pero rápida.
- Lento y fiable – La fiabilidad sólo puede construirse con una versión estable de los mensajes guardados en los sistemas para ser procesados más tarde, incluye el envío de un recibo o acuse de recibo también. Esto es importante en sistemas que manejan transacciones que no pueden perderse de ninguna manera y necesitan mantener el orden de la comunicación
No sólo con los mensajes, el equilibrio entre fiabilidad y velocidad debe hacerse con las API, especialmente en torno a las capas de BFF que se han transformado de sistemas estables basados en sesiones, pero que aún tienen que mantener algún tipo de orden/visibilidad para evitar que las operaciones del CRUD fallen en las transacciones.
No hay una única fuente de verdad (SSoT)
Este ha sido un problema común en el mundo de los microservicios, ya que los datos son transmitidos entre sistemas no existe una base de datos global o un almacenamiento común al que referirse. Cada sistema ha estado viviendo en una “vieja verdad” con una copia de su propia base de datos/memoria.
La forma más fácil de hacer frente a esto es el registro de eventos y las técnicas de replicación de datos. Aunque en los casos en que el tiempo es más importante -los sistemas terminan usando la misma base de datos en microservicios para tener una visión única de la verdad (SVoT) si la fuente no es posible. Incluso con eso nunca estamos seguros de que los datos sean lo suficientemente consistentes para tener los SLOs adecuados adaptados a ellos.
Reintentos en todas partes
Mas que la falla en sí, la recuperación de las fallas ha sido lo más costoso en el mundo de los microservicios – cada reintento en un punto de falla puede inundar los sistemas con solicitudes/mensajes/transacciones causando efectos mariposa o dominó debido a la cantidad de comunicación existente entre todos los sistemas.
Hay que tener cuidado con el número correcto de umbrales de reintentos y a menudo hay que tener retrasos entre los reintentos con el algoritmo correcto para evitar la inundación de la red. Aquí es donde necesitamos identificar y utilizar el interruptor correcto para manejar tales casos y evitar que los recursos del sistema se agoten en la recuperación misma.
Visibilidad
A menudo, cuando construimos un sistema de microservicios, con tantos componentes orquestados, a veces nos cegamos con tantos datos alrededor. Con la velocidad de los sistemas distribuidos sin estado, ¿Tenemos una visión correcta de los problemas, registros en mano? Sería imposible rastrear los problemas y depurarlos sin un ID de correlación y las herramientas adecuadas para rastrear cada solicitud de HTTP.
Optimismo
Con el movimiento hacia la arquitectura MACH, el enfoque de los Microservicios, la API como prioridad “API-first”, la Nube nativa y los sistemas “headless” – todavía hay asombro en todos.
Hay un optimismo poco realista y la esperanza de que los microservicios funcionarán bien en producción.
Al no estar todavía probados a un nivel que permita esperar que los sistemas fallen, es necesario que se sigan prácticas y enfoques de ingeniería del caos para probar y construir los sistemas. Herramientas creadas que generar fallos intencionales como el “monkey chaos” o “litmus chaos” deben ser utilizadas como parte de la búsqueda de debilidades y fallas en los sistemas.
En resumen, la administración de un sistema distribuido sin estado “stateless” no debe ser subestimada. Y definitivamente no deberíamos esperar que sea infalible. Las aplicaciones que migran hacia los microservicios deben ser construidas en pequeño e ir creciendo lentamente ganando poco a poco más confiabilidad.
Autor: Prateek Srivastava
Lead Solutions Architect / Engineering Manager
Artículo original: https://www.linkedin.com/pulse/reliability-engineering-microservices-prateek-srivastava/