Parece que el pico de exageración para los microservicios está detrás. Ya no leemos las publicaciones "Cómo transfirí mi monolito a 150 servicios" varias veces a la semana. Ahora a menudo escucho pensamientos razonables: "No odio el monolito, solo me importa la eficiencia". Incluso observamos varias migraciones desde microservicios de regreso al monolito . Al pasar de una aplicación grande a varios servicios más pequeños, tendrá que resolver varios problemas nuevos. Los enumeramos lo más brevemente posible.

Instalación: desde química básica hasta mecánica cuántica.

Configurar la base de datos base y la aplicación con el proceso en segundo plano fue un proceso bastante claro. Publico un archivo Léame en Github, y a menudo después de una hora, como máximo, un par de horas, todo funciona y empiezo un nuevo proyecto. Agregar y ejecutar código, al menos para el entorno inicial, se realiza desde el primer día. Pero si nos aventuramos en microservicios, el tiempo de lanzamiento inicial despega hacia el cielo. Sí, ahora tenemos un Docker orquestado y un grupo de máquinas K8, pero para un programador novato, todo esto es un orden de magnitud más complicado. Para muchos jóvenes, esta es una carga que es una complejidad realmente innecesaria.

El sistema no es fácil de entender.

Detengámonos por un momento en nuestro junior. Con aplicaciones monolíticas, en caso de error, era fácil rastrearlo e inmediatamente proceder a la depuración. Ahora tenemos un servicio que habla con otro servicio que pone en cola algo en el bus de mensajes que procesa otro servicio, y luego se produce un error. Tenemos que juntar todas estas partes para eventualmente descubrir que el servicio A se está ejecutando en 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: debe usar un terminal / depurador interactivo para realizar el proceso paso a paso La depuración y la comprensión en esencia se han vuelto más difíciles.

Si no puede depurar, tal vez los probaremos

La integración continua y el desarrollo continuo se están volviendo comunes. La mayoría de las nuevas aplicaciones que veo con cada nueva versión crean y ejecutan pruebas automáticamente y requieren que las pruebas pasen y se revisen antes del registro. Estos son procesos excelentes que no pueden abandonarse; se han convertido en un gran cambio para muchas empresas. Pero ahora, para probar realmente el servicio, tengo que subir la versión de trabajo completa de mi aplicación. ¿Recuerdas a ese nuevo ingeniero con un clúster K8 de 150 servicios? Bueno, ahora le enseñaremos a nuestro sistema de CI cómo elevar todos estos sistemas para verificar que todo realmente funcione. Probablemente sea demasiado esfuerzo, por lo que solo probaremos cada parte de forma aislada: estoy seguro de que nuestras especificaciones son lo suficientemente buenas, las API están limpias y la falla del servicio está aislada y no afectará a otras.

Todos los compromisos tienen una buena razón. Derecho?

Hay muchas razones para actualizar a microservicios. Vi que hacen esto para una mayor flexibilidad, para escalar comandos, para el rendimiento, para proporcionar una mejor estabilidad. Pero en realidad, hemos invertido décadas en las herramientas y la práctica de desarrollar monolitos, que continúan desarrollándose. Trabajo con profesionales en diferentes tecnologías. Por lo general, hablamos de escalado porque se enfrentan a los límites de un solo nodo de base de datos Postgres. La mayor parte de la charla es sobre escalar la base de datos .

Pero siempre estoy interesado en aprender sobre su arquitectura. En qué etapa de la transición a los microservicios se encuentran. Es interesante ver cómo cada vez más ingenieros dicen que están contentos con su aplicación monolítica. Muchos microservicios se beneficiarán, y los beneficios superarán los baches en la ruta de migración. Pero personalmente, dame, por favor, mi solicitud monolítica, un lugar en la playa, y estoy completamente feliz.