microservices - sistema - Microservicios vs arquitectura monolítica

microservicios c# (3)

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 de usar microservicios sobre la arquitectura monolítica, y viceversa?

Cuando los microservicios se adaptan mejor, y dónde mejor ir con la arquitectura monolítica.

@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 desacoplar las aplicaciones, sino que también pueden ayudar a nivel organizacional. La organización, por ejemplo, podría dividirse en múltiples 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, un equipo de servicios de infraestructura, etc. Si desea ingresar a los microservicios, Amazon es un muy buen ejemplo de ello. Jeff Bezos hizo un mandato para que los equipos se comuniquen con los servicios de otro equipo si necesitaban acceso a una funcionalidad compartida. Ver here 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 frente al monolito en Twitter. El debate es un poco menos técnico, pero también puede ofrecer algunas ideas.

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

Implementabilidad : más agilidad para implementar nuevas versiones de un servicio debido a ciclos más cortos de construcció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 solo a ese microservicio 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 típicamente más lento de todo el monolito.
Escalabilidad : cada microservicio se puede escalar de forma independiente mediante grupos, agrupaciones y cuadrículas. Las características de implementación hacen que los microservicios sean una excelente combinación para 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 sueltos, solo accesibles a través de sus contratos, y por lo tanto menos propensos a convertirse en una gran bola de lodo.
Administración : el esfuerzo de desarrollo de aplicaciones se divide en 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 volver a implementar cada microservicio de forma independiente

Desafíos

Implementabilidad : hay muchas más unidades de implementación, por lo que hay trabajos más complejos, scripts, áreas de transferencia y archivos de configuración para supervisar la implementación. (Por esa razón, la entrega continua y DevOps son muy deseables para proyectos de microservicios).
Rendimiento : es 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 microservicios "habladores").
Modificabilidad : es más probable que los cambios en el contrato afecten a los consumidores desplegados en otros lugares, mientras que en el modelo monolítico los consumidores tienen más probabilidades de estar dentro del monolito y se implementarán en sintonía con 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 tiempo de ejecución.
Administración : el esfuerzo para administrar las operaciones aumenta porque hay más componentes de tiempo de ejecución, archivos de registro e interacciones punto a punto para supervisar.
Uso de la memoria : muchas clases y bibliotecas a menudo se replican en cada paquete de microservicios y la huella de memoria general aumenta.
Autonomía de tiempo de ejecución : en el monolito, la lógica general del negocio está colocada. Con microservicios, la lógica se extiende a través de microservicios. Entonces, 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; 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 la consistencia eventual, la arquitectura basada en eventos, CQRS, caché (replicación de datos) y la alineación de microservicios con contextos limitados 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 comprendamos estas compensaciones , hay una cosa más que debemos saber para responder a la otra pregunta: ¿cuál es mejor, microservicios o monolitos? 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.

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

Cuando utiliza la arquitectura de microservicios, habrá aumentado el desacoplamiento y la separación de las preocupaciones. Ya que literalmente está dividiendo 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 hace esto correctamente , será más fácil en el futuro agregar nuevas funciones a su aplicación. Mientras que con una arquitectura monolítica, podría ser algo muy difícil de hacer si su aplicación es grande (y puede suponer que en algún momento lo será).

También es más fácil implementar la aplicación , ya que está creando los microservicios independientes por separado y los está implementando 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 algunas dificultades serias involucradas. Dije que es más fácil implementar microservicios, pero esto solo es cierto en comparación con los grandes monolitos. Al utilizar 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 hace grande, pero para aplicaciones más pequeñas, es más fácil mantenerse monolítico.