Nelle attività di modernizzazione applicativa, i responsabili IT sono consapevoli di dover scegliere al meglio tra le architetture di microservizi e le piattaforme applicative tradizionali, il modello più usato in passato. Vediamo di capire cosa fa spostare l’ago della bilancia
La modernizzazione applicativa – ci spiega Diego Pandolfi, research & consulting manager di IDC Italia – costituisce oggi una delle principali priorità strategiche di innovazione per oltre il 40% delle imprese. Le aziende riconoscono oggi la necessità di fruire di applicazioni moderne, idonee agli ambienti cloud o accessibili in modalità software-as-a-service (SaaS) e che siano inoltre in grado di utilizzare enormi quantità di dati provenienti da diverse fonti. Per queste ragioni, gli applicativi enterprise oggi devono necessariamente avvalersi di strumenti di advanced analytics e intelligenza artificiale, oltre che di API per gestire le loro integrazioni in un mondo ormai completamente digitale e interconnesso. I principali driver che stanno spingendo le aziende verso la progressiva modernizzazione applicativa sono comunemente la volontà di migliorare le funzionalità core delle applicazioni, aumentare la loro rapidità di sviluppo, senza ovviamente tralasciare la possibilità di ridurre i costi associati alle licenze, migliorare la user experience, la collaborazione, la produttività e l’utilizzo di tutti i dati a disposizione del business.
Nelle attività di modernizzazione applicativa, i leader IT sono chiaramente consapevoli di dover ben ponderare le loro scelte tra architetture a microservizi e piattaforme applicative tradizionali e valutare in modo completo il miglior percorso da seguire per la loro evoluzione in base ai processi e alle attività gestite attraverso l’applicazione stessa e agli ambienti IT utilizzati. Le strategie adottate dalle aziende per la modernizzazione sono diverse: dal lift and shift (rehosting) al replatforming, fino alla riscrittura parziale dell’applicativo (rearchitect/refactoring) o alla completa sostituzione con una soluzione nuova nativamente in cloud (SaaS).
Ogni scelta varia in funzione dell’applicativo e dell’azienda. Per la modernizzazione e la migrazione verso il cloud, una ricerca di IDC mostra come circa il 26% delle aziende italiane stia utilizzando o pianificando di utilizzare un’architettura a microservizi per l’evoluzione degli applicativi tradizionali on-premise. Questa percentuale sale al 40% quando si tratta invece di modernizzare applicativi nativamente cloud. Chiaramente, far evolvere un applicativo verso un’architettura a microservizi impone la riprogettazione della soluzione per ottimizzarne le sue funzionalità per il cloud e quindi seguire, in questo caso, una strategia di refactoring. Un esempio comune di refactoring riguarda la trasformazione di applicazioni monolitiche in architetture di microservizi tramite container. Affidarsi ad architetture a microservizi è una scelta perseguita solitamente quando si vuole modernizzare un applicativo intervenendo in modo sostanziale sul ridisegno di alcune componenti architetturali, riscrivendo parti del codice per meglio adattarlo al cloud. Questo consente alle aziende di trarre i maggiori benefici dagli ambienti cloud, ad esempio maggiori agilità e flessibilità.
ARCHITETTURA DI MICROSERVIZI
Un’architettura a microservizi è strutturata come una suite di servizi liberamente accoppiati che implementano funzionalità di business: i singoli servizi che costituiscono un’applicazione possono essere progettati e configurati per lavorare in modo indipendente condividendo solo minimi componenti di gestione centralizzata. Uno degli obiettivi di questo modello è che i team possano sviluppare e distribuire i propri servizi indipendentemente gli uni dagli altri. In tal modo le organizzazioni sono in grado di sviluppare software con una crescita e una dimensione rapide, oltre a utilizzare più facilmente servizi standard con requisiti di comunicazione ridotti. Questi vantaggi però hanno un costo dovuto al mantenimento del disaccoppiamento, le interfacce devono essere progettate con attenzione e trattate come un’API pubblica al fine di evitare il rischio di interruzione del servizio agli utenti esistenti in caso di modifica del codice del singolo microservizio. Va comunque sottolineato che non esiste un’unica definizione per i microservizi e spesso vengono riconosciuti come tali solo per alcune caratteristiche distintive, tuttavia eterogenee e, non raramente, soggettive.
ARCHITETTURA MONOLITICA
L’architettura monolitica è un modello tradizionale di programmazione software, compilata come un’unità unificata autonoma e indipendente dalle altre applicazioni. Nel contesto tradizionale, il software è stato concepito di fatto come una singola entità, un progetto unico, sviluppato con un solo linguaggio di programmazione, distribuito in un unico pacchetto gestito da un file eseguibile. Si tratta di un modello per sua natura molto efficace nel contesto on-premise, che ha condizionato varie stagioni della storia evolutiva del software, finendo inevitabilmente per subire i segni del tempo, soprattutto nell’ottica in cui un’applicazione viene concepita come un insieme di servizi molto eterogenei.
I monoliti facilitano la gestione del codice, il sovraccarico cognitivo e la distribuzione e possono dunque risultare pratici nelle prime fasi di un progetto, poiché queste caratteristiche consentono di rilasciare in una sola volta tutti gli elementi al loro interno. Tuttavia, man mano che le applicazioni diventano complicate, spesso il rimedio è la crescita verticale, ottenuta espandendo l’hardware con l’aggiunta di altri server oppure sviluppando verticalmente l’applicazione. Ogni singola modifica comporta la ridistribuzione dell’intera applicazione, mediante la pubblicazione di un nuovo eseguibile. Questa evidenza comporta una serie di conseguenze piuttosto gravose da gestire. Non è infatti possibile risolvere al volo un problema, ma occorre pianificare l’uscita di una serie di service update che raccolgono una serie di migliorie e bug fixing, il che costringe gli utenti a lunghi attese prima di vedere implementata una funzione che, da sola, potrebbe richiedere non più di qualche ora di lavoro per uno sviluppatore. Il modello monolitico preclude inoltre una gestione a distribuzione continua di tipo continuous delivery che sia totalmente trasparente per l’utente finale.
In tempi più recenti, anche facendo riferimento soltanto alle criticità appena espresse, si è sentita più che mai viva l’esigenza di variare l’approccio monolitico, spostando la complessità a livello della gestione del progetto, per alleggerire e rendere più snelle le procedure sui singoli processi. Il monolite viene dunque scomposto in vari servizi, mediante una specializzazione orientata a distinguere le parti funzionali. Questo consente agli sviluppatori di concentrarsi soltanto su una parte del software, contribuendo alla creazione dei singoli pacchetti che compongono l’applicazione complessiva.
METTIAMOLE A CONFRONTO
Nell’approccio monolitico, un’applicazione che supporta più funzioni dovrebbe essere ridimensionata nella sua interezza anche se solo una di queste funzioni avesse un vincolo di risorse. Con i microservizi, solo il microservizio che supporta la funzione con vincoli di risorse deve essere ridimensionato, fornendo così vantaggi di ottimizzazione delle risorse e dei costi. Quello che distingue l’architettura basata su microservizi dagli approcci monolitici tradizionali è proprio la suddivisione dell’app nelle sue funzioni di base. Un microservizio non è un livello all’interno di un’applicazione monolitica, ma piuttosto una funzionalità aziendale autonoma con interfacce chiare che può, attraverso i propri componenti interni, implementare un’architettura a più livelli. Da una prospettiva strategica, l’architettura di microservizi segue essenzialmente la filosofia Unix di “Fai una cosa e falla bene!”. È comune che le architetture di microservizi vengano adottate per applicazioni cloud native ed elaborazioni serverless. I singoli microservizi possono essere ridimensionati individualmente.
Un passaggio fondamentale nella definizione di un’architettura di microservizi è capire quanto deve essere grande un singolo microservizio. Non c’è consenso o cartina di tornasole per questo, poiché la risposta giusta dipende dal contesto aziendale e organizzativo. È considerata una cattiva pratica rendere il servizio troppo piccolo, poiché l’overtime di runtime e la complessità operativa possono superare i vantaggi dell’approccio. Quando le cose diventano troppo dettagliate, è necessario prendere in considerazione approcci alternativi, come impacchettare la funzione come libreria o spostare la funzione in altri microservizi.
Nelle architetture monolitiche tutti i processi sono strettamente collegati tra loro e vengono eseguiti come un singolo servizio. Ciò significa che se un processo dell’applicazione sperimenta un picco nella richiesta, è necessario ridimensionare l’intera architettura. Aggiungere o migliorare una funzionalità dell’applicazione monolitica diventa più complesso, in quanto sarà necessario aumentare la base di codice. Tale complessità limita la sperimentazione e rende più difficile implementare nuove idee. Le architetture monolitiche rappresentano un ulteriore rischio per la disponibilità dell’applicazione, poiché la presenza di numerosi processi dipendenti e strettamente collegati aumenta l’impatto di un errore in un singolo processo.
Le architetture di microservizi permettono invece di scalare e sviluppare le applicazioni in modo più rapido e semplice, permettendo di promuovere l’innovazione e accelerare il time-to-market di nuove funzionalità. Se vogliamo sintetizzare, possiamo dire che i microservizi devono essere autonomi cioè ognuno può essere sviluppato, distribuito, eseguito e ridimensionato senza influenzare il funzionamento dell’architettura complessiva, e specializzati, cioè progettati per una serie di capacità che si concentrino sulla risoluzione di un problema specifico. La progettazione di architetture di questo tipo – ci ricorda IDC – consente di apportare modifiche rapide ai singoli moduli all’interno di un’applicazione, permettendo in questo modo la rapida distribuzione di aggiornamenti e correzioni, nonché la possibilità di ottimizzare le prestazioni di un’applicazione e di ridurre i costi di aggiornamento e di eventuali ulteriori modifiche. Le architetture di microservizi, inoltre, consentono una maggiore agilità e velocità nel processo di sviluppo del software, offrendo agli sviluppatori la libertà di distribuire il codice alla produzione per moduli indipendenti responsabili di funzionalità applicative diverse. Per loro natura, le architetture di microservizi abilitano al riuso: «Il concetto del riuso dei servizi – ci dice Carlo Bozzoli, global CIO di Enel Group – estende quello del riuso del codice perché oltre a permettere risparmi legati al semplice sviluppo e manutenzione consente anche di fare economia di risorse infrastrutturali: lo stesso microservizio può servire più applicazioni senza necessità di istanziazioni multiple».
AGLI OCCHI DEL BUSINESS
In base ai risultati di una recente ricerca di IDC, tra le principali soluzioni sulle quali si focalizzeranno le strategie di modernizzazione degli applicativi nelle aziende italiane spiccano quelle di business analytics/big data, finance e accounting, gestione delle risorse umane, supply chain management, sales e marketing. Sul lungo termine, l’adozione di un’architettura a microservizi sarà sicuramente in grado di garantire all’azienda un risparmio di costi, ad esempio sulle implementazioni, sullo sviluppo e sui requisiti infrastrutturali, ma anche una maggiore capacità dell’applicativo di adattarsi ai cambiamenti richiesti, aggiungendo nuove funzionalità o modificando quelle esistenti, a seconda delle evoluzioni dei processi gestiti o delle nuove esigenze di business.
È probabile che i microservizi siano popolari tra i dirigenti e i responsabili di progetto almeno quanto lo sono tra gli sviluppatori. Il motivo risiede nel fatto che i microservizi riflettono meglio il modo in cui molti business leader vogliono strutturare e portare avanti i loro team e i processi di sviluppo. I microservizi promettono alle organizzazioni un antidoto alla profonda frustrazione associata a modifiche di piccola entità che richiedono un enorme dispendio di tempo. Non è necessario un dottorato in informatica per vedere o capire il valore di un approccio che facilita meglio la velocità e l’agilità. L’accoppiamento in modo lasco dei microservizi sviluppa anche un certo grado di isolamento dei malfunzionamenti e una migliore resilienza nelle applicazioni. Le piccole dimensioni dei servizi, poi, combinate con i loro chiari confini e pattern di comunicazione, consentono ai nuovi membri del team di comprendere più facilmente la base di codice e di apportarvi il loro contributo rapidamente, un chiaro vantaggio in termini sia di velocità sia di morale dei dipendenti.
I microservizi, insomma, permettono di ottenere vari vantaggi. Il primo è in termini di agilità e organizzazione del lavoro: essendo di piccole dimensioni, e dedicati a singole funzioni, i microservizi risultano più semplici da sviluppare e gestire tra i team. Con i microservizi, inoltre, il time-to-market di rilascio di nuovi prodotti si riduce, perché lo sviluppo diventa meno problematico, più fluido e rapido. Scalabilità e flessibilità sono superiori, in quanto le performance di ciascun microservizio si possono espandere in modo indipendente, utilizzando risorse distribuibili su molteplici server. L’adattabilità alle esigenze di business è favorita dal fatto che i microservizi si possono considerare mattoncini di codice riutilizzabili in modo semplice e rapido per creare sempre nuove funzionalità. Utilizzando API per comunicare tra loro, essi garantiscono anche una maggior apertura all’integrazione con altre applicazioni e servizi. Tale capacità d’integrazione di applicazioni e servizi di terze parti consente di espandere i propri canali di distribuzione e sviluppare la propria offerta di prodotti e servizi attraverso nuove partnership commerciali. Ancora: l’architettura di microservizi si presta a far proprio il metodo Agile, il cui obiettivo fondamentale, nello sviluppo software, è saper rispondere al cambiamento continuo delle esigenze dell’utente. Velocità ma non solo, un altro vantaggio è quello di abilitare Un modello organizzativo emergente comune che consiste nell’aggregare dei team interfunzionali intorno a un servizio, un prodotto o un problema di business. Il modello di microservizi si adatta perfettamente a questa tendenza perché consente a un’organizzazione di creare piccoli team interfunzionali intorno a un servizio o una raccolta di servizi e di farli lavorare in modo agile.
AGLI OCCHI DELL’IT
I vantaggi dei microservizi sono numerosi e importanti anche a livello di gestione dell’IT. La gestione e l’evoluzione del software diventano più semplici spingendo a creare codice il più possibile pulito e flessibile. La fase di deployment del codice è semplificata dalla compatibilità dei microservizi con le metodologie di sviluppo di tipo continuous integration e continuous deployment, mentre, in termini di adattabilità tecnologica, i microservizi non pongono vincoli, e possono essere sviluppati scegliendo i linguaggi e le tecnologie più appropriati per gli scopi da raggiungere.
Come già accennato, la natura indipendente di ciascun microservizio lo rende un componente costituito da codice e funzioni riutilizzabili. Con i microservizi è possibile non solo implementare ma anche ridimensionare ogni singolo servizio separatamente. Il vantaggio che ne deriva è ovvio: eseguiti in modo corretto, i microservizi richiedono meno infrastruttura rispetto alle applicazioni monolitiche perché consentono un ridimensionamento preciso dei soli componenti che lo richiedono, invece dell’intera applicazione come nel caso delle applicazioni monolitiche. Uno degli aspetti più evidenti dell’utilizzo dei microservizi è dato dalla possibilità di sfruttare tutti i vantaggi derivanti dal cloud computing, che consentono di eliminare i costi relativi alle infrastrutture e alle risorse IT necessarie per sostenere le fasi di sviluppo, collaudo e implementazione delle applicazioni, potendo inoltre contare sulla scalabilità, sulla sicurezza e sugli ambienti di sviluppo pronti all’uso che i provider PaaS (Platform as a Service) mettono a disposizione. Il risultato è quello di poter creare applicazioni più semplici da mantenere ed aggiornare lungo l’intero ciclo di vita.
I microservizi sono alla base delle pratiche di continuous delivery che consentono ai team di adattarsi rapidamente ai requisiti degli utenti ed è per questo che la loro adozione va spesso di pari passo con l’approccio DevOps. L’architettura software basata su microservizi e API si posiziona come la più indicata per realizzare e amministrare nel tempo applicazioni in evoluzione continua, come le moderne app digitali. Usando un’architettura a microservizi diventa più facile e rapido creare prodotti e servizi agili, innovativi e rispondenti alle dinamiche del mercato. «Oltre ai benefici in termini economici e di resilienza applicativa, questo paradigma fa bene anche all’ambiente – ci ricorda Bozzoli – e per questo in Enel abbiamo costruito la Enel Digital Platform (EDP), lo strumento che ci permetterà di gestire la complessità e creare applicazioni moderne con il minor effort possibile. La Enel Digital Platform mette in comunicazione i dati aziendali con le solution delle varie divisioni attraverso un layer di servizi messi a disposizione di tutti. EDP è anche la nostra porta d’accesso verso una strategia multi-cloud, in cui rendiamo le nostre applicazioni agnostiche rispetto all’infrastruttura su cui girano. Ad oggi abbiamo già più di un fornitore di servizi cloud e i nostri sviluppatori possono scegliere quale usare in base alle proprie necessità. Le architetture a microservizi sono fondamentali per spostare i carichi di lavoro da un cloud provider all’altro senza interruzioni in base alle necessità, la ricetta per il successo è dare agli sviluppatori gli strumenti giusti per lavorare agevolmente con questo paradigma».
IN FIN DEI CONTI
I microservizi non sono assolutamente la soluzione ottimale a tutti i pensieri; tuttavia, sono in grado di risolvere un discreto numero di problemi dei software e delle aziende in crescita. Dal momento che un’architettura di microservizi è costituita da unità eseguite in modo indipendente, ogni servizio può essere sviluppato, aggiornato, distribuito e ridimensionato senza influire sugli altri servizi. Gli aggiornamenti software vengono eseguiti con maggiore frequenza, in modo più affidabile e con prestazioni e tempo di attività migliorati. Siamo passati dal rilascio di aggiornamenti una volta alla settimana a due o tre volte al giorno. I microservizi costituiscono con ogni probabilità l’alternativa più diffusa al tradizionale modello monolitico, anche se non sono certamente l’unica opzione a disposizione degli sviluppatori viso che ci sono anche i Web service e la service oriented architecture (SOA).
Diffusione a parte, microservizi potrebbero non essere la soluzione migliore per tutti. Un monolite legacy può funzionare alla perfezione e potrebbe non valere la pena di scomporlo. Ma, via via che le organizzazioni crescono e le richieste sulle applicazioni aumentano, l’architettura di microservizi potrebbe essere la giusta soluzione. Come ci ricorda Pandolfi di IDC: «Alcuni aspetti critici da considerare nel passaggio verso architetture a microservizi potrebbero essere invece l’eventuale vendor lock-in che si potrebbe creare con il fornitore di servizi di public cloud, i tempi più lunghi per una modernizzazione e migrazione applicativa che implica la riscrittura del codice e la necessità di disporre di avanzate competenze interne di sviluppo e di processi DevOps, fondamentali per evitare errori a livello di codice, configurazione e infrastruttura. In generale, quindi, è richiesto uno sforzo progettuale maggiore».
Chiaramente, il modello della “piattaforma” applicativa è ancora valido, in quanto questa tipologia di soluzione mantiene i suoi vantaggi, tra cui prestazioni ottimali e la capacità di gestire processi complessi come l’esecuzione di transazioni commerciali specifiche (es. transazioni bancarie o elaborazione di indennizzi assicurativi). Molte realtà, soprattutto in aree di business molto complesse, preferiscono l’adozione di piattaforme applicative tradizionali per la loro formula collaudata e la possibilità di gestire in modo centralizzato processi differenti, anche se spesso queste soluzioni sono più difficili da aggiornare e più costose da mantenere. Un aspetto da considerare del modello a piattaforma è che qualora si rendesse necessario, però, apportare delle modifiche all’applicativo, gli interventi impatteranno l’intera piattaforma, con un effort maggiore in termini di costi e risorse. Chiaramente è possibile far evolvere anche questa tipologia di soluzioni verso gli ambienti cloud, attraverso strategie di rehosting o replatforming, anche se i principali fornitori di piattaforme prevedono già oggi in molti casi un’offerta nativamente SaaS, che consente di raggiungere tutti i benefici di scalabilità, flessibilità e interoperabilità tipici degli ambienti cloud. Anche le piattaforme, quindi, stanno evolvendo e i principali vendor offrono già soluzioni as-a-service pronte all’uso, di facile installazione, con modelli di prezzo flessibili e opzioni agili di configurazione e gestione.
Che non bisogna mai dimenticare l’obiettivo della trasformazione ce lo ricorda ancora Carlo Bozzoli: «Mentre completavamo la migrazione in cloud ci siamo resi conto che per poter sfruttare al massimo le opportunità di questa tecnologia bisognava fare un ulteriore passo, l’adozione di un modello software basato sui microservizi e sulle applicazioni modulari. La scelta delle architetture a microservizi, sebbene sia stata fatta principalmente per massimizzare il potenziale del cloud, ci ha permesso di accedere a una serie di benefici ulteriori facendo in modo che l’Enel Digital Platform sviluppata diventasse anche la porta d’accesso verso una strategia multi-cloud, in cui si possono rendere le proprie applicazioni agnostiche rispetto all’infrastruttura su cui girano. Questo è importante per spostare i carichi di lavoro da un cloud provider all’altro senza interruzioni in base alle necessità».
