Parece que el pico del hype por los microservicios ha quedado atrás. Ya no leemos varias veces a la semana publicaciones como "Cómo migré mi monolito a 150 servicios". Ahora escucho más a menudo pensamientos razonables: "No odio el monolito, simplemente me preocupa la eficiencia". Incluso hemos observado algunas migraciones . Al pasar de una gran aplicación a varios servicios más pequeños, te enfrentarás a varios problemas nuevos. Enumeremos brevemente.
Configuración: de la química básica a la mecánica cuántica
Configurar la base de datos básica y la aplicación con un proceso en segundo plano fue un proceso bastante claro. Publico un readme en Github y, a menudo, en una hora, como máximo un par de horas, todo está en funcionamiento y empiezo un nuevo proyecto. La adición y ejecución del código, al menos para el entorno inicial, se realiza el mismo día. Pero si nos atrevíamos con microservicios, el tiempo de lanzamiento inicial se dispara. Sí, ahora tenemos Docker con orquestación y un clúster de máquinas K8, pero para un programador principiante, todo esto es considerablemente más complejo. Para muchos juniors, es una carga que realmente representa una complejidad innecesaria.
El sistema no es fácil de entender
Detengámonos un momento en nuestro junior. Con aplicaciones monolíticas, si ocurría un error, era fácil rastrearlo y pasar directamente a la depuración. Ahora tenemos un servicio que habla con otro servicio, que coloca algo en una cola en el bus de mensajes, que maneja otro servicio, y ahí es donde ocurre el error. Debemos juntar todas estas partes para eventualmente descubrir que el servicio A está en la versión 11, mientras que el servicio E ya está esperando la versión 12. Esto difiere mucho de mi registro consolidado estándar: tengo que usar un terminal interactivo/debugger para recorrer el proceso paso a paso. La depuración y la comprensión han pasado a ser, en esencia, más complicadas.
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 nuevas aplicaciones que veo crean y ejecutan automáticamente pruebas con cada nuevo lanzamiento, y requieren que las pruebas sean aprobadas y revisadas antes de la implementación. Estos son excelentes procesos de los que no se puede prescindir; han supuesto un gran cambio para muchas empresas. Pero ahora, para realmente probar el servicio, debo levantar una versión completamente funcional de mi aplicación. ¿Recuerdas al nuevo ingeniero con el clúster de K8 de 150 servicios? Bueno, ahora vamos a enseñar a nuestro sistema de CI cómo levantar todos estos sistemas para comprobar que todo funciona realmente. Probablemente sea demasiado esfuerzo, así que simplemente probaremos cada parte de forma aislada: estoy seguro de que nuestras especificaciones son bastante buenas, que las API son limpias y que la falla del servicio está aislada y no afectará a los demás.
Todos los compromisos tienen una razón válida. ¿No es así?
Hay muchas razones para migrar a microservicios. He visto que se hace para obtener mayor flexibilidad, para escalar equipos, para mejorar el rendimiento y para garantizar una mejor resiliencia. Pero en realidad, hemos invertido décadas en herramientas y prácticas para desarrollar monolitos que siguen evolucionando. Trabajo con profesionales en diferentes tecnologías. Generalmente hablamos sobre la escalabilidad porque se enfrentan a las limitaciones de un único nodo de base de datos Postgres. La mayor parte de la conversación se centra en .
Pero siempre me interesa conocer su arquitectura. ¿En qué etapa del proceso de transición a microservicios se encuentran? Es curioso observar cómo cada vez más ingenieros dicen que están contentos con su aplicación monolítica. Muchos se beneficiarán de los microservicios y las ventajas superarán los obstáculos en el camino de la migración. Pero, personalmente, prefiero mi aplicación monolítica, un lugar en la playa, y soy completamente feliz.
Fuente: habr.com
