👩🏼‍🌾 ➖ 👨‍👨‍👦 Microservicios o sistemas modulares? ¿Cómo puede un cliente elegir un enfoque de la arquitectura de TI de un producto? 🍀 🖐🏻 🚼

El microservicio y los sistemas modulares son tipos de arquitectura de soluciones de TI.

Cuando trabajamos con módulos, estamos finalizando una versión en caja de un producto de TI existente.

Por la versión en caja nos referimos a un monolito, un sistema listo para usar con un núcleo que se entrega a todos los clientes de la misma manera, "tal cual".

El refinamiento consiste en crear módulos con funcionalidad faltante.

Obtenemos nuevos módulos reutilizando partes del monolito (núcleo u otros módulos).
La lógica empresarial se escribe dentro del monolito: para un programa (aplicación, sitio, portal) hay un punto de entrada y un punto de salida.

Cuando trabajamos con microservicios, creamos un producto de TI desde cero, componiéndolo a partir de "ladrillos": microservicios atómicos que son responsables de un pequeño proceso separado (enviar una carta, recibir datos de pedidos, cambiar el estado del pedido, crear un cliente, etc.).
La lógica empresarial combina un conjunto de dichos bloques en un sistema común (por ejemplo, usando BPMS). A pesar de la presencia de conexiones, cada bloque es autónomo y tiene sus propios puntos de entrada y salida.

La mayoría de los productos de TI para nuestros clientes comienzan con el desarrollo modular. Algunos de ellos evolucionan con el tiempo a microservicios. Por otro lado, no se necesitan microservicios. En este artículo, examinaremos por qué esto es exactamente así y qué criterios ayudan a determinar si es necesario implementar microservicios o si debe seguir trabajando con módulos.

imagen

Beneficios de la arquitectura modular

Todos los sistemas CMS (Bitrix, Magento, Drupal, Hybris, etc.), CRM, ERP, WMS y muchos otros tienen versiones en caja. Se venden bien y tienen una gran demanda.
Echemos un vistazo a esas razones objetivas por las que los clientes eligen con mayor frecuencia trabajar con una arquitectura modular y comprar voluntariamente soluciones en caja.

Alta velocidad de implementación La

instalación, configuración y llenado de directorios para dicho software lleva un poco de tiempo. Es realista que una empresa mediana comience a trabajar con una caja tres o cuatro meses después del inicio, a veces incluso un poco antes.

Para las pequeñas empresas, este período puede ser de unos pocos días.
. , enterprise- .
. . , , , .
,

. , .

Hay otros factores subjetivos que pueden ser engañosos e influir en la decisión de usar cajas y módulos.

1. Raza de fabricantes

Los vendedores de software convencen calurosamente a los clientes de que su solución inmediata es la correcta: ha sido probada durante años, y de moda, y empresarial, y popular, y de marketing ... Cualquier proveedor: Bitrix, Magento, SAP, Oracle, OpenCart, Django y todos los demás están trabajando duro en técnicas de marketing y ventas.

2. Concepto erróneo sobre la complejidad de las mejoras: los

clientes a menudo están llenos de optimismo. Eligen el software en caja y piensan: “Sí, se necesitarán mejoras. Pero es fácil: no tienes que inventar algo nuevo. Tenemos una versión popular, pero millones de usuarios no pueden cometer errores y comprar un mal producto ".
En su opinión, el proceso de refinamiento se ve así: hay una funcionalidad principal (en caja). Para "terminar" algo en él, los desarrolladores tendrán que "simplemente" redefinir el módulo o escribir rápidamente el suyo. En este caso, no es necesario utilizar métodos repetidos, porque supuestamente todo está pensado en el monolito: se prescriben métodos comunes para calcular los impuestos, existen reglas claras para escribir los métodos de entrega y pago, flujo de trabajo claro de pedidos, etc.

En la vida real, las cosas son diferentes. Y después de las agradables emociones del fácil comienzo de trabajar con la caja, los clientes aún enfrentan una dura realidad. La mayoría de las veces esto sucede con empresas de medianas y grandes empresas, cuyos proyectos tienen una lógica empresarial única, y se necesitan mejoras a gran escala.

Si su empresa es una pequeña empresa y el software no es su principal activo, lo más probable es que le convenga una solución popular en caja (o mejor, una nube).

Veamos qué problemas puede encontrar al trabajar con una arquitectura modular y cómo los microservicios ayudan a evitar esto.

Problemas de sistemas modulares

El principal problema es que todos los sistemas modulares no están diseñados para redefinir seriamente la funcionalidad. Tienen una caja, módulos listos para usar, es mejor usarlos.

