ESB vs microservizi: fare la scelta giusta

L’Enterprise Service Bus è un’architettura centralizzata che ha visto il suo successo nei primi anni 2000 grazie alla possibilità di collegare diverse applicazioni tramite un bus – un canale di comunicazione centrale –. Da allora il mondo digitale si è evoluto: gli utenti pretendono un’esperienza di navigazione continua, immediata e multicanale, trascinandosi dietro importanti novità IT, tra le quali i microservizi.
I microservizi hanno notevoli vantaggi sulla struttura IT dell’azienda, attenuando i limiti del suo predecessore. Per questo è lecito chiedersi: i microservizi hanno sostituito completamente l’ESB? Quale tra le due è la scelta migliore? Proviamo a rispondere insieme a queste domande.

Enterprise Service Bus e microservizi: un piccolo ripasso

Gli Enterprise Service Bus sono dei sistemi di integrazione utilizzati per integrare e disaccoppiare applicazioni SOA (Service Oriented Architecture): gli applicativi comunicano con l’ESB attraverso l’utilizzo di diversi protocolli e API. I messaggi inviati all’ESB vengono processati, talvolta rielaborati – spesso utilizzando linguaggi proprietari – e inviati agli applicativi interessati nella comunicazione. L’utilizzo degli ESB consente, inoltre, di monitorare la comunicazione tra i componenti applicativi ma al tempo stesso costituisce un single point of failure che potrebbe rallentare l’intero sistema o addirittura comprometterne il funzionamento.

L’utilizzo degli ESB impone di porre particolare attenzione al design di nuovi flussi: l’introduzione di nuove integrazioni o la modifica di quelle esistenti deve avvenire in maniera automatizzata e disaccoppiata rispetto al resto del sistema. Se questo non avviene, l’ESB rischia di rallentare il deploy degli applicativi a esso collegati e quindi di compromettere l’evoluzione IT dell’azienda.

Invece, in un’architettura a microservizi le applicazioni sono organizzate come una serie di piccoli componenti responsabili di una specifica funzione di business: lo sviluppo e il deploy dei microservizi avvengono quindi in maniera indipendente rispetto a tutte le altre componenti del sistema, garantendo flessibilità sia nelle tecnologie scelte, sia nell’operatività e nel deploy delle stesse, sfruttando le logiche DevOps.

ESB e microservizi: alcuni consigli per scegliere

Gli evidenti vantaggi dei microservizi hanno messo in discussione il successo dell’ESB. Tuttavia, la migrazione verso i microservizi è insidiosa e non sempre va fatta: esistono contesti enterprise dove l’ESB è parte integrante del sistema e, quindi, vale la pena chiedersi se il passaggio ai microservizi sia sempre la scelta giusta.

Quando scegliere i microservizi?

• Per implementare le logiche di business custom, per le quali è richiesta una flessibilità di gestione che gli ESB non garantiscono;
• Per utilizzare sistemi di streaming e Fast Data per importare in near real time i dati dai sistemi legacy alle basi dati ad alte performance dell’architettura a microservizi.

Come sfruttare un ESB già interno?

• Utilizzando l’ESB per implementare funzionalità di decoupling verso i sistemi legacy per le comunicazioni sincrone;
• Utilizzando l’ESB per implementare logiche di pass-through qualora servisse un monitoraggio delle comunicazioni verso i sistemi legacy.

Come scegliere un ESB?

• Selezionando soluzioni ESB che favoriscano una gestione DevOps e che siano facilmente scalabili;
• Individuando soluzioni ESB integrate con ecosistemi container based come Kubernetes.

In conclusione, non è detto che i microservizi siano una scelta d’obbligo per tutte le aziende, ma bisogna pianificare attentamente l’introduzione di questa architettura e individuare il percorso migliore in base all’ampiezza e alle caratteristiche univoche del proprio ambiente IT. Alcuni elementi da considerare per fare la scelta giusta sono:

Dunque, i microservizi hanno sostituito l’ESB? La risposta è no: i sistemi legacy saranno presenti ancora nei prossimi anni, ma le aziende devono comunque valutare la loro strategia IT di lungo termine e farsi trovare preparate ai cambiamenti tech dei prossimi 5-10 anni, evitando rischi di vendor lock-in.