Architettura a Microservizi: cos’è e perché utilizzarla

Nonostante la recente costituzione, l’architettura a microservizi rappresenta ormai un ambito più che mai consolidato soprattutto nell’ambito dello sviluppo software e il suo straordinario successo si deve essenzialmente ad una ragione: il cloud e il Software as a Service (Saas), le cui applicazioni cloud native hanno adottato pienamente un modello di sviluppo basato sulle metodologie agili, decisamente agli antipodi rispetto al tradizionale modello di sviluppo monolitico.

In questo servizio cercheremo di fare chiarezza sui microservizi soprattutto in relazione a due aspetti: in cosa differiscono rispetto alle architetture tradizionali e quali sono i vantaggi che è possibile ottenere, senza trascurare le criticità che potrebbero vanificare l’investimento nel modernizzare le applicazioni.

Cosa sono i microservizi?

I microservizi sono architetture IT che consentono di supportare la creazione del software con una logica orientata alla gestione separata dei singoli servizi che compongono l’applicazione completa. Sfruttando le potenzialità degli ambienti di sviluppo in cloud ed in particolare del PaaS (Platform as a Service) consentono di svolgere in maniera agile le fasi di sviluppo, test e implementazione delle applicazioni.

A prescindere dalle tecnologie che la contraddistinguono, per cogliere appieno il senso di un’architettura a microservizi è opportuno comprendere quali sono le differenze concettuali tra un software a servizi e un tradizionale software monolitico.

Il software monolitico è concepito a tutti gli effetti come una singola entità progettuale, sviluppata con un unico linguaggio di programmazione e distribuita in pacchetto unitario con un file eseguibile di riferimento. Per anni ha costituito uno standard di riferimento assoluto ed è tuttora diffuso nel contesto on-premises, dove il software è distribuito con installazioni localizzate su ogni singola macchina.

Il modello monolitico, pur essendo decisamente lineare e semplice nella logica di gestione, risulta decisamente poco agile e francamente inadatto per supportare un modello a servizi come il SaaS, basato su una logica di rilascio continuo (continous delivery) e soprattutto su progetti di natura complessa, che vedono la confluenza di molti moduli funzionali da aggiornare in maniera estremamente frequente.

Il software on-premises risulta funzionale al modello monolitico in quanto viene aggiornato sulla base di un versionamento periodico, che consiste in genere in una patch da scaricare ed applicare in autonomia sulle varie macchine dove è presente l’applicazione principale.
Il software in cloud non prevede installazioni in locale. Vi si accede remotamente attraverso un browser o una local app. L’onere di aggiornare il SaaS è esclusivamente a carico del fornitore del servizio (Cloud Service Provider), che rilascia il software in maniera del tutto trasparente all’utente finale, che non deve minimamente preoccuparsi di quale versione sta utilizzando, dal momento che la routine di rilascio continuo ne rende disponibile soltanto una: la più aggiornata, sulla base di una strategia di rilasci che può prevedere anche più deploy nel corso della giornata.

Le architetture a microservizi nascono sulla scia di modelli come il SOA (Service Oriented Architecture) con un focus specifico sullo sviluppo del software, ribaltando totalmente il concetto monolitico in favore di uno modello agile, basato sulla decomposizione del “monolite” tradizionale in più pacchetti, cui corrispondono i singoli elementi funzionali che compongono il software.

Tali pacchetti vengono disaccoppiati, in modo da risultare il più possibile indipendenti tra loro durante le fasi di sviluppo e risultare combinabili nell’applicazione di riferimento. Questo comporta quindi un’agilità intrinseca data dal possibile riutilizzo dei vari pacchetti per struttura applicazioni differenti oltre al fatto di poter aggiornare i vari moduli del software senza dover ricompilare l’intera struttura.

Sulla base di questa premessa, vediamo dunque quali sono i principali vantaggi introdotti dall’architettura a microservizi nell’ambito dello sviluppo software, in modo da descrivere più nel dettaglio in cosa effettivamente consiste.

I vantaggi dell’architettura a microservizi

