Orquestación vs Coreografía en Microservicios | Decisiones
Blog de decisiones
Orquestación de procesos frente a coreografía en microservicios
Conclusiones clave:
La orquestación versus la coreografía se reduce a cómo los servicios coordinan el trabajo. La orquestación utiliza un coordinador central para gestionar un proceso, mientras que la coreografía permite que los servicios respondan a eventos sin un controlador central. El enfoque correcto depende de la visibilidad, las dependencias y la flexibilidad que requiere su flujo de trabajo.
Al contemplar la arquitectura de software, probablemente te habrás encontrado y habrás experimentado microservicios dentro de la orquestación de procesos que se ha convertido en el método predeterminado para crear aplicaciones. El estilo arquitectónico de microservicios se centra en desarrollar aplicaciones singulares para operar como un conjunto de “microservicios”, cada uno ejecutando sus propios procesos y comunicándose con mecanismos como una API de recursos HTTP.
Las aplicaciones están diseñadas para implementarse de forma independiente y diseñadas en torno a capacidades comerciales con ejecución automatizada. La gestión centralizada es un componente, pero sólo es mínimamente necesaria. Cuando se hace referencia a microservicios, es útil compararlo con el estilo monolítico de desarrollo de aplicaciones donde hay 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 administra solicitudes HTTP, implementa lógica de dominio, recibe y actualiza información de la base de datos y luego selecciona y muestra vistas HTML a través del navegador.
Como monolito, es un único ejecutable. Si se requiere algún cambio, se debe crear 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 solicitudes a través de un solo proceso y utiliza funciones básicas para dividir la aplicación en clases, funciones y espacios de nombres. Si quisieras ejecutar varias instancias, podrías escalar el monolito horizontalmente detrás de un equilibrador de carga.
Si bien el estilo monolítico de desarrollo de aplicaciones puede generar éxito, también puede generar obstáculos para implementar una mayor cantidad 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 reconstrucción y una reimplementación completas. Con el tiempo, mantener una estructura modular organizada se vuelve mucho más complejo y requiere más tiempo.
Si su organización quisiera escalar aplicaciones comerciales, tendría que escalar cada aplicación—una por una en lugar de solo un componente que necesita más recursos.
Del monolito al microservicio
La popularidad de los microservicios se debe en parte a las frustraciones asociadas con el estilo monolítico. Sin mencionar que el estilo de microservicios garantiza que los servicios sean escalables y desplegables de forma independiente, con la capacidad de escribir diferentes servicios en diferentes lenguajes. También puede ser gestionado por diferentes equipos. Las raíces del estilo de microservicios se remontan a los principios de diseño de Unix, y son mucho más eficientes en la era de la nube.
Propiedad del producto durante todo su ciclo de vida
En el estilo monolítico, una vez desarrollada una aplicación se considera completada. El siguiente paso es transferir la propiedad al equipo de mantenimiento. Por el contrario, el estilo de microservicio abarca la propiedad de por vida del equipo del proyecto que lo desarrolló. Piense en el mantra de Amazon de “lo construyes, lo ejecutas” 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 soporte. La idea es que exista una relación continua con la aplicación para garantizar que cumpla consistentemente con las capacidades comerciales previstas.
De hecho, los equipos de microservicios a menudo se resisten a aplicar estándares estrictamente aplicados. Aunque también puede depender de cómo se establezcan y apliquen las normas. Por ejemplo, en el mundo corporativo, los estándares suelen ser desarrollados 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 acotado basado en dominios. DDD compartimenta un dominio complejo en múltiples contextos acotados con un mapa que vincula las relaciones. El proceso DDD es beneficioso tanto en arquitecturas monolíticas como de microservicios 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 administrar su propia base de datos incluso si hay diferentes instancias. Este enfoque se conoce como persistencia políglota. Cada servicio tiene una función específica y utiliza un medio para interactuar y compartir datos. ¿cómo? Ya sea a través de orquestación o coreografía.
¿Qué es la orquestación de procesos en microservicios?
Al igual que una orquesta depende de un director, la orquestación de microservicios utiliza un coordinador central para gestionar cómo funcionan juntos los servicios. El orquestador determina qué pasos se ejecutan, rastrea su progreso y decide qué sucede a continuación.
Orquestación de procesos Puede utilizar solicitudes sincrónicas, mensajes asincrónicos o una combinación de ambos. Su característica definitoria es la coordinación centralizada—no si cada servicio espera una respuesta inmediata.
Los beneficios incluyen:
Una visión clara del proceso general y su estado.
Gestión centralizada de secuenciación, dependencias y manejo de errores.
La desventaja es que la lógica de coordinación se concentra en el orquestador. Los equipos deben diseñar la disponibilidad y la recuperación para que una falla no interrumpa todo el flujo de trabajo.
¿Qué es la coreografía en los microservicios?
Si su objetivo es evitar dependencias y permitir que cada servicio funcione de forma independiente, entonces la coreografía sería el método óptimo. Con este enfoque, los servicios no tienen que esperar instrucciones—actúan de forma independiente. Al adoptar el enfoque asincrónico, los servicios saben qué y cómo reaccionar ante los eventos. Aquí hay algunos beneficios:
Procesamiento rápido ya que los servicios no esperan a un orquestador.
Fácil de añadir servicios o actualizar desde el flujo de eventos.
Elimina cualquier punto único de fallo.
Se alinea con un modelo de entrega ágil donde los equipos pueden centrarse en servicios específicos en lugar de en toda la aplicación.
La coreografía parece la opción lógica para una infraestructura de microservicios, pero existen algunas limitaciones, incluido el hecho de que los procesos están distribuidos, lo que dificulta la gestión de todo el proceso. Como resultado, la complejidad es un problema importante. Si quieres entender la coreografía frente a la orquestación, puede ser útil compararlas primero con ejemplos de la vida real. Por ejemplo, piensa en comprar una barra de chocolate en una máquina expendedora. Un flujo de trabajo básico implicaría lo siguiente:
Introduce dinero en la máquina
Selecciona tu artículo
El armario emite el caramelo
Recoge tu dulce
Recoge el cambio (si lo hay)
Puedes desglosarlo aún más en tres componentes distintos:
Pago
Realizando tu pedido
Despacho de artículos
Ahora, imaginemos los aspectos de una banda de garage—no habría director. Con la máquina expendedora, cada evento desencadena otra acción preparada para su ejecución. Cuando insertas tu dinero, se activa la máquina para permitir una selección de opciones de refrigerios. Una vez que presionas el botón de tu elección, comienza el desembolso. Cada componente sólo funciona en función del evento ocurrido previamente.
A diferencia de una banda de garage, se requiere un director cuando hay una orquesta involucrada. Cada nota tocada y cómo se toca son guiadas por el director. Para esta ilustración, puedes llamarlo orquestación con un director o administrador de procesos que secuencia cada evento. Por tanto, el conductor es consciente de todo el flujo de trabajo. Como el director lo sabe todo, esta persona también puede ofrecer actualizaciones de estado —la música siempre se reproduce en el momento justo. Como en el ejemplo de una banda de garage, muchos de los miembros improvisan; trabajan de forma independiente y no saben qué pasará después.
Entonces, si eres una empresa que requiere actualizaciones continuas, entonces la orquestación sería lo indicado. Por otro lado, si tu organización cambia continuamente, entonces la coreografía tendría más sentido. Aún así, no tienen por qué ser mutuamente excluyentes, ya que pueden trabajar juntos en varios aspectos de diferentes flujos de trabajo.
Orquestación de procesos frente a 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 eventos—sería un desafío eliminar los eventos requeridos porque se anota cada enlace. Por el contrario, el enfoque de la coreografía significa que los eventos no “hablan” entre sí sino que actúan de forma autónoma. La orquestación coloca la lógica de coordinación en un controlador central, mientras que la coreografía la distribuye entre servicios basados en eventos.
Cuando se llega al rango de gestión de cientos o miles de procesos, resulta abrumador “coreografiar”
A gran escala, la orquestación facilita el seguimiento de todos los procesos a la vez. Además, las interacciones humanas se pueden insertar de forma fácil y rápida. Imagine un equipo de bailarines actuando en un evento. Ya conocen su coreografía, por lo que pueden bailar sin que nadie les diga dónde ir, cuándo girar o cuándo sumergirse. Toman los pasos correctos y no pierden el ritmo. La actuación es asincrónica—cuando están en el escenario frente a su público objetivo, ya no esperan al coreógrafo. La coreografía es la elección lógica cuando las tareas no lo requieren respuestas y solicitudes síncronas.
Entonces, compare el equipo de baile con los procesos. Incluso si un evento falla, todas las demás acciones pueden continuar según lo diseñado. Si un bailarín falla un salto en el mismo contexto, los otros bailarines aún pueden continuar con la actuación como si nunca hubiera sucedido. Como resultado, hay mucho menos flujo y rotación. Cada tarea está conectada pero también actúa de forma independiente, lo que mejora el ahorro de tiempo y reduce los requisitos de trabajo manual. Los procesos se ejecutan más rápido porque ya han sido programados y no necesitan gestión activa. El rendimiento está probado y es confiable. En esencia, la orquestación funciona mejor en un contexto delimitado donde la coreografía funciona mejor entre contextos acotados.
Dado que los servicios pueden fallar en un momento dado, es fundamental contar con procedimientos para determinar las fallas rápidamente y automatizar la restauración del servicio. Requiere monitoreo de aplicaciones en tiempo real junto con monitorización semántica para recibir alertas tempranas si algo sale mal. Además, es significativamente más importante dentro de una arquitectura de microservicios, ya que la coreografía de microservicios favorece implícitamente el enfoque.
Bailemos: ¿Coreografía u Orquestación?
Nuestra respuesta es ambas cosas. Utilizar un híbrido de bloques de procesos sincrónicos y asincrónicos —orquestación y coreografía combinadas significa que el flujo se distribuye y protege contra un único punto de falla. Los servicios pueden desacoplarse, hasta cierto punto. Combinar orquestación con coreografía le brinda la oportunidad de obtener resultados optimizados y adaptar cada enfoque para satisfacer las necesidades de su arquitectura.
¿Quiere obtener más información sobre cómo puede funcionar un enfoque equilibrado para su organización? Decisiones de contacto hoy determinar cómo integrar dinámicamente sus procesos para que pueda cumplir rápidamente con sus objetivos comerciales.
Preguntas frecuentes
¿Cuál es la diferencia entre orquestación y coreografía?+−
La orquestación utiliza un coordinador central para dirigir los servicios a través de un proceso. La coreografía distribuye la coordinación entre los servicios que publican y responden a los eventos. La principal diferencia es dónde vive la lógica de coordinación de procesos.
¿La orquestación es siempre sincrónica?+−
No. La orquestación puede utilizar solicitudes sincrónicas, mensajería asincrónica o ambas. Un orquestador central puede coordinar tareas de larga duración y esperar eventos o respuestas antes de continuar con el flujo de trabajo.
¿Pueden la orquestación y la coreografía trabajar juntas?+−
Sí. Un sistema puede utilizar la orquestación para coordinar un proceso de negocio mientras los servicios publican eventos que desencadenan acciones independientes en otros lugares. La combinación de patrones permite a los equipos equilibrar el control centralizado de procesos con interacciones de servicios basadas en eventos.