Microservizi

Cosa sono i microservizi?

I microservizi sono un approccio architetturale alla realizzazione di applicazioni. 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 implementata in modo indipendente. Pertanto, i singoli servizi possono funzionare, o meno, senza compromettere gli altri.

Pensa alla tua ultima visita al sito di un retailer 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 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 forma 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, potrebbe comportare un ostacolo per l'intera organizzazione.


Microservizi e architettura SOA messi a raffronto

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, i microservizi comunicano tramite interfacce di programmazione delle applicazioni (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.

Quando si decide di rinnovare la propria architettura, partire nel modo giusto è la fase più difficile. Che si tratti di realizzare nuove app o svecchiare quelle esistenti, occorre valutare i pro e i contro della strutturazione in microservizi.


I vantaggi di un'architettura basata sui microservizi

Poiché basati 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.

Commercializzazione più rapida

Consentendo di abbreviare i cicli di sviluppo, un'architettura basata su microservizi supporta deployment e aggiornamenti più agili.

Scalabilità superiore

Man mano che la domanda per determinati servizi aumenta, i microservizi possono essere distribuiti su più server e infrastrutture, in base alle esigenze di business.

Resilienza

Ciascun servizio, costruito correttamente, è indipendente e non influisce sugli altri servizi nell'infrastruttura. Di conseguenza, l'eventuale errore di un componente non determina il blocco dell'intera app, come avviene con il modello monolitico.

Semplicità di deployment

Poiché le app basate su microservizi sono più piccole e modulari delle tradizionali applicazioni monolitiche, tutti i problemi associati a tali deployment vengono automaticamente eliminati. Benché questo approccio richieda un coordinamento superiore, i vantaggi che ne derivano sono determinanti.

Accessibilità

Poiché le app più grandi vengono suddivise in parti più piccole, per gli sviluppatori è molto più semplice comprendere, aggiornare e migliorare tali componenti, e questo permette di accelerare i cicli di sviluppo, soprattutto in combinazione con le metodologie di sviluppo Agile.

Maggiore apertura

Grazie alle API indipendenti dal linguaggio, gli sviluppatori sono liberi di scegliere il linguaggio e la tecnologia ottimali per la funzione da creare.


Problematiche

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 presso il 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 tuoi dati.
  2. Test: i test di integrazione, così come i test end-to-end, possono diventare molto difficili, ma anche più importante che mai. Occorre ricordarsi che un errore in una parte dell'architettura potrebbe causare un errore in un componente a vari passi di distanza, 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: 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 rollout 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 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.

Scopri tutti gli utilizzi dei microservizi