Quería escribir un artículo sobre la arquitectura de microservicios desde hace tiempo, sin embargo, dos cosas siempre me detuvieron: cuanto más profundizaba en el tema, más me parecía que lo que sabía era obvio, y lo que no sabía, aún tenía que investigar más. Por otro lado, creo que ya hay suficiente material para discutir y compartir con una audiencia más amplia. Así que se agradecen las opiniones alternativas.
La Ley de Conway y la relación entre el negocio, la organización y el sistema de información
Permítanme citar una vez más:
«Cualquier organización que diseñe algún sistema (en un sentido amplio) obtendrá un diseño cuya estructura copia la estructura de los equipos dentro de esa organización»
— Melvyn Conway, 1967
En mi opinión, esta ley se relaciona más con la viabilidad de la organización empresarial que directamente con el sistema de información. Permítanme explicarlo con un ejemplo. Supongamos que tenemos una oportunidad de negocio establecida con un ciclo de vida lo suficientemente largo como para justificar la organización de una empresa (no es un error tipográfico, pero me gusta mucho este término que he tomado prestado). Es evidente que el sistema que respalda este negocio se alineará organizativamente y en términos de procesos con la naturaleza de este negocio.
Orientación empresarial de los sistemas de información
Permítanme explicarlo con un ejemplo. Supongamos que hay una oportunidad de negocio para organizar un negocio de venta de pizzas. En la versión V1 (llamémosla pre-informativa), la empresa consistía en una pizzería, un punto de venta y un servicio de entrega. Esta versión fue muy duradera en un entorno de baja volatilidad. Luego llegó la versión 2, que era más avanzada y capaz de utilizar un sistema de información como base para un negocio con arquitectura monolítica. Y aquí, en mi opinión, surge una injusticia terrible con respecto a los monolitos — supuestamente la arquitectura monolítica no corresponde al modelo de dominio del negocio.Si así fuera, el sistema no podría funcionar en absoluto, lo que contradice la misma ley de Conway y el sentido común. No, la arquitectura monolítica se ajusta completamente al modelo de negocio en esta etapa del desarrollo empresarial; me refiero, por supuesto, a la etapa en la que el sistema ya ha sido creado y puesto en funcionamiento. Es un hecho completamente 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. ¿Dónde está la trampa?
Todo fluye, todo cambia, ¿o los microservicios son una herramienta para combatir la complejidad?
Antes de continuar, consideremos algunas confusiones respecto a la arquitectura de microservicios.
Los defensores del uso del enfoque de microservicios a menudo dicen que dividir un monolito en microservicios simplifica el desarrollo al reducir la base de código de los servicios individuales. Desde mi punto de vista, esta afirmación es completamente absurda. En serio, ¿la interacción obvia dentro de un monolito y el código homogéneo parece complicada? Si realmente fuera así, todos los proyectos se construirían desde el principio como microservicios, mientras que la práctica demuestra que la migración de un monolito a microservicios es mucho más común. La complejidad no desaparece, simplemente se traslada de módulos individuales a interfaces (ya sean buses de datos, RPC, API y otros protocolos) y sistemas orquestadores. ¡Y esto es complicado!
La ventaja de usar un stack heterogéneo también es dudosa. No voy a discutir que eso también es posible, pero en realidad rara vez ocurre (Y, adelantando un poco, debería ser así, pero más como consecuencia que como ventaja).
El ciclo de vida del producto y el ciclo de vida del servicio
Mira de nuevo el diagrama anterior. No resalté por casualidad la disminución del ciclo de vida de cada versión del negocio; en las condiciones modernas, acelerar la transición del negocio entre versiones es determinante para su éxito. El éxito de un producto se determina por la velocidad de verificación de las hipótesis comerciales en él. Y aquí es donde, en mi opinión, se encuentra la clave de la ventaja de la arquitectura de microservicios. Pero vayamos por partes.
Pasemos a la siguiente etapa de la evolución de los sistemas de información: la arquitectura orientada a servicios (SOA). Así que, en algún momento determinado, destacamos en nuestro producto servicios de larga duración — servicios duraderos en el sentido de que al pasar entre versiones del producto, hay probabilidades 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, ya que lo que realmente nos importa es la velocidad de transición a la siguiente versión. Pero, lamentablemente, nos vemos obligados a realizar cambios constantes en los servicios, y aquí todo nos sirve: las prácticas de DevOps, la contenedorización y todo lo que se nos ocurra. ¡Pero eso aún no son microservicios!
Microservicios como medio para luchar contra la complejidad… gestión de configuraciones
Y aquí es donde finalmente podemos pasar al papel definitorio de los microservicios: es un enfoque que simplifica la gestión de la configuración del producto. Más concretamente, la función de cada microservicio describe exactamente una función de negocio dentro del producto según el modelo de dominio, y estas son cosas que no viven en una versión de corta duración, sino en una oportunidad comercial de larga duración. Y la transición a la siguiente versión del producto ocurre de forma casi imperceptible: cambias o agregas un microservicio, o quizás simplemente el esquema de su interacción, y de repente ya te encuentras en el futuro, dejando atrás a los competidores llorando que siguen saltando entre las versiones de sus monolitos. Ahora imagina que hay un volumen considerable de microservicios con interfaces y oportunidades de negocio ya definidas. Y tú llegas y construyes la estructura de tu producto a partir de microservicios listos, simplemente dibujando un diagrama, por ejemplo. Felicitaciones, has creado una plataforma, y ahora puedes hacer que tu negocio despegue. Sueños, sueños.
Conclusiones
- La arquitectura del sistema debe definirse por el ciclo de vida de los componentes que la conforman. Si un componente vive dentro del marco de una versión del producto, no tiene sentido aumentar la complejidad del sistema aplicando un enfoque de microservicios.
- La arquitectura de microservicios debe basarse en el modelo de dominio, debido a que la oportunidad de negocio es el área de mayor duración
- Las prácticas de entrega (prácticas de DevOps) y orquestación tienen una importancia crucial para la arquitectura de microservicios, ya que el aumento en la velocidad de cambio de componentes exige mayores requerimientos de velocidad y calidad en la entrega.
Fuente: habr.com
