Escalado de monolitos frente a escalado de microservicios

Uno de los argumentos comunes para usar microservicios es una mejor escalabilidad. Pero me pregunto si este argumento es realmente válido.

Digamos que teníamos una aplicación que consta de 10 microservicios con 9 de ellos con cada dos instancias (por redundancia) y uno de ellos con 4 instancias para manejar la carga (escalabilidad). El argumento pro-microservicio es que puede escalar este miroservicio independientemente de los otros servicios.

Sin embargo, supongamos que los 10 microservicios eran módulos en un solo monolito y que se implementaron varias instancias (por ejemplo, 22 como la suma de arriba) de este monolito. El sistema debería poder manejar la carga de la parte crítica, porque hay suficientes instancias para hacerlo. Si las instancias contienen lógica de programa que no es necesaria, el único inconveniente sería que el binario y la cantidad de RAM necesaria serían ligeramente mayores. Pero, de nuevo, la diferencia no debería ser demasiado grande en la mayoría de los casos, al menos no en comparación con el resto de la pila (piense en Spring Boot). La ventaja de un monlith escalado sería un sistema más simple sin (la mayoría de) las falacias de un sistema distribuido.

¿Me estoy perdiendo de algo?

microservices

— deamon
fuente

¿Qué tan grande de monolito estás hablando? Porque creo que podría ser más que una cantidad "ligeramente mayor" de RAM. Sin mencionar el tiempo de implementación: corregir un error podría tomar 22 implementaciones en lugar de 4. Pero tal vez su monolito sea pequeño y las implementaciones no tomen mucho tiempo, las migraciones de la base de datos no toman mucho tiempo, y así sucesivamente.

— Thomas Owens

No he contado líneas de código, pero el monolito tendría varios miles de líneas de código (no un sistema gigante). El punto de partida de mi consideración fue que el tamaño del código de la aplicación real es pequeño en comparación con los grandes marcos como Spring e Hibernate. El número de implementaciones en realidad podría ser menor que con microservicios, porque si tuviera 2 instancias ya tendría redundancia básica y más instancias serían para la escalabilidad.

— deamon

@deamon Tenga en cuenta que con el enfoque monolítico no hay partes del código que estén totalmente inactivas en cada instancia, solo que el código rara vez se usa. Ahora, el código en sí solo puede consumir una pequeña cantidad de memoria, pero si usa muchos objetos almacenados en la memoria, esa cantidad puede crecer sustancialmente.

— Frank Hopkins

Tenga en cuenta que la sobrecarga del "código de ejecución" básico no es necesariamente tan grande como podría saberlo de sus aplicaciones Java, donde a menudo todo el jvm es parte de la imagen del servicio.

— Frank Hopkins

Respuestas:

El objetivo de los microservicios no es reducir la carga del procesador. De hecho, debido a la sobrecarga de comunicación y la repetición de funciones que solían ser código de utilidad global, generalmente aumenta un poco la carga del procesador.

El punto de abolir un monolito es mucho más que ser capaz de mantener, implementar y ejecutar un sistema complejo de funcionalidad en absoluto . Una vez que su sistema alcanza un cierto tamaño, compilando, probando, implementando, etc., un monolito se vuelve demasiado costoso para ser factible mientras mantiene un tiempo de actividad decente. Con microservicios, puede actualizar, reiniciar o revertir un sistema por etapas.

No se equivoque, no escribimos microservicios porque es inherentemente una mejor solución para acoplar cosas libremente en interfaces remotas. De hecho, la pérdida del tipo fuerte y la comprobación de consistencia que un monolito podría proporcionar es a menudo un gran inconveniente. Lo hacemos porque tenemos que hacerlo porque la complejidad nos ha superado y estamos haciendo lo mejor de una situación subóptima.

— Kilian Foth
fuente

Convenido. La razón para pasar a una arquitectura de microservicios es principalmente política. La carga distribuida, el desacoplamiento son consecuencias, no causas. El beneficio real de los microservicios está en el SDLC y el Gobierno. Además de esto, la arquitectura es la respuesta lógica a una necesidad que en la mayoría de los casos proviene de la estrategia de mercado de la compañía. El tiempo de lanzamiento al mercado es más corto que las arquitecturas monolíticas, por lo que la empresa puede adoptar nuevas estrategias, cambiar de una a otra sin problemas y rápidamente

— Laiv

Es por eso que alguien no debería ir directamente a microservicios para aplicaciones medianas y pequeñas, también. La sobrecarga y la complejidad adicional del sistema pueden terminar costando más tiempo, dinero y calidad que un sistema monolítico, en esas escalas.

— T. Sar

"Lo hacemos porque tenemos que hacerlo porque la complejidad nos ha superado y estamos haciendo lo mejor de una situación subóptima." Sí. Para mí, eso lo clava!

— Thomas Junk

Tengo que estar en desacuerdo con la última parte de la respuesta. micro-servicios son inherentemente mejor que un monolito, porque utilizan más de un ordenador

— Ewan

@ewan También puedes usar más de una computadora con monolitos.

— Deamon

En su mayoría tienes razón. Si tiene servicios rápidos que se cargan por igual, puede instalarlos todos en todos los cuadros. No es tan "agradable" como tener una caja por servicio, pero ahorra dinero.

Sin embargo. Tan pronto como tenga un desequilibrio, digamos que el servicio 5 toma el 100% de la CPU durante 2 minutos, desea mover ese servicio a su propia caja para que no bloquee todos los demás servicios si se ejecuta.

Si las llamadas al servicio 5 expiran debido a la carga, solo algunas funciones de su aplicación fallarán en lugar de todas.

Ahora podría hacer lo mismo con un monolito bien modularizado. Instale todos los servicios, pero solo enrute el tráfico del servicio 5 a uno de ellos. Mientras no se enruta el servicio de tráfico 5 a las otras cajas.

Pero por lo general, los monolitos, por su propia naturaleza, no son una colección suelta de servicios que se instalan en la misma caja. Habrá en la memoria llamadas entre los módulos que causarán el fallo de la aplicación.

— Ewan
fuente

El punto de los micro servicios son 1) separación de preocupaciones y 2) distribución de carga. Esencialmente, esto nos libera para hacer el mejor servicio de caja negra que podamos con tecnologías específicas para esa tarea. Nuestros servicios pueden ser políglotas, es decir, escritos en diferentes lenguajes de programación en diferentes pilas. Diferentes equipos pueden trabajar en cada servicio sin saber cómo funcionan los demás más allá del contrato de su API. Esto, en su conjunto, permite una base de código mucho más simple para cada servicio que es más fácil de depurar, comprender y ajustar para el rendimiento.

— Lewis A Sellers
fuente

Estoy de acuerdo en parte. Mi punto no era sobre argumentos para microservicios en general, sino sobre escalabilidad. En mi caso específico, todos los microservicios están escritos en la misma tecnología, por ejemplo. Entonces, si bien sería posible utilizar una tecnología diferente para cada uno, simplemente no es el caso aquí. Quería verificar que no pierdo un punto importante sobre la escalabilidad.

— deamon