Le architetture a microservizi risultano funzionali sia nello sviluppo da zero di nuove applicazioni cloud native, che nel refactoring di software basato su architettura monolitica, grazie ad operazioni di suddivisione, abbastanza semplici sul piano teorico quante ricche di insidie a livello pratico. Vediamo nel complesso quali sono i vantaggi generici che l’adozione di un modello di sviluppo basato sull’architettura a microservizi consente di adottare.

Apertura e linguaggi di programmazione

Dal momento che le API sono indipendenti dal linguaggio di programmazione, ogni componente può essere sviluppato utilizzando una tecnologia differente, senza che ciò comporti alcun vincolo per i team di sviluppo attivi sulle altre parti dell’applicazione. In senso più ampio, la possibilità di impiegare più linguaggi di programmazione consente di utilizzare la tecnologia più efficace in funzione della funzione da creare.

Codice riutilizzabile in più progetti

La decomposizione del software in vari moduli funzionali comporta di impiegare le funzioni previste per più progetti, in quanto la scrittura di un modulo non si esaurisce nell’applicazione stessa, come accade nel caso di un’architettura monolitica.
Il riutilizzo delle parti di software già scritte comporta buone capacità di integrazione ma agevola moltissimo la composizione e il lancio di nuove applicazioni. Il riuso del codice può equivalere inoltre ad un più o meno sensibile contenimento di tempi e costi di sviluppo;

Manutenzione e distribuzione più semplice

Grazie al supporto del CI/CD (integrazione e distribuzione continua) è possibile utilizzare le istanze dei vari componenti per testare più soluzioni e dare all’applicazione un maggior contributo in termini di innovazione, oltre che agevolare complessivamente i processi legati alla manutenzione e all’aggiornamento;

Resilienza delle applicazioni

A differenza di un’architettura monolitica, l’architettura a microservizi dispone di servizi per definizione indipendenti tra loro. Nel caso in cui un componente venisse interessato da una criticità sarebbe possibile intervenire isolando soltanto la funzionalità coinvolta, senza dover cessare l’impiego dell’intera applicazione;

Riduzione del time-to-market

Grazie all’abbreviazione dei cicli di sviluppo dovuta in buona parte alla facilità di testing, i deploy e gli aggiornamenti diventano più agili, veloci e semplici da gestire, ciò è possibile grazie ad una miglior accessibilità generale, che consente agli sviluppatori di comprendere e aggiornare i componenti dell’applicazione in maniera più rapida. Questi aspetti sono tanto più rilevanti se adeguatamente supportati da una metodologia di sviluppo Agile;

Scalabilità in cloud

Se i carichi di lavoro determinati da alcuni servizi aumentassero nel tempo, sarebbe possibile distribuire i relativi microservizi su più server, assecondando le esigenze aziendali. La stessa flessibilità si dimostrerebbe utile nel caso in cui si assistesse ad una contrazione dei servizi.

Le criticità dell’architettura a microservizi

Se i vantaggi architetturali appaiono palesi, vi sono tuttavia una serie di situazioni in cui l’impiego dei microservizi potrebbe rivelarsi un’arma a doppio taglio. Ciò accade soprattutto quando si sottovaluta l’impegno generale o si incorre in un project management di scarso successo. Possono infatti costituire una criticità i seguenti fattori:

Agile ma complesso da gestire

La gestione di molteplici servizi da un lato consente di gestirli in maniera agile, ma gli oneri nella fase di gestione del progetto crescono sensibilmente considerando che i team di sviluppo possono essere anche tra loro molto differenti sia per quanto riguarda le tecnologie utilizzate sia per quanto concerne le competenze ed il livello di esperienza.

Orchestrazione onerosa

L’orchestrazione rappresenta una delle fasi cruciali per il successo di un’architettura a microservizi. Agile per definizione, rischia di diventare molto complessa ed onerosa nel caso in cui si debbano gestire addirittura centinaia di servizi differenti, anche se sul piano concettuale maggiore è la complessità del progetto, maggiore è il possibile beneficio che si può trarre grazie all’orchestrazione. A parte il gioco di parole, l’aspetto cruciale, quando le dimensioni e le complessità del progetto aumentano, diventa essenziale l’automatizzazione dei servizi.

