Rispondere rapidamente ai cambiamenti nella domanda di mercato è un requisito chiave per qualsiasi azienda digitale. La metodologia agile è ormai considerata quasi all’unanimità un alleato vincente in questa prospettiva.  Lo abbiamo spiegato in diversi post, come questo . Ma cosa, dietro le quinte, permette di ottenere tutta la flessibilità tipica delle aziende agili? 

Le architetture a microservizi, soprattutto se basate su funzioni serverless, stanno diventando lo standard principale in grado di favorire lo sviluppo agile delle imprese innovative.  

In questo post proveremo a spiegare come, senza addentrarci in risvolti tecnici e con qualche esempio puramente indicativo. Se sei un tecnico e vuoi approfondire il discorso, scarica il White Paper che abbiamo realizzato in occasione del nostro ultimo evento in partnership con AWS. 

Come funzionano le app a microservizi vs app monolitiche 

 
Come nell’esempio che approfondiamo più avanti, immaginiamo un e-commerce che vende diversi tipi di prodotti. Scarpe, accessori, cosmetici, abbigliamento, etc. L’app dovrà occuparsi di diverse funzioni, più o meno “visibili” all’utente finale: ricerca, ordini, magazzino, fatture, mail di conferma, profilazione utenti, etc. 

Per lo sviluppo dell’applicazione possiamo basarci su una struttura monolitica, dove cioè tutte le funzioni sono collegate l’una all’altra in un unico blocco. Ogni cambiamento richiederà un intervento sul codice dell’intera app, in modo da garantire il funzionamento delle varie parti di cui è costituita. Questo comporta un lavoro di “manutenzione” complesso, che toglie tempo e focus alle funzioni di business vere e proprie che quella applicazione si propone di offrire. 

Proprio per ovviare a questa e altre difficoltà, è andato via via affermandosi un modello architetturale basato su microservizi serverless. Questo paradigma permette di eseguire codice isolando dati e responsabilità di ogni funzione, aggiungendo il vantaggio di non dover gestire i server. 

In questo approccio, ogni singolo servizio (ordini, magazzino, mail, etc.) è un componente isolato all’interno dell’architettura di un’applicazione, funziona a sé ed è gestito in modo indipendente. Eventuali modifiche, test e nuove release non influiscono sulle altre funzioni dell’app. Questo tipo di infrastruttura consente agli sviluppatori di concentrarsi solo sulle caratteristiche principali offerte. Inoltre, sfruttando servizi serverless in un approccio a microservizi si ottengono notevoli benefici in termini di costi, scalabilità, alta affidabilità, tolleranza ai guasti. Vediamone alcuni. 

Time-to-market ridotto e meno rischi 

L’approccio a microservizi facilita lo sviluppo agile delle aziende perché nuovi prodotti e servizi possono essere creati ed essere distribuiti più velocemente, senza interruzioni sul funzionamento dell’app. Immaginiamo di introdurre una nuova funzione che suggerisce all’utente abbinamenti di diversi prodotti presenti nell’eCommerce. Funzionerà? Piacerà al mio pubblico? Quale impatto avrà sulle vendite? Potendo testare rapidamente sul mercato nuove funzionalità, si riducono anche i rischi legati al funzionamento dell’intera piattaforma. Al contrario, nelle applicazioni monolitiche le modifiche effettuate su un processo potrebbero influire negativamente su un altro e bloccare o rallentare l’intero servizio. 

Scalabilità automatica 

I microservizi serverless permettono, senza necessità di configurazioni complesse, di aumentare o ridurre la potenza dell’infrastruttura necessaria al loro funzionamento, con un approccio “orizzontale”. Ogni microservizio funziona come diverse auto che trasportano un carico a seconda delle necessità. Non è necessario ogni volta che il carico aumenta procurarsi un mezzo più potente. E’ sufficiente aggiungere una nuova auto che porterà il carico in eccesso. Quando la merce da trasportare diminuisse di nuovo, torneremo ad usare due auto anziché tre, spendendo solo per le auto effettivamente in funzione. Questo permette di risparmiare e migliorare l’esperienza degli utenti. 

Continuità del servizio 

Al contrario di un’applicazione monolitica, quando insorge un problema, questo riguarderà una piccolissima parte del prodotto digitale. I tempi di ripristino saranno più brevi, mentre gli altri servizi continueranno a funzionare. Il tutto, con un disagio minimo per gli utenti e carichi di lavoro ridotti per gli sviluppatori. 

Interoperabilità 

Una volta sviluppati, i microservizi sono facilmente compatibili con diversi tipi di cloud provider, sia su cloud pubblico che privato. Sono quindi “riutilizzabili” in diversi punti dell’infrastruttura che sta dietro a una piattaforma, a seconda delle esigenze.  

Esempio di funzionamento di microservizi 

Torniamo all’esempio iniziale: l’architettura di un eCommerce di diversi prodotti. Quando un utente fa un ordine abbiamo: 

• un microservizio ordine con un proprio database riferito ai dati dell’ordine 
• un microservizio magazzino con un proprio database riferito ai dati del magazzino 
• un microservizio mail con un proprio database riferito ai dati degli utenti per l’invio di una mail di conferma 

Il microservizio ordine contiene i dati dell’ordine e il numero univoco con cui quel prodotto è salvato in magazzino, richiamandolo da quel database. A sua volta darà un input al microservizio mail per l’invio della conferma all’utente che ha lasciato il proprio indirizzo. E così via per altri microservizi che non aggiungiamo per semplicità (es. pagamenti, fatture, resi, etc.). Se insorge un problema nel magazzino di una certa categoria merceologica (es. scarpe), il microservizio ordine continuerà a funzionare per altri magazzini (es. cosmetica), che funzionano indipendentemente, grazie ai relativi microservizi.  

Analogamente, se l’azienda decide di lanciare una nuova linea merceologica (es. accessori), potrà aggiungere un nuovo microservizio magazzino, riferito a un relativo db accessori, non influirà sulla performance degli altri magazzini e dell’intera piattaforma.  

Questo anche perché ogni microservizio è in grado di “scalare” in modo autonomo a seconda dei picchi di traffico, senza pesare sull’intera applicazione. Se avrò un boom di vendite di accessori, il traffico gestito da quel microservizio aumenterà, ma quella degli altri prodotti rimarrà invariata (o potrà diminuire, in base alle richieste degli utenti). In tal modo si garantisce una gestione delle risorse più oculata e all’effettivo bisogno