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?

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.

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.

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.