Test e integrazione

Se la containerizzazione agevola lo sviluppo dei test sui vari pacchetti dell’applicazione, il discorso può complicarsi eccome quando si tratta di testare l’intera applicazione prima dei deploy. Anche in questo caso diventa fondamentale l’automatizzazione, soprattutto per le app a distribuzione continua che prevedono rilasci molto frequenti in produzione.

Comunicazione tra i servizi

Rispetto all’architettura monolitica, integrata per definizione, le architetture a microservizi vedono gran parte del loro successo nell’efficacia della comunicazione tra i vari componenti dell’applicazione. Non è sempre semplice garantire adeguati livelli di latenza per instradare le comunicazioni nel modo migliore, soprattutto quando i processi attivi sono molti. Dal punto di vista logico la decomposizione tende a far prevalere un numero elevato di servizi, dal punto di vista pratico sarebbe opportuno cercare di limitare il più possibile la frammentazione, in quanto rischia di complicare oltremodo la comunicazione a livello dell’applicazione generale.

Gestione dei database

Nel caso di un’architettura a microservizi, il modello classico di un database centralizzato potrebbe andare in crisi nel garantire l’accessibilità dei dati ai vari componenti dell’applicazione. Potrebbe rendersi pertanto necessario partizionare il database, con tutte le complessità che ne derivano. Anche in questo caso, la soluzione è nell’elevato livello di automatizzazione nella gestione del database.

Quando conviene utilizzare un’architettura a microservizi?

Modernizzare le applicazioni grazie ai modelli a servizi ha tutto il senso in determinate circostanze, ma non equivale certamente alla panacea di tutti i mali, anzi, spesso può implicare un inutile complicarsi la vita, imbarcandosi in progetti laddove i tempi e i costi di gestione supererebbero nettamente quelli dedicati allo sviluppo vero e proprio.

Nel caso di applicazioni molto semplici, per cui è prevista l’azione di un piccolo team, se non di un singolo programmatore, l’architettura monolitica può continuare a costituire la miglior alternativa possibile, soprattutto se si presume un ciclo di vita del software relativamente breve, tale da non comportare un processo di manutenzione molto rilevante in termini di ore.

La scelta della metodologia di sviluppo e dell’architettura da utilizzare non segue regole assolute. Certo, ci sono degli standard tipologici che valgono pressoché nella stragrande maggioranza dei casi. Se dovessimo implementare una piattaforma gestionale per un insieme di servizi, la scelta di un’architettura a microservizi sarebbe di gran lunga la soluzione più probabile, ma nel caso di una app mobile monofunzione senza particolari necessità di integrazione, uno sviluppo di tipo tradizionale potrebbe andare benissimo.

Per il resto la scelta di un’architettura piuttosto che un’altra dipende soprattutto dall’esperienza e dalla sensibilità nel saper valutare caso per caso tutti i pro e i contro che una scelta implica rispetto all’altra, anche in relazione alle risorse umane, tecnologiche ed economiche di cui effettivamente si dispone.

Microservizi in container

Quando si cercano in rete informazioni relative ai microservizi, si legge molto spesso di container, piuttosto che di applicazioni containerizzate. Ma cosa vuol dire esattamente? E perché i container sono così importanti?

I container: dove i pacchetti del software prendono forma

I container sono ambienti di sviluppo in cui le applicazioni possono essere eseguite tramite istanze, per cui sono molto utilizzati soprattutto nella fase di sviluppo e testing, dove si distinguono grazie alla loro flessibilità. In altri termini, i vari pacchetti del software vengono eseguiti in un container, mantenendo la loro indipendenza reciproca.

