Orchestration vs Choreography, quale usare? Pro e contro

Orchestration vs Choreography: per capire quale approccio è più funzionale è necessario valutare molti fattori diversi. Approfondiamo il funzionamento, i pro e i contro di ognuno degli approcci possibili: Orchestrazione, Choreography o approccio Ibrido.

L’architettura a microservizi si contrappone all’architettura monolitica, portando con sé nuove esigenze. Ad esempio, la necessità di creare un sistema per far funzionare insieme i microservizi. In questo quadro si inserisce la scelta tra due approcci differenti: Orchestration vs Choreography.

In questo approfondimento faremo dapprima un passo indietro, per definire bene il contesto. Vedremo poi nel dettaglio come sono strutturati i due approcci: Orchestration e Choreography. Infine, cercheremo di capire in che misura è possibile usarli entrambi, in quali situazioni possono essere applicati e con quali limiti.

Orchestration vs Choreography: la rivoluzione delle architetture di microservizi

Le applicazioni Cloud Native sono quasi sempre costruite come un set di microservizi che vengono eseguiti in container (per esempio, Docker) e possono essere gestite e distribuite con dei flussi di lavoro DevOps e CI/CD (Continuous Integration/Continuous Deployment). 

Ci sono diverse possibilità. Uno dei modelli possibili è quello “serverless”, offerto ad esempio da AWS Lambda, che esegue blocchi di codice in risposta a determinati eventi e gestisce automaticamente le risorse di elaborazione sottostanti. 

Tornando alla microservice architecture, il vantaggio consiste nel suddividere l'applicazione in una serie di servizi componibili e riusabili. Servizi piccoli, leggeri e facili da implementare determinano costi di sviluppo e modifica più bassi e permettono di scalare in maniera facile e veloce.

Per far funzionare questo sistema è necessario utilizzare un metodo di coordinamento che consenta ai microservizi di lavorare assieme. Esistono sostanzialmente due approcci: l'Orchestration e la Choreography, termini inglesi che non solo corrispondono perfettamente all'equivalente italiano di "orchestrazione" e "coreografia", ma che ne rispecchiano anche il senso che ne viene dalle arti performative. 

Certo, come tutte le analogie anche questa non è perfetta, ma coglie la differenza fondamentale tra i due approcci. L'orchestra ha un direttore che indica agli orchestrali cosa devono fare momento dopo momento. La coreografia, invece, viene studiata e progettata dal coreografo prima, e i ballerini durante l'esecuzione si muovono in maniera libera. Non vengono controllati, ma scelgono cosa fare di volta in volta sulla base della coreografia che hanno appreso e della musica che sta suonando.

Cos'è e come funziona l'Orchestration

Come abbiamo detto e come suggerisce il nome, l'Orchestration è basata sull'idea di un sistema centrale che controlla tutte le interazioni tra i vari elementi del sistema, cioè i microservizi. 

In questo approccio la parola chiave è "supervisione": il controllo del rispetto delle singole istruzioni. Nell'Orchestration, infatti, esiste un servizio che fa da controller e che gestisce le comunicazioni tra i singoli microservizi. Così facendo garantisce che ciascun servizio esegua la parte che gli è stata assegnata.

Il controller è un vero e proprio middleware, cioè un software che fornisce alle applicazioni delle funzionalità e dei servizi comuni. In generale, possiamo pensare al middleware come al tessuto connettivo tra diversi layer applicativi. Nel caso particolare dell'Orchestration, la componente di middleware ha la funzione di supervisore che controlla le interazioni tra i vari microservizi.

L'orchestrazione può essere utilizzata per una serie ampia di compiti. Per esempio, Kubernetes consente di gestire in maniera dichiarativa le risorse orchestrate astraendo il livello fisico sottostante, in modo da essere gestito come un unico pool di risorse computazionali. 

La gestione della configurazione dichiarativa avviene tramite un loop di controllo. Proprio come fa un termostato in una stanza: definito lo stato desiderato il termostato verifica lo stato corrente e agisce per portarlo il più vicino possibile a quello desiderato. Nel caso di Kubernetes, i controller osservano il cluster e quando è necessario effettuano o richiedono delle modifiche allo stato corrente.

In sintesi, l'approccio "orchestrato" si basa sull'idea di creare un sistema di gestione dei processi di business (Business Process Management, o BPM) centralizzato e ben organizzato che sia in grado di dare stabilità all'applicazione e renderne lo stato facilmente misurabile e modificabile.

Strumenti per l’orchestrazione

