architecture - monolithic - Microservicios: ¿cuáles son los pros y los contras?
microservices tutorial (2)
Pros
Sam Newman en Building Microservices , enumera los beneficios clave de Microservices de la siguiente manera:
Heterogeneidad tecnológica
Con un sistema compuesto por múltiples servicios de colaboración, podemos decidir utilizar diferentes tecnologías dentro de cada uno. Esto nos permite elegir la herramienta adecuada para cada trabajo, en lugar de tener que seleccionar un enfoque más estandarizado y de talla única que a menudo termina siendo el denominador común más bajo.
Resistencia
Un concepto clave en la ingeniería de resiliencia es el mamparo . Si uno de los componentes de un sistema falla, pero esa falla no cae en cascada, puede aislar el problema y el resto del sistema puede seguir funcionando. Los límites del servicio se convierten en sus mamparos obvios. En un servicio monolítico, si el servicio falla, todo deja de funcionar. Con un sistema monolítico, podemos ejecutar en múltiples máquinas para reducir nuestra posibilidad de fallar, pero con microservicios, podemos construir sistemas que manejen la falla total de los servicios y degraden la funcionalidad en consecuencia.
Escalada
Con un servicio grande y monolítico, tenemos que escalar todo juntos. Una pequeña parte de nuestro sistema general tiene un rendimiento limitado, pero si ese comportamiento está bloqueado en una aplicación monolítica gigante, tenemos que manejar la escala de todo como una pieza. Con servicios más pequeños, podemos escalar aquellos servicios que necesitan escalar, lo que nos permite ejecutar otras partes del sistema en hardware más pequeño y menos potente.
Facilidad de implementación
Un cambio de una línea a una aplicación monolítica de un millón de líneas requiere que se despliegue toda la aplicación para liberar el cambio. Eso podría ser un despliegue de alto impacto y alto riesgo. En la práctica, las implementaciones de alto impacto y alto riesgo terminan ocurriendo con poca frecuencia debido a un temor comprensible.
Con los microservicios, podemos hacer un cambio a un solo servicio y desplegarlo independientemente del resto del sistema. Esto nos permite desplegar nuestro código más rápido. Si se produce un problema, se puede aislar rápidamente a un servicio individual, lo que hace que sea fácil lograr una rápida reversión.
Alineación Organizacional
Los microservicios nos permiten alinear mejor nuestra arquitectura con nuestra organización, ayudándonos a minimizar el número de personas que trabajan en cualquier base de código para alcanzar el punto óptimo del tamaño y la productividad del equipo. También podemos cambiar la propiedad de los servicios entre equipos para tratar de mantener a las personas que trabajan en un solo servicio.
Composabilidad
Una de las promesas clave de los sistemas distribuidos y las arquitecturas orientadas a servicios es que abrimos oportunidades para la reutilización de la funcionalidad. Con los microservicios, permitimos que nuestra funcionalidad se consuma de diferentes maneras para diferentes propósitos. Esto puede ser especialmente importante cuando pensamos en cómo nuestros consumidores usan nuestro software.
Optimización de la capacidad de sustitución
Si trabaja en una organización de tamaño mediano o más grande, es probable que esté al tanto de algún sistema legado grande y desagradable que se encuentra en la esquina. El que nadie quiere tocar. El que es vital para el funcionamiento de su empresa, pero que está escrito en una extraña variante de Fortran y se ejecuta solo en hardware que llegó al final de su vida hace 25 años. ¿Por qué no ha sido reemplazado? Ya sabes por qué: es un trabajo demasiado grande y arriesgado.
Dado que nuestros servicios individuales son pequeños en tamaño, el costo de reemplazarlos con una mejor implementación, o incluso eliminarlos por completo, es mucho más fácil de administrar.
Contras
La desventaja más importante de los microservicios es que tienen todas las complejidades asociadas de los sistemas distribuidos, y si bien hemos aprendido mucho sobre cómo administrar bien los sistemas distribuidos, todavía es difícil. Si viene desde un punto de vista de sistema monolítico, tendrá que mejorar mucho el manejo de la implementación, las pruebas y el monitoreo para desbloquear los beneficios. También deberá pensar de manera diferente acerca de cómo escalar sus sistemas y asegurarse de que sean resistentes. Tampoco se sorprenda si las cosas como las transacciones distribuidas o el teorema de CAP comienzan a causarle dolores de cabeza.
Observaciones finales
Sólo citando a Martin Fowler :
Un argumento razonable que hemos escuchado es que no debe comenzar con una arquitectura de microservicios. En su lugar, comience con un monolito, manténgalo modular y divídalo en microservicios una vez que el monolito se convierta en un problema.
¿Cuáles son las ventajas y desventajas de usar microservicios en comparación con arquitecturas alternativas? ¿Hay una regla de oro cuando se deben usar microservicios?
Los profesionales de los microservicios son que sus aplicaciones se escalan muy bien. Usted divide su aplicación en pequeños servicios. Es difícil decidir qué servicios limitados necesitará. Pero una vez que haya hecho esto, puede escalar fácilmente servicios específicos hasta varias veces (los servicios que realmente reciben la mayor carga) en lugar de tener que escalar toda su aplicación.
Otra ventaja es que es más fácil para los nuevos desarrolladores comenzar a crear nuevas funciones para su aplicación, ya que todo se divide en estos servicios separados -> Cada servicio tiene su propia base de código (pequeña).
La mayor desventaja de usar microservicios es, por supuesto, que hay una mayor probabilidad de falla durante la comunicación entre los diferentes servicios.
El uso de microservicios por lo general solo comienza a pagar cuando su aplicación es demasiado grande para mantenerla como una aplicación monolítica. Intente comenzar como monolítico, pero tenga en cuenta sus contextos limitados mientras desarrolla (intente mantenerlo lo más separado posible) para migrar a microservicios si es necesario más adelante.