Cuanto más cerca del nivel de empresa sea el tamaño del proyecto y la complejidad de sus personalizaciones, habrá más problemas con la finalización de los módulos. Hablemos de los principales.

Problema No. 1. El núcleo del sistema se convierte en un punto de desaceleración, y la modularidad se convierte en una complicación innecesaria.

Digamos que su proyecto está asociado con una lógica de almacén compleja. Si elige una arquitectura modular, los desarrolladores no solo necesitan crear funcionalidad para administrar estos almacenes, sino que también deben redefinir o expandir el módulo multinúcleo, que, a su vez, utiliza métodos de kernel.

En este caso, es necesario tener en cuenta la lógica compleja de las devoluciones a los almacenes: dependencia de eventos del sistema CRM, movimiento de mercancías entre catálogos, etc. También vale la pena considerar la lógica oculta asociada con la devolución de fondos, puntos de bonificación, etc.

Cuando se producen tantas redefiniciones, el monolito cambia significativamente. Es importante recordar que la relación entre el volumen del nuevo funcional y el número de módulos no es lineal: para agregar una función, debe realizar cambios en varios módulos, cada uno de los cuales cambia el funcionamiento del otro, o redefinir una gran cantidad de métodos de otros módulos en el nuevo módulo, lo que no cambia la esencia.

Después de todos los cambios, el sistema se vuelve tan complicado que se requerirá una cantidad indecente de horas para agregar las siguientes personalizaciones.

imagen

Problema No. 2. El principio de autodocumentación no es compatible con los sistemas modulares.

La documentación para sistemas modulares es difícil de mantener actualizada. Es mucho y queda obsoleto con cada cambio. El refinamiento de un módulo implica cambios en varios otros documentos (en el usuario, documentación técnica), y todos ellos deben reescribirse.

Como regla, no hay nadie para hacer ese trabajo: pasar tiempo con valiosos especialistas de TI en esto significa simplemente agotar el presupuesto. Incluso el uso del almacenamiento de documentación en código (PHPDoc) no garantiza su fiabilidad. Al final, si la documentación puede diferir de la implementación, necesariamente será diferente.

Problema No. 3. Mayor coherencia del código: el camino hacia la regresión: "lo cambiaron aquí, se cayó"

Los problemas clásicos de los sistemas modulares están en la lucha contra la regresión.

El desarrollo de TDD es difícil de usar para monolitos debido a la gran coherencia de los diferentes métodos (puede pasar fácilmente 30 líneas de pruebas en cinco líneas de código, más accesorios).
Por lo tanto, en la lucha contra la regresión, es necesario cubrir lo funcional con pruebas de integración.
Pero en vista del desarrollo ya lento (después de todo, debe desarrollarlo cuidadosamente para proporcionar muchas anulaciones), los clientes no quieren pagar por pruebas de integración complejas.

Las pruebas funcionales se vuelven tan grandes como sin sentido. Corren durante horas, incluso en paralelo.

Sí, un frente moderno como PWA se puede probar API-funcionalmente. Pero las pruebas a menudo dependen de recibir datos del circuito externo y, por lo tanto, comienzan a fallar si, por ejemplo, la prueba SAP está detrás del supermercado durante N meses y la prueba "1C" envía datos incorrectos.

Cuando tiene que cargar una pequeña edición para algún módulo, los desarrolladores deben elegir entre dos males: comenzar una ejecución completa de CI y pasar mucho tiempo en una implementación o diseñar una revisión sin ejecutar una prueba, arriesgándose a romper algo. Es muy dramático cuando tales ediciones llegan del departamento de marketing el Black Friday. Por supuesto, tarde o temprano, la regresión y el error humano sucederán. ¿Eso es familiar?

En última instancia, para cumplir los objetivos comerciales, el equipo entra en modo de operación de emergencia, hace malabares hábilmente con las pruebas y mira cuidadosamente los tableros de los registros: Kibana, Grafana, Zabbix ... ¿Y qué obtenemos al final? Burnout

Debe admitir que tal situación con regresión no es como la "empresa estable" como debería ser en los sueños y sueños del cliente.

Problema 4: conectividad de código y actualización de plataforma

Otro problema con la conectividad del código es la dificultad de actualizar la plataforma.

Por ejemplo, Magento contiene dos millones de líneas de código. Dondequiera que miremos, hay mucho código en todas partes (Akeneo, Pimcore, Bitrix). Al agregar funcionalidad al kernel, sería mejor tener en cuenta los cambios en sus módulos personalizados.

