Cosa sono i microservizi?

I microservizi sono un approccio architetturale alla realizzazione di applicazioni. In quanto framework architetturale, i microservizi sono distribuiti e a basso accoppiamento, in modo che le modifiche di un team non corrompano l'intera applicazione. Il vantaggio dell'utilizzo dei microservizi sta nel fatto che i team di sviluppo possono creare nuovi componenti delle applicazioni per adeguarsi a esigenze aziendali in continua evoluzione.

Quello che distingue l'architettura basata su microservizi dagli approcci monolitici tradizionali è la suddivisione dell'app nelle sue funzioni di base. Ciascuna funzione, denominata servizio, può essere compilata e distribuita in modo indipendente. Pertanto, i singoli servizi possono funzionare, o meno, senza compromettere gli altri. In questo modo si accoglie l'approccio DevOps e si rendono più semplici e attuabili l'iterazione e la distribuzione costanti (CI/CD).

Pensa alla tua ultima visita al sito di un rivenditore online. Probabilmente hai usato la barra di ricerca del sito per sfogliare i prodotti. La ricerca costituisce un servizio. Potresti avere anche ricevuto suggerimenti per i prodotti correlati, che sono basati su un database di preferenze dei clienti. Anche questo è un servizio. Hai aggiunto un articolo a un carrello online? Ovviamente è un altro servizio.

Pertanto, un microservizio è una funzione di base di un'applicazione, che viene eseguita indipendentemente dagli altri servizi. Tuttavia, l'architettura basata sui microservizi non comporta solo il basso accoppiamento tra le funzioni di base di un'app, ma propone una ristrutturazione dei team di sviluppo e del framework comunicativo tra i servizi. Tale approccio offre la possibilità di gestire criticità inevitabili, supporta la scalabilità dinamica e agevola l'integrazione di nuove caratteristiche.

Per eseguire il deployment dei microservizi e sfruttare i vantaggi di questo approccio, occorre adattare gli elementi di base di un'architettura SOA (Service-Oriented Architecture).

Un approccio già noto

Suddividere un'app nelle relative funzioni base ed evitare le insidie dell'approccio monolitico possono sembrare concetti familiari, perché lo stile architetturale dei microservizi è simile a quello dell'architettura SOA (Service-Oriented Architecture), uno stile di progettazione del software ormai consolidato.

Ai primordi dello sviluppo applicativo, anche un cambiamento minimo a un'app esistente imponeva un aggiornamento completo e un ciclo di controllo qualità (QA, Quality Assurance) a sé, che rischiava di rallentare il lavoro di vari team secondari. Tale approccio viene spesso definito "monolitico", perché il codice sorgente dell'intera app veniva compilato in una singola unità di deployment (ad esempio con estensione .war o .ear). Se gli aggiornamenti a una parte dell'app provocavano errori, era necessario disconnettere tutto, fare un passo indietro e correggere. Questo approccio è ancora applicabile alle piccole applicazioni, ma le aziende in crescita non possono permettersi tempi di inattività.

E qui entra in gioco l'architettura SOA (Service-Oriented Architecture), in cui le app sono strutturate in servizi distinti e riutilizzabili che comunicano fra loro tramite un Enterprise Service Bus (ESB). In questa architettura i singoli servizi sono incentrati su uno specifico processo aziendale e seguono un protocollo di comunicazione, tra cui SOAP, ActiveMQ o Apache Thrift, per essere condivisi attraverso l'ESB. Nel complesso, questa suite di servizi integrati attraverso un ESB costituisce un'applicazione.

Inoltre, questo metodo permette di compilare, testare e modificare più servizi contemporaneamente, svincolando i team IT dai cicli di sviluppo monolitici. Tuttavia, poiché l'ESB rappresenta un singolo punto di errore per l'intero sistema (nel tentativo di eliminare il monolita, se ne crea soltanto un altro), potrebbe comportare un ostacolo per l'intera organizzazione.