Abbiamo citato più volte Kubernetes, l'esempio più noto di orchestratore. Ovviamente esistono altri middleware che si occupano della stessa funzione in modi simili: Docker Swarm e Mesos sono altri due esempi molto diffusi.

La Cloud Native Computing Foundation (CNCF), che gestisce il progetto di Kubernetes, supporta in realtà lo sviluppo anche di altri progetti di orchestratori, che però hanno gradi di maturità differenti. Crossplane è nella fase avanzata di incubazione (che precede il rilascio vero e proprio, cioè il livello di Kubernetes) mentre sono ancora in una fase di sviluppo iniziale ben cinque orchestratori: Fluid, Karmada, Open Cluster Management, Volcano e wasmCloud.

Leggi anche: Cos'è l'orchestrazione dei container e come farla con Kubernetes

I limiti dell’Orchestration

Vediamo ora in sintesi quali sono gli svantaggi dell’Orchestration approach. 

Latenze e problemi di disponibilità di servizio

Nell'orchestrazione il controller deve comunicare direttamente con ciascun servizio per potergli indicare cosa deve fare. Deve quindi attendere che la comunicazione sia stabilita e il servizio risponda. 

Quando l'architettura è costituita da centinaia o migliaia di microservizi, si possono creare problemi di disponibilità del servizio o latenze eccessive. 

Esiste un limite oltre il quale un controller centrale non riesce più a gestire in maniera efficiente questo tipo di architettura. In questo, caso è come se si fosse creata un’applicazione monolitica all'interno di un ambiente distribuito.

Troppa dipendenza tra i microservizi

L'orchestrazione crea una forte dipendenza tra i singoli servizi, soprattutto quando agiscono in maniera sincrona. Un servizio deve rispondere alle richieste di un altro in maniera esplicita. 

Quando le relazioni prevedono un accoppiamento così serrato (tight coupling), ogni rottura di qualsiasi anello della catena può bloccare l'intero processo. In un ambiente enterprise, con migliaia di microservizi che vengono utilizzati per una singola funzione di business, l'approccio uno-a-uno non è in grado di scalare.

API RESTful e difficile scalabilità

A proposito di scalabilità, la terza criticità dell'approccio Orchestration è l'uso delle API di tipo RESTful, che sono a loro volta dei servizi strettamente connessi. Le API di tipo RESTful sono definite da un insieme di vincoli architetturali per sistemi distribuiti. Comunicano via HTTP in modalità stateless per la condivisione di risorse in maniera uniforme, usando una sintassi universale e un identificatore globale. 

Dal nostro punto di vista l'uso di API di tipo RESTful ha l'effetto di serrare in maniera ancora più forte l'accoppiamento dei servizi nell'architettura, aumentando il costo e l'impatto sulle API di qualsiasi funzionalità si voglia aggiungere o togliere. Anche qui, in ultima analisi, il problema è riuscire a scalare.

L'approccio Choreography: cos'è e come funziona

La coreografia utilizza un approccio completamente diverso e fondamentalmente decentralizzato. Per sfruttare ancora la metafora del corpo di ballo, si può dire che le coreografie dei servizi non vengono eseguite, bensì vengono messe in scena. 

Con questo si intende dire che la messa in scena avviene quando i partecipanti eseguono i loro ruoli in maniera autonoma. Nessun elemento esegue un ordine esplicito, bensì ciascuno conosce una serie di azioni che deve compiere in relazione agli altri elementi con cui interagisce.

L'approccio coreografico si basa sull'idea che un elemento di controllo centrale, l'orchestratore (il middleware, come Kubernetes) sia ridondante. I singoli componenti, cioè i microservizi, devono essere capaci di autogestirsi senza intervento esterno e accoppiati in maniera loose (loose coupling) e non tight (tight coupling), cioè in modo largo e non troppo serrato. 

Questo vuol dire che i microservizi loosely coupled devono essere in grado di fornire da soli il maggior valore possibile per il business, senza avere un impatto diretto sugli altri componenti. In questa maniera la complessità si riduce perché non c'è un controller da programmare e gestire. Inoltre, come intuibile, non c'è un unico nodo, cioè un elemento potenzialmente critico per tutta l'infrastruttura in caso di problemi.

Ma in che modo avvengono gli scambi di messaggi tra i microservizi in assenza di un middleware?

Per questa attività nell’approccio Choreography si utilizza una componente chiamata "event broker" (o message broker). La coreografia avviene secondo una sequenza di step. Ogni microservizio che ha svolto un’azione spedisce un messaggio su determinati canali. Gli altri microservizi, iscritti a quello specifico canale, ricevono il messaggio. A quel punto sanno da soli cosa devono fare, perché sono progettati per rispondere in automatico a determinati eventi (event driven).

