🕳️ 🏳️ 👩🏻‍🏫 Microservicios: qué es, por qué es y cuándo necesita implementarlos 🧑🏽‍🤝‍🧑🏽 🍯 👨🏼‍🏭

Quería escribir un artículo sobre el tema de la arquitectura de microservicios durante mucho tiempo, pero dos puntos se detenían todo el tiempo: cuanto más me metía en el tema, más me parecía que lo que sabía era obvio y que no sabía, todavía tenía que estudiar y estudiar. Por otro lado, creo que ya hay algo de qué especular en un público amplio. Así que las opiniones alternativas son bienvenidas.

Conway Law y la relación entre empresa, organización y sistema de información.

Una vez más, me permito citar:

"Cualquier organización que diseñe un sistema (en sentido amplio) recibirá un diseño cuya estructura copia la estructura de los equipos en esta organización"
- Melvyn Conway, 1967

En mi opinión, es más probable que esta ley esté relacionada con la conveniencia de organizar un negocio, en lugar de estar directamente relacionada con el sistema de información. Lo explicaré con un ejemplo. Supongamos que tenemos una oportunidad de negocio suficientemente estable con un ciclo de vida de tal duración que tiene sentido organizar una empresa (esto no es un error tipográfico, pero realmente me gusta el término que eliminé) Naturalmente, el sistema de soporte de este negocio será organizacional y un proceso consistente con este negocio. .

Sistemas de información de orientación empresarial

Lo explicaré con un ejemplo. Supongamos que hay una oportunidad de negocio para organizar un negocio de pizza. En la versión V1 (llamémosla preinformativa), la compañía era una pizzería, caja, servicio de entrega. Esta versión fue de larga duración en condiciones de baja variabilidad del mundo circundante. Luego vino la versión 2, que era más avanzada y podía usar el sistema de información como base para un negocio con una arquitectura monolítica. Y aquí, en mi opinión, hay simplemente una terrible injusticia con respecto a los monolitos: la arquitectura supuestamente monolítica no corresponde al modelo de negocio del dominio.. Sí, si fuera así, el sistema no habría podido funcionar en absoluto, al contrario de la misma ley de Conway y el sentido común. No, la arquitectura monolítica es totalmente coherente con el modelo de negocio en esta etapa del desarrollo empresarial; por supuesto, me refiero a la etapa en que el sistema ya está creado y puesto en funcionamiento. Es un hecho absolutamente notable que, independientemente del enfoque arquitectónico, tanto la arquitectura orientada a servicios de la versión 3 como la arquitectura de microservicios de la versión N funcionarán igualmente bien. ¿Cuál es el truco?

¿Todo fluye, todo cambia o los microservicios son una forma de lidiar con la complejidad?

Antes de continuar, consideraremos algunos conceptos erróneos con respecto a la arquitectura del microservicio.

Los defensores del enfoque de microservicio a menudo dicen que dividir un monolito en microservicios simplifica el enfoque de desarrollo al reducir la base de código de los servicios individuales. En mi opinión, esta afirmación no tiene ningún sentido. En serio, ¿la interacción obvia dentro de un monolito y un código homogéneo parece complicada? Si esto fuera cierto, todos los proyectos se construirían inicialmente como microservicios, mientras que la práctica muestra que la migración de un monolito a microservicios es mucho más común. La complejidad no desaparece en ningún lado, simplemente se mueve de módulos individuales a interfaces (ya sean buses de datos, RPC, API y otros protocolos) y sistemas de orquestación. ¡Y es difícil!

La ventaja de usar una pila heterogénea también es dudosa. No argumentaré que esto también es posible, pero que rara vez ocurre en la realidad (mirando hacia el futuro, este debería ser el lugar para estar, sino más bien como una consecuencia y no como una ventaja).

Ciclo de vida del producto y ciclo de vida del servicio

Eche otro vistazo a la tabla de arriba. No fue por casualidad que noté la disminución del ciclo de vida de una versión separada de un negocio: en las condiciones modernas, es la aceleración de la transición de un negocio entre versiones lo que es crucial para su éxito. El éxito del producto está determinado por la velocidad de prueba de las hipótesis comerciales que contiene . Y aquí, en mi opinión, la ventaja clave de la arquitectura de microservicios está enterrada. Pero vamos en orden.

Pasemos al siguiente paso en la evolución de los sistemas de información: una arquitectura SOA orientada a servicios. Entonces, en algún momento específico, destacamos los servicios de larga duración en nuestro producto- larga vida en el sentido de que cuando se cambia entre versiones de productos existe la posibilidad de que el ciclo de vida del servicio sea más largo que el ciclo de vida de la próxima versión del producto. Sería lógico no cambiarlos en absoluto: la velocidad de transición a la próxima versión es importante para nosotros . Pero, por desgracia, nos vemos obligados a realizar cambios constantes en los servicios, y aquí todo nos conviene, y las prácticas de DevOps, la contenedorización, etc., todo lo que se nos viene a la mente. ¡Pero estos todavía no son microservicios!

Los microservicios como herramienta para combatir la complejidad ... gestión de la configuración

Y aquí finalmente podemos pasar a la función definitoria de los microservicios: este es un enfoque que simplifica la gestión de la configuración del producto. Más específicamente, la función de cada microservicio describe exactamente la función comercial dentro del producto de acuerdo con el modelo de dominio, y estas son cosas que viven no en una versión de corta duración, sino en una oportunidad comercial de larga duración. Y la transición a la próxima versión del producto es literalmente imperceptible: cambia / agrega un microservicio, o tal vez solo el esquema de su interacción y de repente se encuentra en el futuro, dejando a los competidores llorando que continúan saltando entre las versiones de sus monolitos. Ahora imagine que hay un volumen bastante grande de microservicios con interfaces predefinidas y oportunidades comerciales.Y usted viene y construye la estructura de su producto a partir de microservicios listos para usar, simplemente dibujando un diagrama, por ejemplo. Felicitaciones, tiene una plataforma, y ahora puede obtener su propio negocio. Sueños Sueños.

recomendaciones

La arquitectura del sistema debe estar determinada por el ciclo de vida de sus componentes constituyentes. Si un componente vive dentro de la versión del producto, no tiene sentido aumentar la complejidad del sistema utilizando un enfoque de microservicio.
La arquitectura de microservicios debe basarse en un modelo de dominio, por la razón de que la oportunidad de negocio es el área más longeva
Las prácticas de entrega (prácticas de DevOps) y la orquestación tienen uno de los valores más importantes para la arquitectura de microservicios, por la razón de que aumentar la tasa de cambio de componentes aumenta la demanda de velocidad y calidad de entrega.