Per decenni le aziende hanno supportato i propri modelli di business utilizzando software enterprise di tipo monolitico. L’esigenza di affrontare scenari competitivi sempre più innovativi, complessi, globali, ha condotto molte organizzazioni a scontrarsi contro la difficoltà di queste soluzioni a rinnovarsi e a scalare. Di qui l’interesse per l’emergente paradigma dei microservizi, che ovviamente non è una risposta per tutte le esigenze.
Cosa sono i microservizi
Possiamo vedere un’architettura a microservizi come la scomposizione di un’applicazione monolitica nelle singole componenti applicative dedicate a specifici processi necessari nell’ambito di un determinato dominio di attività business.
A differenza delle funzioni delle applicazioni monolitiche, i microservizi non sono rigidamente interconnessi ma connessi in modo lasco (loosely-coupled). Ciascun microservizio deve essere dotato di un’API (Application Programming Interface) in grado di ricevere o inviare messaggi attraverso protocolli leggeri come HTTP e HTTPS o altri sistemi di lightweight messaging. Il tipo di API più diffusa è la RESTful API, uno stile architetturale standard ideato per la comunicazione fra servizi web.
Come funziona un microservizio
Ogni microservizio funziona come una piccola applicazione autonoma, in grado di svolgere operazioni specifiche su determinati dati di cui è responsabile. Ogni microservizio dispone di una codebase gestibile da un team dedicato di sviluppatori e responsabili delle operazioni, che può adottare metodologie di lavoro Agile e DevOps.
La caratteristica di loosely coupling fa sì che momentanei guasti o spegnimenti per manutenzione di uno o più servizi non impattino sulla funzionalità generale dell’applicazione di cui fanno parte. Anche questa caratteristica, oltre all’esistenza di un team focalizzato, consente di operare in ottica di Continuous Delivery (CD), rispondendo in modo veloce ai cambiamenti delle esigenze di business.
Le conseguenze di una migrazione a un’architettura a microservizi
La migrazione da un’architettura monolitica ai microservizi non comporta una semplificazione dell’attività IT. Diventa, infatti, più complessa la gestione dei team, che aumentano di numero, con la moltiplicazione degli sviluppatori e degli esperti di operation.
Inoltre, dal punto di vista hardware, se si elimina il problema di dover ridimensionare per intero un server o un sistema storage per soddisfare le nuove esigenze di una funzionalità, come avviene con le soluzioni monolitiche, le architetture a microservizi si basano quasi sempre su server, storage e sistemi di rete separati. Anche per questa ragione molte aziende decidono di migrare contemporaneamente alle architetture a microservizi e al cloud computing.
I due approcci per avviare i microservizi
Esistono fondamentalmente due approcci all’adozione dei microservizi: brownfield e greenfield. Nel primo, brownfield, si parte dalla soluzione monolitica business critical già esistente, si censiscono le singole funzionalità, i loro confini nel dominio e loro dati, e quindi si pianifica uno scorporo graduale dei servizi. Ognuno di questi servizi viene rifattorizzato (code refactoring) per diventare un microservizio. Ogni microservizio deve avere una REST API per la collaborazione con l’applicazione monolitica e con gli altri microservizi.
Da notare che, quando l’architettura a microservizi cresce, occorre prevedere una API gateway che funga da strato intermedio fra i client esterni (web browser, device mobili, altre applicazioni) e i microservizi. L’API gateway riceve le chiamate dal mondo esterno, le analizza, a volte si occupa anche della user authentication, le filtra e le ridirige verso le API dei microservizi interessati. Poi si occupa anche di raccogliere le risposte e inviarle ai client in attesa. In pratica, l’API gateway funziona come un proxy. Nel caso di una graduale migrazione da un’applicazione monolitica ai microservizi, è possibile utilizzare la prima come API gateway.
Nel caso dell’approccio greenfield, la soluzione basata su architettura a microservizi viene costruita completamente da zero. Lo svantaggio è che non si ha un modello di piattaforma collaudata a cui ispirarsi, ma il vantaggio principale è potersi concentrare completamente sulla creazione di un’organizzazione su misura di una IT basata su metodologie (per lo sviluppo, il testing, il rilascio, il monitoraggio, il continuous delivery) e tecnologie innovative, sempre di più cloud-native, come i microservizi e i container.
I tre tipi di microservizi
I microservizi, da progettare in modo differente, sono di tre tipi:
- Stateless,
- Persistence (o Stateful),
- Aggregator.
I primi, Stateless, sono la stragrande maggioranza. Non mantengono l’informazione di stato fra una sessione e l’altra. Si limitano a eseguire una transazione per volta e non devono memorizzare niente delle transazioni precedenti. Per questa ragione, anche se si guastano, non influiscono sul servizio all’utente, perché possono essere sostituiti da altri microservizi senza impatto sul servizio.
I secondi, Persistence, devono trattenere l’informazione di stato perché, per soddisfare ogni nuova richiesta, possono dover utilizzare informazioni trasmesse durante le richieste precedenti. Nel caso che una sessione venisse interrotta, questi microservizi devono essere in grado di riprendere dal punto in cui si erano fermati. Esempi di microservizi di questo tipo sono quelli che gestiscono database o protocolli Internet. Nella maggior parte dei casi, questi microservizi interagiscono con una risorsa di storage.
Gli Aggregator sono invece microservizi con funzioni “coreografiche”. Di solito ricevono richieste che prevedono la raccolta di dati da più servizi. Man mano che riceve i dati dai servizi richiesti, l’aggregator li correla, li memorizza finché non ha completato il raggruppamento, e alla fine invia un messaggio aggregato come output.
Quali sono i 12 fattori dei microservizi
Come costruire un’organizzazione e processi in grado di realizzare architetture a microservizi di successo? Per rispondere a questa richiesta è oggi disponibile una metodologia – la Twelve-Factor – a cui un numero sempre maggiore di organizzazioni stanno aderendo. La metodologia consta di 12 best practice che vengono utilizzate per lo sviluppo di Web service, di SaaS Software-as-a-Service e anche di microservizi.
Alcune best practice si focalizzano su come rendere i microservizi meglio interoperabili fra loro e con i servizi disponibili negli operativi e sul cloud. Altre ancora sulla collaborazione nei team composto da sviluppatori e responsabili del deployment e dell’esecuzione, in modo da rendere tutti soddisfatti e in grado di velocizzare la continuous delivery. Altri fattori toccano i temi del monitoraggio e dell’amministrazione.
Quale linguaggio di programmazione è usato per i microservizi
Una parte di queste buone prassi si concentra sullo sviluppo di codice, aspetto assolutamente protagonista nel mondo dei microservizi e in grado di offrire opportunità a chiunque si sia dedicato a studiare seriamente linguaggi adatti a diversi tipi di servizi.
Fra i nomi, Java, Go, Python, Node.js, .Net, C++, C#, Ballerina. Le tecnologie necessarie per creare architetture e singoli microservizi, comunque, sono oggi disponibili in framework intorno ai quali sono sorte comunità e blog molto utili per aiutare i principianti.
I vantaggi dei microservizi
Tra i vantaggi dell’architettura a microservizi possiamo elencare:
- Facilità di aggiornamento: grazie alla modularità, è possibile aggiornare o sostituire un singolo servizio senza influire sul funzionamento degli altri, semplificando il processo di manutenzione e riducendo il rischio di errori.
- Migliore esperienza utente: grazie alla maggiore flessibilità e agilità dell’architettura a microservizi, è possibile offrire ai clienti un’esperienza personalizzata e su misura per le loro esigenze specifiche.
- Riduzione dei costi: l’utilizzo dell’architettura a microservizi può consentire una migliore ottimizzazione delle risorse IT, riducendo i costi operativi complessivi della soluzione.
- Maggiore agilità: grazie alla modularità e alla separazione dei servizi, l’architettura a microservizi consente di adattarsi rapidamente ai cambiamenti del mercato o alle esigenze dei clienti.
- Maggiore sicurezza: la suddivisione dell’applicazione in moduli indipendenti consente di applicare politiche di sicurezza specifiche per ogni servizio, migliorando la sicurezza complessiva del sistema.
- Migliore gestione del ciclo di vita dei servizi: grazie alla separazione dei servizi, è possibile gestire il ciclo di vita dei singoli componenti in modo più efficiente e semplificato. Il che consente una migliore pianificazione delle attività di sviluppo e manutenzione.
- Supporto per diverse tecnologie: l’architettura a microservizi consente di utilizzare diverse tecnologie per lo sviluppo e la gestione dei singoli servizi.
- Facilità di integrazione: grazie alla modularità, è possibile integrare facilmente i nuovi servizi con quelli esistenti per una maggiore interoperabilità tra le diverse parti dell’applicazione.
- Miglioramento della qualità del codice: grazie alla suddivisione in moduli indipendenti e al maggior controllo sui singoli componenti, l’architettura a microservizi migliora la qualità del codice e una maggiore facilità nella risoluzione dei problemi.
I migliori esempi di microservizio
Da quando hanno iniziato a diffondersi, alla fine del primo decennio del secondo, i microservizi hanno già raccolto una ricca serie di casi di successo, ecco le principali aziende che li hanno adottati.
L’architettura a microservizi di Netflix
Quello che viene in mente a tutti per primo è quello di Netflix. Nel 2008, a causa del danneggiamento del database su cui era appoggiata la piattaforma monolitica, l’azienda ha deciso di cambiare codebase.
Tra il 2009 e il 2011, in collaborazione con gli ingegneri di Amazon Web Services, ha sviluppato un’architettura che combina microservizi e algoritmi in grado di scalare orizzontalmente, trasformandosi da noleggiatrice di DVD in leader nello streaming e nella produzione di film, serie TV e documentari.
Uber: il successo dei microservizi
Altro caso interessante è quello di Uber, nata nel 2009 come applicazione per la chiamata di taxi nella città di San Francisco. Allora l’azienda si basava su un’applicazione monolitica in grado di abbinare i conducenti e i passeggeri, eseguire controlli in background, e curare la fatturazione e il pagamento.
In seguito, ha deciso di migrare a un’architettura a microservizi, creandone anche di nuovi per la gestione dei passeggeri e dei viaggi. Grazie anche a queste innovazioni l’azienda è riuscita espandere il suo business originario in tutto il mondo e ad aggiungere nuove attività redditizie.