Aquí hay un ejemplo en vivo para Magento.
A finales de 2018, se lanzó una nueva versión de la plataforma Magento 2.3. Multistores y Elasticsearch se han agregado a la edición de código abierto. Además, se corrigieron miles de errores en el núcleo y se agregaron algunas ventajas en OMS.

¿A qué se han enfrentado los proyectos de comercio electrónico que ya han escrito múltiples tiendas en Magento 2.2? Necesitaban reescribir un montón de lógica en el procesamiento de pedidos, el pago y las tarjetas de productos para poder utilizar la funcionalidad en caja. De hecho, "tan correcto": ¿por qué duplicar la funcionalidad de la versión en caja en los módulos? Reducir el volumen de código personalizado en un proyecto grande siempre es útil; después de todo, todos los métodos de caja tienen en cuenta estos almacenes múltiples, y actualizar la caja sin dicha refactorización puede ser inútil (tenga en cuenta los problemas de seguridad por simplicidad, especialmente porque se pueden acumular sin actualizar).

Ahora imagine: ¿cuánto tiempo se dedicará a dicha actualización y cómo se puede probar sin pruebas de integración, que son difíciles de escribir?

No es sorprendente que, para muchos, la actualización de la plataforma se realice sin refactorizar, pero con un aumento de la duplicación o (si el equipo quiere hacer todo en feng shui) con "salir" durante mucho tiempo en la refactorización y restauración del orden.

Problema No. 5. Opacidad de los procesos de negocio.

Uno de los problemas más importantes en la gestión de proyectos es que el cliente no ve toda la lógica y todos los procesos comerciales del proyecto. Solo se pueden restaurar desde el código o desde la documentación (cuya relevancia, como dijimos anteriormente, es problemática de mantener en sistemas modulares).

Sí, Bitrix tiene una parte BPM, mientras que Pimcore tiene una visualización de flujo de trabajo. Pero este intento de administrar módulos a través de procesos comerciales siempre entra en conflicto con la presencia de un núcleo. Además, eventos, temporizadores complejos, operaciones transaccionales, todo esto no ocurre en monolitos BPM. Repito: esto se aplica a las medianas y grandes empresas. Para una empresa pequeña, las capacidades de los sistemas modulares son suficientes. Pero si hablamos del segmento empresarial, entonces esta solución aún carece de un centro de control único donde pueda ir y ver el diagrama de cualquier proceso, cualquier estado, cómo está sucediendo exactamente algo, cuáles son las excepciones, los temporizadores, los eventos y las coronas. . No hay suficientes oportunidades para cambiar los procesos de negocio, pero no los módulos. La gestión del proceso del proyecto se está ahogando en la velocidad del cambio y la coherencia de la lógica.

Problema 6. Complejidad de la escala del sistema

Si implementa un monolito, se implementará en su totalidad con todos los módulos en cada servidor de aplicaciones. Aquellos. no puede aumentar por separado el servicio de procesamiento de pedidos y bonificaciones en una temporada, por separado del resto del código.

Necesita más memoria y procesadores, lo que aumenta enormemente el costo del clúster.

Cómo los microservicios salvan a los clientes de los defectos típicos del desarrollo modular. Orquestación de microservicios en Camunda y jBPM

Spoiler: La solución a los problemas enumerados en el último párrafo es posible utilizando BPMS y orquestando sistemas de microservicios.

BPMS (sistema de gestión de procesos de negocio en inglés) es un software para gestionar procesos de negocio en una empresa. Los BPMS populares con los que trabajamos son Camunda y jBPM.

La orquestación describe cómo los servicios deberían interactuar entre sí mediante la mensajería, incluida la lógica empresarial y una secuencia de acciones. Al usar BPMS, no solo dibujamos esquemas abstractos: nuestro proceso comercial se ejecutará de acuerdo con el sorteo. Lo que vemos en el diagrama está correlacionado con la forma en que funciona el proceso, qué microservicios se utilizan, qué parámetros, según qué tablas de decisión, se selecciona una lógica particular.

Como ejemplo, tomamos un proceso frecuente: enviar un pedido para la entrega.

Por cualquier mensaje o llamada directa, comenzamos el procesamiento de pedidos con el proceso de elegir un método de entrega. Se establece la lógica de selección.

Como resultado, procesos, servicios y desarrollo:

hacerse rápidamente legible;
autodocumentado (funcionan exactamente como se dibujan y no hay sincronización de rassyn entre la documentación y el trabajo real del código);
simplemente depurado (es fácil ver cómo funciona este o aquel proceso y entender cuál es el error).

Nos familiarizaremos con los principios por los cuales funcionan los sistemas de gestión de procesos de negocio.

Principio BPMS No. 1. El desarrollo se vuelve visual y proceso

