Microservizi e container costituiscono un’alternativa più moderna al tradizionale modello software basato sull’architettura monolitica. Capiamo perché
Nel lessico del cloud, microservizi e container rappresentano una costante, soprattutto quando si parla di applicazioni “cloud-native”. La loro compresenza è tuttavia fonte di frequente confusione, in quanto alcune volte i due termini vengono utilizzati impropriamente come sinonimi funzionali, quando in realtà rappresentano due tecnologie del tutto differenti, pur complementari nel loro utilizzo.
A prescindere dal loro impiego, i microservizi e i container sono accomunati dal fatto di costituire un’alternativa più moderna al tradizionale modello software basato sull’architettura monolitica, che per intere generazioni ha spadroneggiato nelle infrastrutture IT on-premises. Per tali ragioni, come vedremo nel dettaglio, microservizi e container costituiscono gli elementi fondamentali per modernizzare le applicazioni, altro mantra che sentiamo nominare spesso, quando si parla di rendere più efficienti e scalabili gli ecosistemi software su cui si basa il flusso operativo digitale delle aziende.
Vediamo dunque, in sintesi, cosa sono microservizi e container, in cosa differiscono e come sia possibile utilizzarli profittevolmente insieme, senza tralasciare ovviamente alcuni punti critici che dobbiamo assolutamente tenere in considerazione qualora dovesse venirci in mente di migrare un’applicazione monolitica in cloud.
Cosa sono i microservizi
Secondo la definizione di Gartner, il microservizio è “un componente applicativo service oriented debolmente accoppiato […] e pertanto implementabile e scalabile in maniera indipendente”. Per avere una percezione semplice del concetto di microservizi è sufficiente far riferimento alla loro architettura, in particolare per gli elementi che la distinguono rispetto alla tradizionale architettura monolitica.
Il software monolitico, come il nome stesso suggerisce, è basato su un’unica applicazione e viene in genere distribuito con un eseguibile che ne consente l’installazione sui sistemi in locale. L’architettura monolitica ha l’indubbio vantaggio dell’elevato livello di comunicazione che intercorre tra i suoi componenti ma, per contro, risulta difficile da aggiornare e gestire in maniera agile, come richiesto dalle metodologie di sviluppo di moderna concezione, come DevOps, che ormai costituiscono uno standard sempre meno differibile.
Utilizzando un’architettura monolitica, se volessi variare una feature in un singolo modulo, sarei costretto a ridistribuire l’intera applicazione. Tale modello, tuttora valido nei sistemi legacy, risulta alquanto problematico da gestire in cloud, in quanto non è in grado di sfruttare i vantaggi in termini di agilità e scalabilità che contraddistinguono gli ambienti IT della nuvola. Tale modello sarebbe oltretutto inattuabile nell’ambito di alcune applicazioni, come quelle e-commerce, che possono prevedere anche più deploy nel corso di una giornata.
L’architettura a microservizi nasce pertanto per decomporre il monolite in più parti, in grado di essere disaccoppiate e gestite in maniera autonoma. Queste parti sono appunto definite microservizi, e possono essere sviluppati in maniera indipendente. Ogni microservizio può equivalere ad una determinata funzione del software complessivo. I singoli microservizi non costituiscono un unico blocco applicativo, come nel caso del software monolitico, ma comunicano tra loro tramite le famigerate Application Programming Interface (API).
I due vantaggi essenziali dei microservizi sono il disaccoppiamento, che consente ad esempio di sviluppare ogni modulo con un differente linguaggio di programmazione, e la possibilità di riutilizzo per comporre differenti applicazioni. Per facilitare l’agilità dei processi di sviluppo e l’orchestrazione dei vari elementi in chiave IT governance entrano pertanto in gioco altre tecnologie, tra cui i container.
Cosa sono i container
Volendo definirli nel modo più semplice possibile, i container sono dei contenitori virtuali che consentono di eseguire un’applicazione.
In altri termini, il container è un ambiente di sviluppo completo che isola tutti i processi e le applicazioni necessarie al runtime di un determinato software, in modo da non dover virtualizzare l’intero hardware, come accade ad esempio nel caso delle tradizionali macchine virtuali. Il tutto senza rinunciare ad un livello di astrazione molto elevato e agile da gestire anche da chi non è propriamente un drago degli hypervisor.
Tale approccio consente una serie di evidenti vantaggi.
I container possono essere eseguiti come i semplici applicativi di un sistema operativo, lanciando anche più istanze analoghe dello stesso servizio, senza dover riconfigurare tutto ad ogni avvio: la classica notizia che farebbe brillare subito gli occhi di chi ad esempio si occupa di testing delle applicazioni. L’avvio dei container è sostanzialmente molto rapido e gli ambienti di sviluppo sono assolutamente personalizzabili, proprio per adattarsi a contesti applicativi molto specifici. È infatti possibile predisporre il codice, le dipendenze, le librerie, i file binari e ovviamente i file di configurazione della app che intendiamo eseguire.
Il container unisce dunque due vantaggi fondamentali: personalizzazione elevata e disponibilità rapida.
Il container va pertanto preparato, creando nel dettaglio l’ambiente di esecuzione per definire le immagini in grado di eseguire l’applicazione che contengono al loro interno. A questo punto, una volta eseguita l’immagine come istanza, ogni modifica viene salvata all’interno del container specifico, senza influenzare l’immagine originale, che rimane disponibile per avviare ulteriori processi.
Si tratta del resto di uno dei vantaggi fondamentali offerti delle tecnologie di virtualizzazione, che creano risorse astratte rispetto al loro substrato fisico, il che consente la configurazione di ambienti virtuali ad hoc per qualsiasi esigenza, consolidando al tempo stesso l’hardware effettivamente disponibile.
È facile intuire come l’utilizzo dei container acceleri notevolmente i cicli di rilascio delle applicazioni, ottimizzando i tempi e i relativi costi, unitamente alla facilità con cui diventa possibile gestire le fasi di creazione di un software e la sua successiva manutenzione.
Le moderne applicazioni cloud-native possono prevedere anche migliaia di container, gestiti da team differenti, con tecnologie differenti, con tempi di sviluppo differenti, ospitati su cloud differenti. Se lo sviluppo del singolo servizio diventa più agile, la straordinaria varietà dell’intero progetto comporta una naturale complessità di gestione, che va necessariamente pianificata a monte.
Per garantire la corretta visibilità di un progetto di sviluppo containerizzato si ricorre dunque all’orchestrazione, che a livello operativo consiste in software in grado di monitorare e gestire tutti i container di un progetto a prescindere dalla loro posizione: on-premises, su cloud pubblico, privato o ibrido. L’orchestratore attualmente più diffuso è basato sulla tecnologia open-source di kubernetes. Saper utilizzare e configurare tali tecnologie rappresenta una delle competenze attualmente più ricercate nel contesto delle professioni legate allo sviluppo.
Microservizi e container: in cosa differiscono
Sulla base delle definizioni che abbiamo analizzato nei precedenti paragrafi, emerge che tra microservizi e container insista una differenza di natura sia tecnologica che funzionale. I microservizi si pongono sul piano dialettico e funzionale dell’architettura IT, andando a comporre le parti stesse del software. I container, all’atto pratico, sono degli ambienti di sviluppo virtuali che consentono di eseguire i microservizi stessi, mettendo a loro disposizione tutte le tecnologie di cui necessitano.
Entrambi sono accomunati dai criteri di scalabilità ed agilità dello sviluppo di moderna concezione, oltre che da un’elevata portabilità, essenziale in cloud e garantita dal fatto che il container contiene tutte le istruzioni necessarie per essere eseguito ovunque allo stesso modo. Questi fattori rendono i microservizi e i container tecnologie ideali per implementare le applicazioni cloud-native, per sfruttare inoltre tutti i vantaggi offerti dalle tecnologie di virtualizzazione.
Come utilizzarli insieme per modernizzare le applicazioni
Container e microservizi vedono la loro adozione congiunta soprattutto in due contesti: lo sviluppo di nuove applicazioni, cloud-native di nome e di fatto, e la migrazione in cloud delle applicazioni legacy, in particolare per quanto concerne il cosiddetto replatforming.
Pur di complessa esecuzione, il replatforming di un’applicazione consente di sfruttare le opportunità del cloud in maniera più mirata rispetto al rehost “lift and shift”, che rischia di portare nella nuvola le stesse qualità che già coesistevano in locale, nel bene e nel male.
Una strategia di replatforming consente di adottare un approccio incrementale nella migrazione delle applicazioni legacy in cloud. Solitamente si procede selezionando i componenti critici, per cui lo sforzo, come si suol dire, vale la candela in termini di benefici che è possibile ottenere in cloud.
L’iter di un replatforming prevede una notevole varietà applicativa, anche sulla base delle competenze specifiche del team di sviluppo chiamata a gestirla. In genere si parte con la decomposizione di un software monolitico in vari pacchetti, che vanno ridefiniti nell’architettura come microservizi. A questo punto diventa possibile “containerizzare i microservizi”, ossia modernizzarli grazie agli strumenti agili che i vari servizi in cloud mettono a disposizione degli sviluppatori.
Volendo diventare sempre più moderni, lo step successivo sarebbe costituito dal serverless, un livello di ulteriore astrazione delle risorse, il cloud-native puro, che rende del tutto trasparente all’utente finale qualsiasi percezione dell’infrastruttura IT necessaria per eseguire i processi richiesti dalle applicazioni. Si tratta dell’ambiente di sviluppo in cui un programmatore può davvero pensare soltanto a svolgere il proprio lavoro, senza porsi minimamente il problema delle risorse necessarie per i vari test e deploy, dal momento che tutto viene gestito in automatico dai CSP (Cloud Service Provider).
Il replatforming consente quindi di ridurre i costi e soprattutto i rischi di un programma di migrazione di un software legacy, anche nell’ottica di rendere molto rapido il ROI (Return of Investment) del progetto. Al tempo stesso, i vantaggi di agilità e scalabilità del cloud consentono di porre solide basi per la completa migrazione del software, attuabile in più fasi, che possono articolarsi anche su un piano pluriennale.
Un approccio mirato e progressivo consente inoltre di assorbire a piccole dosi la complessità a livello IT, per quanto riguardo la necessaria orchestrazione dei microservizi distribuiti per mezzo dei container. Non ci stancheremo mai di ricordare come un progetto lacunoso in termini di IT governance rischia di rivelarsi un pesante capitombolo per qualsiasi iniziativa di modernizzazione, rendendo addirittura controproducenti gli effetti rispetto alle intenzioni.
Il replatforming costituisce dunque un esempio particolarmente rappresentativo della collaborazione di strumenti cloud oriented come microservizi e container, grazie alla cui sinergia i software tradizionali rinascono come cloud-native, adeguandosi ad un modello di fruizione a servizi (es. SaaS) sempre più diffuso, sia in ambito professionale che in ambito consumer.