In questo senso la comunicazione avviene in maniera asincrona e il coordinamento, per tornare all'analogia della danza coreografata, è quella tra ballerini (i microservizi) che ascoltano la musica (l'Event Broker) per danzare. 

Utilizzare una logica di loose service coupling permette di cambiare i microservizi (aggiungendone o togliendone a seconda del bisogno) senza che la logica sottostante venga resa inservibile e debba essere riscritta.

Strumenti per la Choreography

Come per l’orchestrazione, anche in questo ambito sono disponibili soluzioni diverse. 

Il cuore di un’architettura basata su un approccio choreography è l'event broker che citavamo prima. Questo si occupa del vero e proprio disaccoppiamento tra i vari microservizi. Alcuni esempi di event broker sono Kafka, RabbitMQ o Amazon SQS.  

Inoltre, in un’architettura event driven si possono integrare bene service-mesh come Istio, o il nuovo arrivato runtime system DAPR.

I limiti dell’approccio Choreography

Abbiamo visto che la Choreography è un metodo per automatizzare lo scambio di messaggi asincroni tra microservizi. Si utilizza una logica di controllo distribuita, basata sugli eventi e ottimizzata per l'automazione di processo attraverso domini diversi. Porta i vantaggi di eliminare i single point of failure e ha la capacità di scalare senza perdita di performance Si possono inoltre cambiare i processi senza far perdere di efficacia alla logica dell'app definita dai microservizi.

Tuttavia, anche l'approccio basato sulla coreografia determina alcune criticità. Vediamole di seguito.

Il cambio di mentalità è un prerequisito

La necessità di cambiare mentalità e modo di pensare al funzionamento dei microservizi rappresenta un prerequisito. In questo senso possiamo considerarlo un limite: non tutti sono in grado di applicare l’approccio Choreography.

Gestire l’intero processo è più difficile

Con la coreografia il processo di business viene letteralmente sparpagliato nei vari microservizi, ciascuno dei quali ha una maggiore autonomia perché accoppiato in maniera più loose agli altri. Questo rende più difficile mantenere la vista d'insieme, cioè il processo complessivo, e riuscire a gestirlo.

Complessità elevata

Infine, il limite maggiore dell'approccio coreografico ai microservizi è la complessità. Ogni servizio identifica la logica che lo riguarda e reagisce in maniera indipendente, sulla base dei messaggi che gli stanno arrivando dai canali che ascolta. Il rischio di non riuscire a far funzionare questa architettura è elevato.

La terza via: l'approccio ibrido

Una terza via alla gestione dei microservizi è basata su un approccio ibrido - o hybrid approach - che contiene allo stesso tempo parti sincrone e asincrone. 

L’approccio ibrido prevede la parte centralizzata - basata sull'orchestrazione -  per quanto riguarda i singoli servizi, e la parte coreografata per quanto riguarda il modo con il quale i servizi comunicano tra di loro. 

Questo approccio permette di usare l'orchestratore per avere una migliore visibilità e controllo dei microservizi, mentre la coreografia serve per far eseguire il flusso di lavoro dei singoli microservizi in maniera separata e autonoma.

I limiti dell’approccio ibrido

Come per l'orchestrazione, anche i limiti dell’approccio ibrido derivano dal fatto che l'orchestratore è fortemente legato ai microservizi. 

Se il sistema di coordinamento ha un problema, l'impatto si riverbera sull'intero sistema. Inoltre, è più laborioso fare cambiamenti di logica, modifiche, aggiunte o eliminazioni di microservizi.

Orchestration vs Choreography: quale conviene usare?

Quando si parla di architettura di sistemi, la risposta a quale approccio scegliere è sempre "dipende". L'Orchestration presenta una serie di vantaggi e alcuni svantaggi, così come la Choreography. 

Quale scegliere quindi? 

Alla luce dei benefici e delle limitazioni che abbiamo argomentato, è chiaro che la decisione deve essere presa sulla base di diversi fattori. Nella decisione peseranno il tipo di progetto che si vuole realizzare, i bisogni di business, gli obiettivi che devono essere raggiunti, il team e le risorse a disposizione. 

In linea di massima, se vogliamo favorire la scalabilità del progetto e siamo preparati a gestire una complessità elevata possiamo considerare l’approccio Choreography.

Viceversa, se la nostra priorità è ottenere controllo per dare stabilità all'applicazione e renderla più facilmente misurabile e modificabile, possiamo valutare l'Orchestration o l’approccio ibrido.