Orquestación de procesos vs. coreografía en microservicios

Al contemplar la arquitectura de software, probablemente se haya encontrado y haya experimentado con los microservicios dentro de la orquestación de procesos, que se ha convertido en el método por defecto para construir aplicaciones.

El estilo arquitectónico de microservicios se centra en el desarrollo de aplicaciones singulares para que funcionen como un conjunto de "microservicios", cada uno de los cuales ejecuta sus propios procesos y se comunica con mecanismos como una API de recursos HTTP. Las aplicaciones se construyen para ser desplegadas de forma independiente y se diseñan en torno a las capacidades de negocio con ejecución automatizada. La gestión centralizada es un componente, pero sólo se necesita mínimamente.

Al referirse a los microservicios, es útil compararlos con el estilo monolítico de desarrollo de aplicaciones en el que existe una interfaz de usuario del lado del cliente, una base de datos y la aplicación del lado del servidor. Desde el lado del servidor, la aplicación gestiona las peticiones HTTP, despliega la lógica de dominio, recibe y actualiza la información de la base de datos, y luego selecciona y muestra las vistas HTML a través del navegador. Como monolito, es un único ejecutable. Si se requiere algún cambio, entonces se debe construir una nueva versión de la aplicación del lado del servidor.

El estilo monolítico ha sido el enfoque "tradicional" para el desarrollo de aplicaciones. La aplicación maneja las solicitudes a través de un solo proceso y utiliza características básicas para dividir la aplicación en clases, funciones y espacios de nombres. Si quisieras ejecutar múltiples instancias, podrías escalar el monolito horizontalmente detrás de un balanceador de carga.

Si bien el estilo monolítico de desarrollo de aplicaciones puede cosechar éxitos, también puede inducir obstáculos para desplegar un mayor número de aplicaciones en la nube. Por ejemplo, dado que los ciclos de cambio están vinculados entre sí, cualquier modificación de la aplicación requiere una completa reconstrucción y re-despliegue. Con el tiempo, mantener una estructura modular organizada se vuelve mucho más complejo y lleva mucho tiempo. Si su organización quisiera escalar las aplicaciones empresariales, tendría que escalar cada aplicación, una por una, en lugar de un solo componente que necesita más recursos.

Del monolito al microservicio

La popularidad de los microservicios se debe en parte a las frustraciones asociadas al estilo del monolito. Sin mencionar que el estilo de microservicio asegura que los servicios son independientemente escalables y desplegables con la capacidad de escribir diferentes servicios en diferentes idiomas. También puede ser manejado por diferentes equipos. Las raíces del estilo de microservicio se remontan a los principios de diseño de Unix, y son mucho más eficientes en la era de la nube.

La propiedad del producto durante todo su ciclo de vida

En el estilo del monolito, una vez que una aplicación es desarrollada se considera completada. El siguiente paso es transferir la propiedad al equipo de mantenimiento. En cambio, el estilo de microservicio abarca la propiedad de por vida del equipo del proyecto que lo desarrolló. Piensa en el mantra de Amazon: "Lo construyes, lo manejas". Como resultado, el equipo de desarrollo tiene una gestión diaria sobre cómo se comporta su aplicación y maneja algunas de las tareas de apoyo. La idea es que haya una relación continua con la aplicación para asegurar que cumpla consistentemente con sus capacidades de negocio.

De hecho, los equipos de microservicio a menudo se resisten a cumplir con normas estrictas. Aunque también puede depender de la forma en que se establezcan y se hagan cumplir las normas. Por ejemplo, en el mundo empresarial, las normas suelen ser elaboradas por equipos con poca o ninguna experiencia en programación. Una forma de pensar en esto es a través de la lente del Diseño de Contexto Limitado por Dominio. El DDD compartimenta un dominio complejo en múltiples contextos delimitados con un mapa que vincula las relaciones. El proceso DDD es beneficioso tanto en arquitecturas monolíticas como de microservicio, ya que ayuda a aclarar y reforzar las separaciones. Sin embargo, los microservicios descentralizan las decisiones en torno al almacenamiento de datos, donde cada servicio puede gestionar su propia base de datos aunque haya instancias diferentes. Este enfoque se conoce como Persistencia Políglota. Cada servicio tiene una función específica y utiliza un medio para la interacción y el intercambio de datos. ¿Cómo? A través de la orquestación o la coreografía.

¿Qué es la orquestación de procesos?

Al igual que una orquesta se basa en el "director" u "orquestador", una interacción de microservicio utiliza la "Orquestación de procesos" para gestionar todas las interacciones en espera de una respuesta antes de solicitar el siguiente servicio. La orquestación sigue un paradigma de solicitud/respuesta. He aquí varias ventajas de la orquestación:

• Fácil de gestionar mediante la centralización de los procesos empresariales
• El flujo de la aplicación se coordina eficientemente usando un procesamiento sincrónico 

¿Cuáles son las limitaciones? Bueno, la orquestación también crea un tipo de dependencia ya que une los servicios. Si el servicio A experimenta un fallo, entonces el servicio B no será llamado. Además, si el orquestador se cae, todo el procesamiento se detiene y se pierde la visibilidad.

¿Qué es la coreografía?

Si su objetivo es evitar las dependencias y permitir que cada servicio trabaje de forma independiente, entonces la coreografía sería el método óptimo. Con este enfoque, los servicios no tienen que esperar instrucciones, sino que actúan de forma independiente. Tomando el enfoque asíncrono, los servicios saben qué y cómo reaccionar a los eventos. He aquí algunos beneficios: 