BPMS le permite crear un proceso comercial en el que el equipo del proyecto (desarrollador o usuario comercial) determina la secuencia de inicio de los microservicios, así como las condiciones y ramas a lo largo de las cuales se mueve. En este caso, un proceso empresarial (secuencia de acciones) puede incluirse en otro proceso empresarial.

Todo esto se presenta claramente en BPMS: en tiempo real puede ver estos esquemas, editarlos y ponerlos de manera productiva. Aquí, el principio de un entorno de autodocumentación se cumple al máximo: el proceso funciona exactamente como se visualiza.

Todos los microservicios se convierten en cubos de proceso que se pueden agregar de forma instantánea a un usuario empresarial. La empresa gestiona el proceso y el desarrollador es responsable de la disponibilidad y el funcionamiento correcto de un microservicio en particular. Además, todas las partes entienden la lógica general y el propósito del proceso.

Principio BPMS No. 2. Cada servicio tiene entradas y salidas claras.

El principio parece muy simple, y puede parecerle a un desarrollador o usuario comercial sin experiencia que BPMS no mejora la estrategia de escribir microservicios de ninguna manera. Al igual, los microservicios normales se pueden escribir sin BPMS.

Sí, es posible, pero difícil. Cuando un desarrollador escribe un microservicio sin BPMS, inevitablemente desea ahorrar en abstracción. Los microservicios se vuelven francamente grandes y, a veces, incluso comienzan a reutilizar otros. Existe el deseo de ahorrar en la transparencia de la transferencia del resultado de un microservicio a otro.

BPMS te anima a escribir de manera más abstracta. El desarrollo se lleva a cabo con precisión el proceso, con la definición de entrada y salida.

Principio BPMS No. 3. Concurrencia del procesamiento de colas

Imagine el proceso de procesamiento de pedidos: tenemos que ir a algún mercado, recoger todos los pedidos buenos y comenzar a procesarlos.

imagen

Mire el diagrama (parte del diagrama). Aquí se determina que cada 10 minutos verificamos todos los pedidos del mercado, luego ejecutamos en paralelo (como lo indica la "hamburguesa" vertical en el Pedido del proceso) el procesamiento de cada pedido. Si tiene éxito, transfiera todos los datos a ERP y complete el procesamiento.

Si de repente necesitamos aumentar los registros para procesar un pedido específico, en Camunda, JBoss o cualquier otro BPMS, podremos restaurar completamente todos los datos y ver en qué cola estaba y con qué parámetros de entrada / salida.

Principio BPMS No. 4. Error y escalada

Imagine que ocurrió un error durante el proceso de entrega. Por ejemplo (por cierto, este es un caso real), la compañía de transporte tomó la orden y luego el depósito se quemó. Otra historia real: la prisa de la víspera de Año Nuevo, el producto se retrasó primero y luego, tal vez, se perdió.

En este caso, los eventos se activan con el mouse en BPMS, por ejemplo, la notificación de un cliente en caso de que haya pasado el tiempo de entrega. Si recibió un error de la compañía de transporte interna, puede iniciar el proceso en su propia sucursal e interrumpir todo: notificar, dar un descuento en el próximo pedido, devolver el dinero.

Todas estas excepciones son difíciles no solo de programar fuera de BPMS (por ejemplo, un temporizador en un temporizador), sino también de entenderse en el contexto de todo el proceso.

Principio BPMS No. 5. La elección de acciones para uno de los eventos y opciones de interproceso

Envíe el mismo pedido en la entrega.

En total, tenemos tres escenarios:

los bienes fueron entregados como se esperaba;
los bienes no fueron entregados como se esperaba;
El artículo se ha perdido.

Directamente en BPMS, podemos determinar el procedimiento para el envío de mercancías a la empresa de transporte y esperar uno de los eventos por pedido:

entrega exitosa (mensajes del proceso de entrega del producto de que todo se entregó);
o el inicio de algún tiempo.

Si no ha pasado el tiempo, debe iniciar otro servicio: analizar este pedido específico con el operador (debe configurar una tarea para él en el sistema OMS / CRM para averiguar dónde está el pedido) con una notificación adicional del cliente.

Pero si en el proceso de investigación se entregó el pedido, es necesario interrumpir la investigación y completar el procesamiento del pedido.

En BPMS, todas las interrupciones y excepciones están del lado de BPMS. No sobrecargue el código con esta lógica (y la sola presencia de dicha lógica en el código haría que los microservicios fueran grandes y se reutilizaran mal en otros procesos).

Principio BPMS No. 6. En tu Camunda verás todos los registros.

Usando eventos y la opción de interproceso, usted:

Verá toda la secuencia de eventos en una ventana (lo que sucede con el pedido, qué rama de las excepciones pasó, etc., es fácil de ver);
Puede recopilar todos los análisis para BI basándose únicamente en los registros de BPMS (sin la necesidad de sobrecargar los microservicios con eventos de registro).

Como resultado, podrá recopilar estadísticas específicamente sobre los problemas de procesamiento, tasas de transición, todos los procesos de la empresa. Existe una unificación de la información de registro: es fácil vincular el evento en la entrega con la acción del operador o el evento de cualquier otro sistema de información.

Preste atención a la diferencia con el sistema modular: los registros universales también se pueden hacer allí, pero al interactuar con otros sistemas, deberá hacer algo con la unificación del inicio de sesión en ellos, y esto no siempre es posible.

Conclusiones: una comparación de microservicio y arquitectura modular

Cada tipo de arquitectura tiene sus ventajas y desventajas. No hay una solución universal.

No abogamos por un cambio masivo a los microservicios. Por el contrario, para una pequeña empresa o cuando se utiliza un número muy pequeño de personalizaciones, un enfoque modular será más adecuado.

Además, no nos oponemos a ninguna solución de TI (Bitrix, Magento, marcos como Symfony o Django, etc.), porque desarrollamos más de seis mil horas de código cada mes solo en estos marcos, y la misma cantidad de front'a y microservicios Por lo tanto, estamos convencidos de que es importante buscar una solución técnica adecuada y no promover el uso de una plataforma específica (a la cual, por desgracia, una parte importante de las ventas en TI se está deslizando).

En las secciones anteriores del artículo, aprendió sobre las desventajas y ventajas de la arquitectura modular. Esperamos que esto ya haya ayudado a evaluar si el refinamiento de la versión en caja o la creación de microservicios desde cero sería más adecuado. Si no fue posible decidir, veamos cómo cambian los diferentes tipos de arquitectura según la vida del proyecto.

Al inicio del proyecto:

con microservicios: tiene cero funciones y necesita escribir todo para poder trabajar;
con un sistema modular: desde la versión en caja, tiene disponible una gran cantidad de funcionalidades, y puede comenzar a usar el producto poco después de la compra.

Después de los primeros 3-4 meses de desarrollo (esta es la fecha de lanzamiento promedio para el primer MVP) y más allá:

con microservicios: el volumen de funcionalidad se alinea gradualmente en comparación con la versión en caja. Para las empresas medianas, la arquitectura de microservicios se pondrá al día con los módulos lo suficientemente rápido, pero para grandes, generalmente al instante. Y en el futuro, aumentará el mantenimiento y el desarrollo de un sistema modular en términos de una unidad funcional;
con un sistema modular: la velocidad de desarrollo de la funcionalidad será significativamente menor que en microservicios.

En conclusión, veamos cómo se ve la orquestación de microservicios con ejemplos específicos.

Ejemplos de visualización de orquestación de servicios

Considere la orquestación de servicios usando Camunda. A partir de las siguientes imágenes, puede evaluar la conveniencia de administrar microservicios utilizando BPMS con un orquestador. Todos los procesos son visuales, la lógica es obvia.

Los procesos de negocio se ven así:
imagen

Ejemplo (pedido, servicio de disponibilidad):

imagen

se puede ver que en este pedido había una rama "Sin bienes".

Otra copia del pedido (fue al ensamblaje): el

imagen

pedido fue más allá y de acuerdo con la tabla de decisiones (DMN) fue enviado a la sucursal de procesamiento por un determinado operador de servicios de entrega (Boxberry):

imagen

Cuidado del proceso anidado: El

imagen

proceso anidado funcionó:

imagen

Historia de los procesos comerciales:

imagen

Propiedades de esta visualización:

los procesos de negocios son fáciles de leer incluso por un usuario no preparado;
son ejecutables, es decir, funcionan exactamente como se dibujan, no hay rassynchron entre la "documentación" y el trabajo real del código;
los procesos son transparentes: es fácil ver cómo se realizó una importación, un pedido o un procesamiento en particular, es fácil ver dónde se cometió el error.

Recuerde que en kt.team utilizamos el desarrollo tanto modular como de microservicios, eligiendo la opción correcta para cada producto individualmente. Pero si la elección ya se hizo a favor de la arquitectura de microservicios, entonces estamos firmemente convencidos de que es imposible prescindir de sistemas BPM como Camunda o jBPM.

Ver también: video sobre el tema "Microservicio o arquitectura monolítica: ¿qué elegir?"

Microservicios o sistemas modulares? ¿Cómo puede un cliente elegir un enfoque de la arquitectura de TI de un producto?