Quería escribir un artículo sobre el tema de la arquitectura de microservicios durante mucho tiempo, pero dos cosas me detenían: cuanto más me sumergía en el tema, más me parecía que lo que sé es obvio y lo que no. Lo que no sabemos necesita ser estudiado y estudiado. Por otro lado, creo que ya hay algo que discutir entre una amplia audiencia. Así que opiniones alternativas son bienvenidas.
La Ley de Conway y la relación entre empresa, organización y sistema de información.
Una vez más me permitiré citar:
“Cualquier organización que diseñe un sistema (en el sentido amplio) recibirá un diseño cuya estructura replica la estructura de los equipos de esa organización”.
-Melvyn Conway, 1967
En mi opinión, es más probable que esta ley se relacione con la viabilidad de organizar una empresa que directamente con el sistema de información. Dejame explicarte con un ejemplo. Digamos que tenemos una oportunidad de negocio bastante estable con un ciclo de vida de tal duración que tiene sentido organizar una empresa (esto no es un error tipográfico, pero me gusta mucho este término que robé). Naturalmente, el sistema de soporte de este negocio corresponderá organizacional y procesalmente a este negocio.
Orientación empresarial de los sistemas de información.
Dejame explicarte con un ejemplo. Digamos que existe una oportunidad de negocio para organizar un negocio de venta de pizzas. En la versión V1 (llamémosla preinformación), la empresa era una pizzería, una caja registradora y un servicio de entrega a domicilio. Esta versión tuvo una larga vida en condiciones de baja variabilidad ambiental. Luego lo reemplazó la versión 2, más avanzada y capaz de utilizar un sistema de información en su núcleo para negocios con una arquitectura monolítica. Y aquí, en mi opinión, simplemente hay una terrible injusticia en relación con los monolitos: la arquitectura supuestamente monolítica no se corresponde con el modelo de negocio del dominio. Sí, si así fuera, el sistema no podría funcionar en absoluto, en contradicción con 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; me refiero, por supuesto, a la etapa en la que el sistema ya ha sido creado y puesto en funcionamiento. Es un hecho absolutamente maravilloso que, independientemente del enfoque arquitectónico, tanto la versión 3 de la arquitectura orientada a servicios como la versión N de la arquitectura de microservicios funcionarán igualmente bien. ¿Cuál es el truco?
¿Todo fluye, todo cambia o los microservicios son un medio para combatir la complejidad?
Antes de continuar, veamos algunos conceptos erróneos sobre la arquitectura de microservicios.
Los defensores del uso de un enfoque de microservicio a menudo argumentan 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 es una completa tontería. En serio, ¿la interacción obvia dentro de un código monolito y homogéneo parece complicada? Si este fuera realmente el caso, todos los proyectos se construirían inicialmente 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 pasa de los módulos individuales a las interfaces (ya sean buses de datos, RPC, API y otros protocolos) y sistemas de orquestación. ¡Y esto es difícil!
La ventaja de utilizar una pila heterogénea también es cuestionable. No voy a argumentar que esto también sea posible, pero en realidad rara vez ocurre (de cara al futuro, esto debería suceder, pero más como una consecuencia que como una ventaja).
Ciclo de vida del producto y ciclo de vida del servicio.
Eche otro vistazo al diagrama de arriba. No es casualidad que haya notado la disminución del ciclo de vida de una versión separada de una empresa; en las condiciones modernas, es la aceleración de la transición de una empresa entre versiones lo que es decisivo para su éxito. El éxito de un producto está determinado por la velocidad con la que se prueban las hipótesis comerciales en él.. Y aquí, en mi opinión, radica la ventaja clave de la arquitectura de microservicios. Pero vayamos en orden.
Pasemos a la siguiente etapa en la evolución de los sistemas de información: la arquitectura SOA orientada a servicios. Entonces, en algún momento destacamos en nuestro producto servicios de larga duración - de larga duración en el sentido de que al pasar de una versión a otra de un producto, existe la posibilidad de que el ciclo de vida del servicio sea más largo que el ciclo de vida de la siguiente versión del producto. Sería lógico no cambiarlos en absoluto: nosotros Lo que importa es la velocidad de transición a la próxima versión.. Pero, por desgracia, nos vemos obligados a realizar cambios constantes en los servicios, y aquí todo funciona para nosotros, las prácticas de DevOps, la contenedorización, etc., todo lo que se nos ocurre. ¡Pero estos todavía no son microservicios!
Los microservicios como medio para combatir la complejidad... la 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. Con más detalle, la función de cada microservicio describe exactamente la función comercial 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 pasa literalmente desapercibida: cambias/agregas un microservicio, y tal vez solo el esquema de su interacción, y de repente te encuentras en el futuro, dejando atrás a los competidores llorando que continúan saltando entre versiones de sus monolitos. Ahora imagine que existe un volumen bastante grande de microservicios con interfaces y capacidades comerciales predefinidas. Y usted viene y construye la estructura de su producto a partir de microservicios ya preparados, simplemente dibujando un diagrama, por ejemplo. Felicitaciones, tiene una plataforma y ahora puede atraer negocios. Sueños Sueños.
Hallazgos
- La arquitectura del sistema debe estar determinada por el ciclo de vida de sus componentes. Si un componente se encuentra dentro de una versión del producto, no tiene sentido aumentar la complejidad del sistema mediante el uso de un enfoque de microservicio.
- La arquitectura de microservicios debe basarse en el modelo de dominio, porque la oportunidad de negocio es el dominio más longevo.
- Las prácticas de entrega (prácticas DevOps) y la orquestación son unas de las más importantes para la arquitectura de microservicios, ya que el aumento en la tasa de cambio de componentes impone mayores exigencias a la velocidad y la calidad de la entrega.
Fuente: habr.com