• Procesamiento rápido ya que los servicios no esperan a un orquestador. 
• Es simple agregar servicios o actualizar desde el flujo de eventos. 
• Elimina cualquier punto de falla.
• Se alinea con un modelo de entrega ágil en el que los equipos pueden centrarse en servicios específicos en lugar de toda la aplicación. 

La coreografía parece la elección lógica para una infraestructura de microservicios, pero existen algunas limitaciones, entre ellas el hecho de que los procesos están dispersos, lo que dificulta la gestión de todo el proceso. Como resultado, la complejidad es un tema resonante. 

Si quieres entender la coreografía vs. la orquestación, podría ayudar el compararlas con ejemplos de la vida real primero. Por ejemplo, piensa en comprar una barra de chocolate de una máquina expendedora. Un flujo de trabajo básico implicaría lo siguiente:

1. Poner dinero en la máquina
2. Seleccione su artículo
3. El gabinete emite los caramelos
4. Recupera tu dulce placer...
5. Tome cualquier cambio (si está disponible)

Puedes descomponerlo más en tres componentes distintos:

1. Pago
2. Haciendo su pedido 
3. Envío de artículos 

Ahora, imaginemos los aspectos de una banda de garaje - no habría director. Con la máquina expendedora, cada evento desencadena otra acción preparada para su ejecución. Al introducir el dinero, se activa la máquina para permitir una selección de opciones de aperitivos. Una vez que presionas el botón de tu elección, comienza el desembolso. Cada componente sólo funciona en base al evento que ha ocurrido previamente.

A diferencia de una banda de garaje, se requiere un director cuando una orquesta está involucrada. Cada nota tocada, y cómo se tocan, son guiadas por el director. Para esta ilustración, puede llamarse orquestación con un director o gestor de procesos que secuencie cada evento. Por lo tanto, el director es consciente de todo el flujo de trabajo. Como el director lo sabe todo, este individuo también puede ofrecer actualizaciones de estado: la música siempre sucede en el momento oportuno. 

Como en el ejemplo de una banda de garaje, muchos de los miembros improvisan; trabajan de forma independiente y no saben qué pasará después. Así que, si eres un negocio que requiere actualizaciones continuas, entonces la orquestación encajaría. Por otro lado, si tu organización cambia continuamente, entonces la coreografía tendría más sentido. Aún así, no tienen que ser mutuamente excluyentes ya que pueden trabajar juntos a través de varios aspectos de diferentes flujos de trabajo.

Orquestación de procesos vs. Coreografía: ¿Cuáles son sus dos modos de interacción? 

Cuando un flujo de trabajo sigue un patrón de orquestación de procesos, siempre hay una conexión punto a punto entre los eventos - sería un reto eliminar los eventos necesarios porque cada vínculo se anota. Por el contrario, el enfoque coreográfico significa que los eventos no se "hablan" entre sí sino que actúan de manera autónoma. La orquestación requiere un control activo, mientras que la coreografía no.

Cuando llegas al rango de manejar cientos o miles de procesos, se vuelve abrumador "coreografiar". A gran escala, la orquestación facilita el control de todos los procesos a la vez. Además, las interacciones humanas pueden ser insertadas fácil y rápidamente.

Imagina un equipo de bailarines actuando en un evento. Ya conocen su coreografía, así que pueden bailar sin que nadie les diga adónde ir, cuándo girar o cuándo bañarse. Dan los pasos correctos y no se pierden ni un paso. La actuación es asincrónica - cuando están en el escenario frente a su público, ya no esperan al coreógrafo. La coreografía es la elección lógica cuando las tareas no requieren respuestas y solicitudes sincrónicas.

Entonces, compara el equipo de baile con los procesos. Incluso si un evento falla, todas las demás acciones pueden seguir adelante como fueron diseñadas. Si un bailarín falla un salto en el mismo contexto, los otros bailarines pueden seguir con la actuación como si nunca hubiera ocurrido. Como resultado, hay mucho menos flujo y rotación. Cada tarea está conectada pero también actúa de forma independiente, lo que aumenta el ahorro de tiempo y reduce las necesidades de mano de obra. Los procesos se ejecutan más rápido porque ya han sido programados y no necesitan una gestión activa. El rendimiento está probado y es fiable. En esencia, la orquestación funciona mejor en un contexto delimitado donde la coreografía funciona mejor entre contextos delimitados.

Dado que los servicios pueden fallar en un momento dado, es crucial disponer de procedimientos para determinar rápidamente las fallas y automatizar la restauración del servicio. Se necesita una supervisión de la aplicación en tiempo real junto con vigilancia semántica para recibir alertas de alerta temprana si algo sale mal. Además, es significativamente más importante dentro de una arquitectura de microservicios ya que los microservicios implícitamente favorecen el enfoque coreográfico.

Bailemos: ¿Coreografía u orquestación?

Nuestra respuesta es ambas. Utilizando un híbrido de bloques de procesos síncronos y asíncronos, la orquestación y la coreografía combinadas significa que el flujo se distribuye y se protege contra un único punto de fallo. Los servicios pueden ser desacoplados, hasta cierto punto. La combinación de la orquestación con la coreografía le da la oportunidad de obtener resultados optimizados y adaptar cada enfoque para satisfacer las necesidades de su arquitectura.

¿Quiere saber más sobre cómo un enfoque equilibrado puede funcionar para su organización? Póngase en contacto con Processmaker hoy mismo para determinar cómo integrar dinámicamente sus procesos para que pueda cumplir rápidamente sus objetivos de negocio.