Microservicios frente a arquitectura monolítica [cerrado]

Leí un poco sobre microservicios y estoy un poco intrigado. Parece que es un concepto interesante. Pero me pregunto cuáles son las ventajas y desventajas del uso de microservicios sobre la arquitectura monolítica y viceversa.

Cuándo los microservicios son más adecuados y dónde ir mejor con la arquitectura monolítica.

Si bien soy relativamente nuevo en el mundo de los microservicios, intentaré responder su pregunta lo más completa posible.

Cuando utilice la arquitectura de microservicios, tendrá un mayor desacoplamiento y separación de preocupaciones. Dado que está dividiendo literalmente su aplicación.

Esto da como resultado que su base de código será más fácil de administrar (cada aplicación es independiente de las otras aplicaciones para mantenerse en funcionamiento). Por lo tanto, si lo hace correctamente , en el futuro será más fácil agregar nuevas funciones a su aplicación. Mientras que con una arquitectura monolítica, podría resultar muy difícil de hacer si su aplicación es grande (y puede asumir que en algún momento lo será).

Además, la implementación de la aplicación es más fácil , ya que está construyendo los microservicios independientes por separado y implementándolos en servidores separados. Esto significa que puede crear e implementar servicios cuando lo desee sin tener que reconstruir el resto de su aplicación.

Dado que los diferentes servicios son pequeños y se implementan por separado, es obvio que es más fácil escalarlos , con la ventaja de que puede escalar servicios específicos de su aplicación (con un monolítico, escala la "cosa" completa, incluso si es solo una parte específica dentro del aplicación que está recibiendo una carga excesiva).

Sin embargo, para aplicaciones que no están destinadas a ser demasiado grandes para administrarlas en el futuro. Es mejor mantenerlo en la arquitectura monolítica. Dado que la arquitectura de microservicios tiene serias dificultades involucradas. Dije que es más fácil implementar microservicios, pero esto solo es cierto en comparación con los grandes monolitos. Al usar microservicios, tiene la complejidad adicional de distribuir los servicios a diferentes servidores en diferentes ubicaciones y necesita encontrar una manera de administrar todo eso. La creación de microservicios lo ayudará a largo plazo si su aplicación se vuelve grande, pero para aplicaciones más pequeñas, es más fácil mantenerse monolítico.

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

Beneficios

• Implementación : más agilidad para implementar nuevas versiones de un servicio debido a ciclos más cortos de compilación + prueba + implementación. Además, flexibilidad para emplear configuraciones de seguridad, replicación, persistencia y monitoreo específicas del servicio.
• Fiabilidad : 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 : implementar una nueva versión de un microservicio requiere poco tiempo de inactividad, mientras que implementar una nueva versión de un servicio en el monolito requiere un reinicio generalmente más lento de todo el monolito.
• Escalabilidad : cada microservicio se puede escalar de forma independiente mediante grupos, clústeres y cuadrículas. Las características de implementación hacen que los microservicios se adapten perfectamente a la elasticidad de la nube.
• Modificabilidad : más flexibilidad para usar nuevos marcos, bibliotecas, fuentes de datos y otros recursos. Además, los microservicios son componentes modulares de acoplamiento flexible a los que solo se puede acceder a través de sus contratos y, por lo tanto, son menos propensos a convertirse en una gran bola de barro.
• Gestión : el esfuerzo de desarrollo de aplicaciones se divide entre equipos que son más pequeños y trabajan de forma 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 volver a implementar cada microservicio de forma independiente.

Desafíos

• Implementación : hay muchas más unidades de implementación, por lo que hay trabajos, scripts, áreas de transferencia y archivos de configuración más complejos para supervisar la implementación. (Por esa razón, la entrega continua y DevOps son muy 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 "parlanchines").
• Modificabilidad : es más probable que los cambios en el contrato afecten a los consumidores implementados en otros lugares, mientras que en el modelo monolítico es más probable que los consumidores estén 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.
• Capacidad de prueba: las pruebas de integración son más difíciles de configurar y ejecutar porque pueden abarcar diferentes microservicios en diferentes entornos de ejecución.
• Administración : el esfuerzo para administrar las operaciones aumenta porque hay más componentes en tiempo de ejecución, archivos de registro e interacciones punto a punto que supervisar.
• Uso de memoria : varias clases y bibliotecas a menudo se replican en cada paquete de microservicios y aumenta la huella de memoria general.
• Autonomía en tiempo de ejecución : en el monolito se ubica la lógica empresarial general. Con los microservicios, la lógica se distribuye entre los microservicios. Entonces, en igualdad de condiciones, es más probable que un microservicio interactúe con otros microservicios a través de la red; esa interacción disminuye la autonomía. Si la interacción entre microservicios implica cambiar 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 la coherencia eventual, la arquitectura basada en eventos, CQRS, la caché (replicación de datos) y la alineación de microservicios con contextos delimitados por DDD. Estas técnicas no son inherentes a los microservicios, pero han sido sugeridas 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: ¿cuál es mejor, microservicios o monolito? Necesitamos conocer los requisitos no funcionales (requisitos de atributos de calidad) de la aplicación. Una vez que comprenda la importancia del rendimiento frente a la escalabilidad, por ejemplo, puede sopesar las compensaciones y tomar una decisión de diseño informada.

@Luxo da en el clavo. Solo me gustaría ofrecer una pequeña variación y lograr la perspectiva organizativa de la misma. Los microservicios no solo permiten desacoplar las aplicaciones, 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, puede tener un equipo de personalización, un equipo de comercio electrónico, un equipo de servicios de infraestructura, etc. Si desea ingresar a los microservicios, Amazon es un muy buen ejemplo de ello. Jeff Bezos estableció como un mandato para los equipos comunicarse con los servicios de otro equipo si necesitaban acceso a una funcionalidad compartida. Vea aquí para una breve descripción.

Además, los ingenieros de Etsy y Netflix también tuvieron un pequeño debate en la época de los microservicios frente al monolito en Twitter. El debate es un poco menos técnico, pero también puede ofrecer algunas ideas.