Parece que el pico de exageración por los microservicios ha quedado atrás. Ya no leemos publicaciones varias veces a la semana sobre "Cómo moví mi monolito a 150 servicios". Ahora escucho pensamientos más sensatos: "No odio el monolito, sólo me importa la eficiencia". Incluso observamos varias migraciones. . Al pasar de una aplicación grande a varios servicios más pequeños, tendrá que resolver varios problemas nuevos. Enumerémoslos lo más brevemente posible.
Marco: de la química básica a la mecánica cuántica
Configurar una base de datos básica y una aplicación con un proceso en segundo plano fue un proceso bastante sencillo. Publico el archivo Léame en Github y, a menudo, después de una hora, un par de horas como máximo, todo funciona y comienzo un nuevo proyecto. Agregar y ejecutar código, al menos para el entorno inicial, se realiza el primer día. Pero si nos aventuramos en los microservicios, el tiempo de lanzamiento inicial se dispara. Sí, ahora tenemos Docker con orquestación y un grupo de máquinas K8, pero para un programador novato todo esto es mucho más complicado. Para muchos jóvenes, esta es una carga que realmente constituye una complicación innecesaria.
El sistema no es fácil de entender.
Centrémonos en nuestro junior por un momento. Con las aplicaciones monolíticas, si ocurría un error, era fácil localizarlo y pasar inmediatamente a la depuración. Ahora tenemos un servicio que está hablando con otro servicio que está poniendo en cola algo en un bus de mensajes que está procesando otro servicio, y luego ocurre un error. Tenemos que juntar todas estas piezas para eventualmente descubrir que el Servicio A está ejecutando la versión 11 y el Servicio E ya está esperando la versión 12. Esto es muy diferente de mi registro consolidado estándar: tener que usar un terminal/depurador interactivo para recorrer a través del proceso paso a paso. La depuración y la comprensión se han vuelto inherentemente más difíciles.
Si no se puede depurar, tal vez los probemos.
La integración continua y el desarrollo continuo se están convirtiendo en algo común. La mayoría de las aplicaciones nuevas que veo crean y ejecutan pruebas automáticamente con cada nueva versión y requieren que se realicen y revisen pruebas antes del registro. Estos son grandes procesos que no deben abandonarse y han supuesto un gran cambio para muchas empresas. Pero ahora, para probar realmente el servicio, tengo que abrir una versión funcional completa de mi aplicación. ¿Recuerda a ese nuevo ingeniero con el grupo K8 de 150 servicios? Bueno, ahora le enseñaremos a nuestro sistema CI cómo activar todos estos sistemas para verificar que todo realmente funciona. Probablemente esto suponga demasiado esfuerzo, por lo que probaremos cada parte de forma aislada: estoy seguro de que nuestras especificaciones son lo suficientemente buenas, las API están limpias y una falla del servicio está aislada y no afectará a otros.
Todos los compromisos tienen una buena razón. ¿Bien?
Hay muchas razones para pasar a los microservicios. He visto que esto se hace para lograr una mayor flexibilidad, escalar equipos, mejorar el rendimiento y brindar una mejor sostenibilidad. Pero, en realidad, hemos invertido décadas en herramientas y prácticas para desarrollar monolitos que continúan evolucionando. Trabajo con profesionales en diferentes tecnologías. Generalmente hablamos de escalamiento porque llegan a los límites de un único nodo de base de datos de Postgres. La mayoría de las conversaciones son sobre .
Pero siempre estoy interesado en aprender sobre su arquitectura. ¿En qué etapa de la transición a los microservicios se encuentran? Es interesante ver a más ingenieros decir que están contentos con su aplicación monolítica. Mucha gente se beneficiará de los microservicios y los beneficios superarán los obstáculos en el camino de la migración. Pero personalmente, por favor, dame mi aplicación monolítica, un lugar en la playa, y estaré completamente feliz.
Fuente: habr.com