Qual è la differenza? I microservizi possono comunicare tra loro, in genere in modalità stateless, permettendo di realizzare app con una maggiore tolleranza di errore e meno dipendenti da un singolo ESB. Inoltre, comunicano tramite interfacce di programmazione delle applicazioni (API) (API) indipendenti dal linguaggio e ciò consente ai team di sviluppo di scegliere i propri strumenti.

Considerando l'evoluzione di SOA, i microservizi non costituiscono una novità assoluta, ma ultimamente sono diventati più appetibili grazie ai progressi delle tecnologie di containerizzazione. Oggi i container Linux permettono di eseguire più parti di un'app in modo indipendente, sullo stesso hardware, con un controllo decisamente superiore sui singoli componenti e cicli di vita. In combinazione con le API e i team DevOps, i microservizi containerizzati rappresentano la base delle applicazioni cloud native.

Basandosi su un'architettura distribuita, i microservizi consentono di ottenere sviluppo e routine più efficienti. La possibilità di sviluppare più microservizi in contemporanea consente a più sviluppatori di lavorare simultaneamente alla stessa app, riducendo le tempistiche di sviluppo.

Se hai deciso di passare a un'architettura basata su microservizi, è essenziale riuscire a cambiare anche la struttura di comunicazione e collaborazione tra i team, non solo quella delle app. Cambiare la cultura aziendale può risultare difficile, in parte perché ciascun team segue una propria cadenza di deployment ed è responsabile di un servizio unico, per un determinato gruppo di clienti. Pur non essendo una problematica strettamente legata agli sviluppatori, superarla diventa essenziale per il successo dell'architettura basata su microservizi.

Oltre a queste, un'architettura basata su microservizi presenta due criticità principali: la complessità e la produttività. Nel suo intervento in occasione del Red Hat Summit del 2017, il platform architect di Red Hat Mobile John Frizelle ha identificato queste otto categorie di problematiche:

1. Compilazione: occorre dedicare tempo all'identificazione delle dipendenze fra i servizi. A causa di tali dipendenze, quando si esegue una compilazione può essere necessario eseguirne anche molte altre. È fondamentale considerare anche gli effetti prodotti dai microservizi sui dati.
2. Test: i test di integrazione, così come i test end-to-end, possono diventare molto difficili, ma anche più importanti che mai. Occorre ricordarsi che un errore in una parte dell'architettura potrebbe causare un errore in un componente poco distante, a seconda del modo in cui i servizi sono strutturati per supportarsi a vicenda.
3. Gestione delle versioni: l'aggiornamento a una nuova versione potrebbe compromettere la retrocompatibilità. Il problema può essere gestito attraverso la logica condizionale, ma in breve tempo può diventare difficile da gestire. Disporre di più versioni live per client diversi può essere un'alternativa, ma la manutenzione e la gestione possono essere molto più laboriose.
4. Deployment: soprattutto durante la configurazione iniziale, anche questa è una fase critica. Per semplificare il deployment, occorre innanzitutto investire notevolmente in soluzioni di automazione. La complessità dei microservizi renderebbe il deployment manuale estremamente difficile. Pensa al modo e all'ordine in cui eseguire il roll-out dei servizi.
5. Registrazione: nei sistemi distribuiti, per ricollegare tutti i vari componenti sono necessari registri centralizzati, senza i quali gestirli in modo scalabile risulterebbe impossibile.
6. Monitoraggio: è fondamentale per i team operativi avere una visibilità centralizzata del sistema, al fine di identificare l'origine dei problemi.
7. Debugging: il debugging remoto tramite l'ambiente di sviluppo integrato (IDE) locale non è una scelta praticabile con decine o centinaia di servizi. Al momento non esiste un'unica soluzione legata al debugging.
8. Connettività: occorre valutare quale metodo di rilevamento dei servizi scegliere, se centralizzato o integrato.