Da monolite a microservizi: come far evolvere un’applicazione legacy

La trasformazione digitale ha introdotto innovazioni tecnologiche, software e applicative, che si sono dimostrate estremamente vantaggiose per le aziende. Per questo, sono sempre di più le imprese che stanno adottando nuovi paradigmi di sviluppo software. Tuttavia, per ottenere implementazioni di successo, nella maggior parte dei progetti, c’è un ostacolo importante da superare: la modernizzazione dei processi e dei paradigmi.

Applicazione monolitica: che cos’è

Un tempo le applicazioni erano sviluppate e distribuite come singole unità: applicazioni monolitiche, con una sola base di codice, facili da implementare in piccole dimensioni, ma inadatte a crescere ed evolversi. I componenti essenziali di un’applicazione con architettura monolitica (interfaccia utente, sistema di autorizzazione, database, logica di business) hanno la caratteristica di essere combinati e integrati in un solo programma.

Se prendiamo ad esempio un e-commerce, la sua realizzazione secondo il modello a monolite richiederebbe l’implementazione di tutte le funzioni – dalla visualizzazione dei prodotti, al carrello, alle funzioni di pagamento – tramite una sola base di codice. Questa caratteristica, al crescere dell’applicazione, potrebbe generare grossi problemi di gestione.

Complessità dell’architettura monolitica

Le applicazioni basate su una struttura software monolitica presentano diverse limitazioni. Vediamole nel dettaglio.

Manutenibilità

Quando occorre modificare, aggiornare e aggiungere funzionalità, la base di codice aumenta facendo crescere le dimensioni dell’applicazione. Quando un’applicazione diventa troppo grande e complessa, risulta anche complicato comprenderla nella sua interezza e apportare cambiamenti, anche se piccoli, senza andare a toccare l’intero sistema.

Velocità

Con questa architettura, diventa difficile fare rilasci frequenti, perché, per aggiornare un componente, occorre eseguire il deployment da zero dell’intera applicazione. C’è poi anche la possibilità che i componenti che non sono stati direttamente coinvolti nella modifica subiscano dei danneggiamenti o rallentamenti e tali rischi connessi con il redeployment finiscono per scoraggiare le pratiche di aggiornamento frequente.

Scalabilità

Contenendo al suo interno tutte le funzionalità, ed essendo caratterizzata da un’architettura in cui servizi sono strettamente integrati e interdipendenti, un’applicazione monolitica diventa difficile da scalare, perché una modifica per ottenere la scalabilità di un singolo aspetto determina un impatto sull’intera applicazione. Per risolvere tale inconveniente, la soluzione è in genere implementare una scalabilità orizzontale, duplicando la funzione interessata in un cluster, o creando nuove istanze dell’applicazione stessa.

Affidabilità

Il verificarsi di un malfunzionamento in qualunque modulo del programma è potenzialmente in grado di compromettere o bloccare l’intero processo e la disponibilità dell’applicazione.

Microservizi: cosa sono e come possono aiutare

I microservizi rappresentano un approccio innovativo allo sviluppo software: un’applicazione può essere realizzata sviluppando diversi servizi modulari indipendenti, che interagiscono tra di loro per completare le stesse attività. In sostanza, ogni componente dell’applicazione può essere implementato in maniera indipendente ed essere eseguito come servizio, responsabile di una specifica funzione e in grado di comunicare con gli altri attraverso API (Application Programming Interface). In questo modello architetturale, il malfunzionamento di un servizio non compromette necessariamente il funzionamento dell’intera applicazione.

La medesima applicazione ecommerce di cui sopra, realizzata secondo il modello a microservizi, potrebbe essere modificata e scalata in tutti i suoi componenti senza alcuna difficoltà. Ad esempio, se dovessi modificare il gateway di pagamento potrei intervenire direttamente sul microservizio che ha in carico quella funzionalità, senza intaccare le altre parti dell’applicazione.

Microservizi e cloud-native: i vantaggi rispetto all’applicazione monolitica

L’approccio a microservizi, grazie alle più moderne tecnologie, come Kubernetes, Docker e i container, può inoltre essere inserito nel modello di sviluppo applicativo cloud-native: questo modello permette di disaccoppiare il software dall’hardware e di sfruttare i vantaggi che il cloud offre in termini di flessibilità e agilità nella gestione delle risorse.

Facendo leva su un’architettura distribuita, un modello di sviluppo applicativo cloud-native a microservizi consente di ottenere diversi benefici.

Agilità di sviluppo

La possibilità, per differenti sviluppatori, di lavorare in contemporanea su singoli componenti e servizi appartenenti alla medesima applicazione, consente di snellire il ciclo di progettazione, riducendo il time-to-market. 

Supporto delle strategie CI/CD

I microservizi facilitano l’applicazione delle metodologie di integrazione continua e distribuzione continua (CI/CD – continuous integration/continuous deployment) del codice, alla base del modello DevOps. Ad esempio, quando occorre aggiornare un componente, è sufficiente fare il deployment solo di quel particolare servizio, e non dell’intera applicazione.

Scalabilità

Ciascun servizio può essere scalato in maniera indipendente dagli altri, e distribuito su più server e infrastrutture. 

Affidabilità

Con un’architettura a microservizi, il verificarsi di un malfunzionamento in un componente/servizio non ha ripercussioni sul funzionamento degli altri, perché ciascuno di essi è stato sviluppato in maniera indipendente. In questo modo, a differenza di un’applicazione con architettura monolitica, l’applicazione a microservizi non crolla, ma continua a funzionare e, nel frattempo, è possibile riparare il problema nel componente malfunzionante e rieseguirne il deployment.

Modernizzare i sistemi: da monolite a microservizi

Lo sviluppo a microservizi, realizzato secondo il modello cloud-native, può essere utilizzato per evolvere i sistemi legacy: sistemi software aziendali datati, basati su codice obsoleto, ma ancora largamente in uso perché di fondamentale importanza per l’azienda. Questi sistemi IT sono tipicamente legati a un’architettura centralizzata, molto difficile da interfacciare con i sistemi moderni e con i diversi canali.

Poiché supportano funzionalità mission-critical, non possono (e non devono) essere eliminati o sostituiti, ma possono essere modernizzati, applicando sopra di essi uno strato di software in grado di realizzare tutti i servizi e le logiche di business customizzati, necessari all’azienda.

Questo strato di software è la piattaforma a microservizi, che consente di separare i sistemi legacy sottostanti dalle logiche custom. Con un approccio incrementale, è possibile realizzare tutti i servizi e le personalizzazioni necessarie, mantenendo in vita i sistemi legacy e allegerendone il carico di lavoro. In questo modo, è possibile far evolvere i sistemi nel tempo e, se necessario, sostituire – per esempio – un gestionale datato con uno più moderno, senza interrompere i processi e perdere le evolutive realizzate sugli altri componenti (canali, app interne, business intelligence etc.)

I benefici sono sia in termini di produttività – realizzazione, aggiornamento, scalabilità e distribuzione delle applicazioni – sia in termini di gestione dei cicli di sviluppo – offrendo un’esperienza di sviluppo e gestione automatizzata e ottimizzata.

In conclusione, far evolvere le applicazioni monolitiche e i sistemi legacy aziendali fornisce all’impresa molteplici vantaggi che si traducono anche in riduzione del time-to-market, abbattimento dei costi dell’IT e miglioramento della customer experience.

Mockup da Freepik.