Anche se a prima vista potrebbero apparire simili alle macchine virtuali, i container sono in realtà molto più semplici in quanto non si occupano dell’astrazione delle risorse hardware, ma vengono eseguiti come semplici applicazioni, la cui esigenza principale è quella di rimanere isolata, in modo da poter gestire le istanze software in esecuzione senza dover intervenire sul sistema operativo host.
Qualora si verificasse un problema in fase di test, sarebbe sufficiente rilanciare l’istanza pulita ed effettuare tutte le modifiche del caso, senza dover reinstallare nulla sul sistema operativo host. L’isolamento di un container è tuttavia più leggero, almeno di base, rispetto a quello delle macchine virtuali. La ragione di questa scelta è dettata proprio dalla funzione per cui sono stati concepiti: rendere disponibile un ambiente in cui eseguire le istanze delle applicazioni, e nient’altro. I container vengono impiegati prevalentemente per lo sviluppo di applicazioni cloud native e ne esistono varie versioni, tra cui i container Linux e i container Docker.

I container coinvolti nello sviluppo di un’applicazione sono indipendenti, pertanto si rende necessaria l’azione degli orchestratori, in modo da gestirli e distribuirli in maniera assolutamente resiliente.

Gli orchestratori: strumenti per la gestione unificata delle applicazioni

Se il container rappresenta uno strumento eccellente per distribuire e soprattutto eseguire le applicazioni, gli orchestratori consentono di avere una visione unificata di tutti i container attivi nel contesto di un progetto di sviluppo, dal momento che potrebbero trovarsi su cloud diversi, avere linguaggi di programmazione differenti, ecc. tutti aspetti che ci interessano relativamente dal punto di vista funzionale, sempre in virtù della decantata indipendenza delle applicazioni containerizzate.

La tecnologia di orchestrazione più celebre per gestire i container Linux è costituita da Kubernetes, una piattaforma open source concepita in maniera specifica per la gestione dei carichi di lavoro e servizi containerizzati, che può essere visto a tutti gli effetti come un’evoluzione, almeno sulla carta più efficiente, dei servizi di deploy virtualizzati. Tra le altre cose, Kubernetes consente di:

• Scoprire i servizi e bilanciare i carichi dei container;
• Creare nuovi container ed eliminare i controller esistenti non più necessari;
• Orchestrare lo storage on-prem e in cloud, montando in modo automatico almeno un sistema di archiviazione;
• Ottimizzare le richieste hardware necessarie per eseguire i container;
• Automatizzare le routine e adottare misure di autoriparazione per riavviare i container bloccati o eliminare/sostituire quelli irrimediabilmente compromessi;
• Indirizzare il traffico soltanto verso i container pienamente operativi, rendendo temporaneamente inattivi quelli che non rispondono con successo agli health check.

Alcuni esempi di architettura a microservizi

Le architetture a microservizi vengono utilizzate con molta frequenza quando si sviluppano applicazioni che prevedono servizi per gli utenti, con un elevato livello di interazione. Un caso estremamente diffuso è costituito dall’e-commerce.

La struttura di un’applicazione e-commerce prevede di base un frontend, con cui si interfacciano i clienti durante il processo di acquisto, e un backend, con cui l’azienda gestisce tutte le dinamiche necessarie per rendere operativo il servizio: dall’inserimento dei prodotti nel catalogo, all’evasione degli ordini fino alla gestione dell’eventuale customer care integrato nel sito internet aziendale.

A titolo puramente esemplificativo, un’applicazione e-commerce potrebbe essere composta almeno dai seguenti servizi:

• Interfaccia sito web (frontend)
• Interfaccia applicazione mobile (frontend)
• Catalogo prodotto
• Configuratore di prodotto
• Carrello
• Wishlist
• Sistema di pagamento online
• Creazione degli ordini
• Gestione degli ordini
• Form per le recensioni

Di fatto questi moduli, in parte funzionali al frontend ed in parte al backend dell’intera applicazione, possono essere gestiti in autonomia da differenti team di sviluppatori, con un project manager che si occupa di avere la visibilità totale sul progetto. Risulta inoltre evidente come alcuni moduli, come il sistema di pagamento online, con ogni probabilità dovrà essere affidato in outsourcing ai fornitori di questa specifica tipologia di servizi, lasciando all’azienda cliente la semplice integrazione nell’applicazione principale.
Il rapporto tra frontend e backend delle applicazioni e-commerce è facilmente riconoscibile anche in altri esempi di architettura a microservizi, come l’internet banking, i sistemi di fatturazione elettronica, i portali web per la fornitura di energia, e molti altri.