Vantaggi, opportunità e rischi dell’approccio a microservizi 

Si ringrazia Michelangelo Uberti, Marketing Manager Par-Tec, per questo articolo. 

Resilienza, scalabilità, riduzione del time-to-market, flessibilità nella scelta di linguaggi e tecnologie. Le architetture a microservizi stanno rivoluzionando il modo di scrivere e distribuire le applicazioni. 

Dai monoliti ai microservizi 

Negli ultimi 20 anni i professionisti dell’IT hanno vissuto tre distinte “ere geologiche”. 

La prima era è iniziata ben prima del boom della net economy ed è terminata poco più di dieci anni fa. È l’era dello sviluppo waterfall (“a cascata”), con le sue classiche fasi di analisi dei requisiti, progettazione, sviluppo, collaudo e manutenzione. In questa epoca era normale avere delle applicazioni monolitiche concentrate su server fisici posti nei data center del cliente. 

La seconda era è la fase dello sviluppo agile e del suo approccio iterativo, delle applicazioni a più strati che girano su macchine virtuali noleggiate da service provider pubblici. 

Nella nuova era, il processo di sviluppo è una evoluzione del metodo agile ed è basato su micro-cicli di sviluppo. Con l’avvento del paradigma DevOps sfumano inoltre i confini tra lo sviluppo e l’esercizio, e si punta ad una maggiore integrazione tra i team. La distribuzione delle componenti avviene mediante Linux containers che girano in ambienti cloud e Platform-as-a-Service (PaaS) come Red Hat OpenShift. 

Le architetture applicative 

Con l’aggettivo monolitiche si intendono delle applicazioni sviluppate e distribuite come una singola entità. Sono tendenzialmente più facili da sviluppare perché un singolo programma comprende in sé tutta la logica. 

È l’approccio ideale per applicazioni piccole e poco complesse ma è estremamente limitato: la scalabilità è solo verticale, perciò all’aumentare del carico si devono aggiungere risorse al sistema sul quale gira l’applicazione. All’aumentare della complessità e della grandezza dell’applicazione, diventa sempre più difficile garantire la manutenzione correttiva ed evolutiva del prodotto. 

Le applicazioni multi-tier nascono per tentare di superare questi limiti mediante la scomposizione in tre strati più facilmente gestibili: presentation layer (front-end), business layer (back-end) e data layer (database). Come ogni passaggio evolutivo, questa trasformazione ha richiesto lo sviluppo di nuove competenze e nuovi strumenti, basti pensare ad esempio alle complessità connesse all’alta affidabilità. 

Nelle architetture a microservizi, le applicazioni vengono scomposte in tanti elementi distinti che svolgono funzioni atomiche o comunque ben identificabili. Questo è il motivo per cui spesso sono rappresentate come dei puzzle o delle costruzioni che si incastrano tra loro. 

Quanto debba essere grande o complesso un servizio è un tema ampiamente discusso: c’è chi si focalizza sul tipo di funzionalità offerta, chi sul tempo richiesto per risvilupparlo da zero e così via. Quel che è certo è che ogni servizio deve poter scalare autonomamente e che un suo disservizio non deve risultare bloccante per l’applicazione. 

SOA vs. Microservizi 

È bene precisare che il concetto dell’interazione tra servizi era stato già introdotto dalle architetture SOA (Service Oriented Architecture). Non a caso i microservizi sono considerati una evoluzione di questo modello. 

La principale differenza è che nelle SOA si tendeva a far interagire n applicazioni distinte come se fossero servizi, mentre ora abbiamo un’applicazione che al suo interno è composta da n servizi stateless. 

Inoltre, i microservizi comunicano via API (Application Programming Interfaces) e moderni sistemi di message queuing anziché attraverso un tradizionale ESB (Enterprise Service Bus). 

Un esempio concreto: Netflix 

Quando nel 2008 annunciarono la decisione di abbandonare i propri data center in favore di una nuova architettura a microservizi interamente eseguita nel cloud AWS, molti pensarono che il management fosse impazzito. La nuova architettura presentata nel 2014 ha permesso a Netflix di espandersi in 130 paesi e passare da 10 ad oltre 160 milioni di abbonati in tutto il mondo, un primato che prima sarebbe stato impossibile da raggiungere. 

Cosa c’è dietro l’interfaccia che milioni di persone utilizzano quotidianamente? Oltre 700 microservizi, rappresentati nella “costellazione” mostrata per la prima volta proprio durante la conferenza del 2014. 

Ogni singolo elemento dell’interfaccia è gestito da un microservizio: autenticazione, lista dei programmi, suggerimenti, prelievo del file più adatto alla risoluzione del dispositivo etc. 

Quest’approccio ha permesso loro di azzerare i disservizi gravi – l’ultimo risale al 2008 quando avevano ancora un’architettura monolitica – ed effettuare rilasci di patch e nuove funzionalità in pochi minuti. 

Architetture a microservizi: vantaggi e punti di attenzione 

La migrazione verso un’architettura a microservizi porta con sé numerosi vantaggi: 

1. Lo sviluppo di un singolo servizio è più semplice, perciò è possibile utilizzare più team ristretti per aumentare il parallelismo e sfruttare le diverse competenze in azienda. Ogni servizio può essere sviluppato con una tecnologia diversa, perciò si può sperimentare e scegliere il linguaggio più adatto allo scopo. 

2. Essendo tutti indipendenti tra loro, il fault di un singolo servizio non comporta il disservizio dell’intera applicazione. 

3. I servizi possono essere rilasciati in momenti diversi, semplificando il rilascio di patch o nuove funzionalità. Inoltre, possono scalare autonomamente per adattarsi ai diversi carichi di lavoro. 

4. L’isolamento delle componenti aumenta la sicurezza dell’intera applicazione. 

Purtroppo, non è tutto oro quel che luccica. Esistono dei punti di attenzione che con l’esperienza, il giusto approccio e gli strumenti adatti è possibile dominare. 

1. Per cogliere i vantaggi di queste architetture è necessario ripensare il modo in cui i team lavorano e al modo in cui le applicazioni vengono progettate. È vero che i micro-team possono focalizzarsi sul servizio di propria competenza ma è fondamentale avere degli architect che definiscano le linee guida e mantengano una visione d’insieme sul progetto. 

2. All’aumentare dei microservizi aumentano anche le comunicazioni tra di essi. Ciò comporta una serie di rischi connessi alle performance della rete o al fisiologico overhead che questa comunicazione causerà. In caso di problemi, la user experience potrebbe risultarne penalizzata. 

3. Individuare e risolvere problemi di qualunque natura è più complicato perché cresce il numero di fattori che incidono sull’affidabilità e sulle prestazioni dell’applicazione. È necessario valutare sin da subito l’adozione di strumenti per l’Application Performance Management (APM) come Dynatrace, fondamentali per mantenere il controllo e ridurre drasticamente l’effort delle Operations. 

4. La presenza di tanti piccoli database – ogni servizio dovrebbe avere il suo datastore – impone un cambio radicale nella gestione dei dati. Questo vale ancora di più negli ambienti transazionali dove è fondamentale garantire la consistenza dei dati. 

Il modo più efficace per cogliere i vantaggi dei microservizi è definire un percorso evolutivo che comprenda il rinnovamento della cultura aziendale e, ovviamente, tutti gli aspetti tecnici. In questo webinar del 2020, viene presentato un caso di successo focalizzato su questo percorso: TIM, grazie alle tecnologie di Red Hat e Dynatrace e al supporto di Par-Tec, ha completato un ridisegno della propria infrastruttura IT, passando da un modello tradizionale a uno basato su PaaS, container e microservizi.