Microservicios vs Arquitectura Monolítica [cerrado]

Esta es una pregunta muy importante porque algunas personas se sienten atraídas por todo el zumbido en torno a los microservicios, y hay compensaciones a considerar. Entonces, ¿cuáles son los beneficios y desafíos de los microservicios (en comparación con el modelo monolítico)?

Beneficios

• Deployability: mayor agilidad para implementar nuevas versiones de un servicio debido a ciclos de compilación+prueba+implementación más cortos. Además, la flexibilidad para emplear seguridad, replicación, persistencia y configuraciones de monitoreo.
• Confiabilidad: una falla de microservicio afecta a ese microservicio solo y a sus consumidores, mientras que en el modelo monolítico una falla de servicio puede derribar todo el monolito.
• Disponibilidad : la implementación de una nueva versión de un microservicio requiere poco tiempo de inactividad, mientras que la implementación de una nueva versión de un servicio en el monolito requiere un reinicio típicamente más lento de todo el monolito.
• Escalabilidad : cada microservicio se puede escalar de forma independiente utilizando grupos, clústeres y cuadrículas. Las características de implementación hacen de los microservicios una excelente combinación para la elasticidad de la nube.
• Modificabilidad: más flexibilidad para usar nuevos frameworks, bibliotecas, fuentes de datos y otros recursos. Además, los microservicios son componentes modulares de acoplamiento flexible, solo accesibles a través de sus contratos, y por lo tanto menos propensos a convertirse en una gran bola de barro.
• Gestión : la aplicación desarrollo el esfuerzo se divide entre equipos que son más pequeños y trabajan de manera más independiente.
• Autonomía de diseño: el equipo tiene libertad para emplear diferentes tecnologías, marcos y patrones para diseñar e implementar cada microservicio, y puede cambiar y redistribuir cada microservicio de forma independiente

Desafíos

• Deployability: hay muchas más unidades de despliegue, por lo que hay trabajos, scripts, áreas de transferencia y configuración más complejos archivos a supervisar para el despliegue. (Por esa razón, la entrega continua y DevOps son altamente deseables para proyectos de microservicios.)
• Rendimiento : es más probable que los servicios necesiten comunicarse a través de la red, mientras que los servicios dentro del monolito pueden beneficiarse de las llamadas locales. (Por esa razón, el diseño debe evitar los microservicios "charlatanes".)
• Modificabilidad : es más probable que los cambios en el contrato afecten a los consumidores desplegados en los consumidores de modelos monolíticos tienen más probabilidades de estar dentro del monolito y se implementarán al mismo tiempo que el servicio. Además, los mecanismos para mejorar la autonomía, como la consistencia eventual y las llamadas asincrónicas, agregan complejidad a los microservicios.
• Testability: las pruebas de integración son más difíciles de configurar y ejecutar porque pueden abarcar diferentes microservicios en diferentes entornos de tiempo de ejecución.
• Gestión : aumenta el esfuerzo para gestionar operaciones porque hay más componentes de tiempo de ejecución, archivos de registro e interacciones punto a punto que supervisar.
• Uso de memoria: a menudo se replican varias clases y bibliotecas en cada paquete de microservicios y la huella de memoria general aumenta.
• Autonomía en tiempo de ejecución: en el monolito se coloca la lógica general del negocio. Con los microservicios, la lógica se extiende a través de los microservicios. Por lo tanto, si todo lo demás es igual, es más probable que un microservicio interactúe con otros microservicios a través de la red that esa interacción disminuye la autonomía. Si la interacción entre microservicios implica el cambio de datos, la necesidad de un límite transaccional compromete aún más la autonomía. La buena noticia es que para evitar problemas de autonomía en tiempo de ejecución, podemos emplear técnicas como consistencia eventual, arquitectura impulsada por eventos, CQRS, caché (replicación de datos) y alineación de microservicios con contextos limitados a DDD. Estas técnicas no son inherentes a los microservicios, pero han sido sugerido por prácticamente todos los autores que he leído.

Una vez que entendemos estas compensaciones , hay una cosa más que necesitamos saber para responder a la otra pregunta: ¿qué es mejor, microservicios o monolito? Necesitamos conocer los requisitos no funcionales (requisitos de atributos de calidad) de la aplicación. Una vez que entienda lo importante que es el rendimiento frente a la escalabilidad, por ejemplo, puede sopesar las compensaciones y tomar una decisión de diseño informada.

@Luxo es perfecto. Solo me gustaría ofrecer una ligera variación y lograr la perspectiva organizacional de la misma. Los microservicios no solo permiten que las aplicaciones se desacoplen, sino que también pueden ayudar a nivel organizacional. La organización, por ejemplo, podría dividirse en varios equipos donde cada uno puede desarrollarse en un conjunto de microservicios que el equipo puede proporcionar.

Por ejemplo, en tiendas más grandes como Amazon, es posible que tenga un equipo de personalización, un equipo de comercio electrónico, equipo de servicios de infraestructura, etc. Si desea entrar en microservicios, Amazon es un muy buen ejemplo de ello. Jeff Bezos hizo un mandato para que los equipos se comunicaran con los servicios de otro equipo si necesitaban acceso a una funcionalidad compartida. Ver aquí para una breve descripción.

Además, los ingenieros de Etsy y Netflix también tuvieron un pequeño debate en el día de los microservicios vs monolith en Twitter. El debate es un poco menos técnico, pero puede ofrecer algunos insights también.