Architettura a microservizi: Caratteristiche e vantaggi

La capacità delle aziende di adeguare le applicazioni alle mutevoli esigenze di business dipende in gran parte dal framework architetturale sottostante. Un’architettura rigida e obsoleta non permette la dovuta flessibilità per apportare modifiche in un’ottica di maggiore scalabilità, velocità e performance delle applicazioni enterprise. Per questo motivo, il tradizionale approccio alla progettazione delle applicazioni viene sempre di più sostituito da un pattern architetturale distribuito: l’architettura a microservizi.

Le principali caratteristiche dei microservizi sono: 

• Autonomia: l’indipendenza e il disaccoppiamento dei microservizi permettono ai team di organizzarsi autonomamente e concentrarsi su un dominio più ristretto e con una superfice di cambiamento più piccola. Ciò consente all'azienda di cambiare ed evolvere rapidamente i servizi in base alle esigenze del business senza dover riscrivere l'intera applicazione. 

• Scalabilità: i microservizi sono estremamente scalabili e consentono all’azienda di ridimensionare velocemente le sue risorse per gestire i picchi di traffico o le richieste dell’utente. Essi possono anche essere distribuiti su più macchine per garantire una maggiore resilienza e affidabilità nella rete. 

• Cloud Ready: questo modello architetturale garantisce l’elasticità di poter decidere nel tempo, qualora ce ne sia bisogno, di spostare alcuni componenti software sul Cloud o integrare dei servizi PaaS nel proprio dominio. 

• API business oriented: i microservizi collaborano tra di loro attraverso interfacce di programmazione di applicazioni (API) standardizzate. Ciò permette l’utilizzo di diversi linguaggi di scrittura e l’adozione di diverse tecnologie. 

I microservizi rappresentano un modello ampiamente utilizzato dalle più grandi società high-tech, come Netflix, Amazon Prime, Spotify, Airbnb e Twitter. Infatti, queste realtà si basano su migliaia di microservizi che gestiscono quotidianamente miliardi di richieste da parte degli utenti. Ogni microservizio è responsabile di una singola funzionalità della piattaforma, come, ad esempio, lo stato del pagamento mensile, l’algoritmo che individua i contenuti preferiti dell’utente, la messa in memoria delle serie tv viste, la classificazione dei contenuti più poplari del momento.

I principali punti di debolezza di un’architettura monolitica sono: 

• Nello sviluppo: un sistema monolitico di grandi dimensioni presenta una struttura complessa e, spesso, poca chiara per la mancanza di documentazione degli interventi svolti nel passato. Il rischio di regressioni funzionali è alto ed è causa di timori nel team nel momento in cui sono richieste evoluzioni funzionali. Inevitabilmente, si accumula debito tecnico e rallenta l’intero processo di sviluppo. Inoltre, l’evoluzione di un singolo componente richiede il deployment dell’intera applicazione. 

• In termini di performance: il monolite non è concepito per scalare orizzontalmente e verticalmente all’infinito. Risulta difficile aggiungere risorse computazionali e scalare oltre un certo numero di nodi. Quindi, è evidente che il sistema monolitico non garantisce la flessibilità oggi necessaria alle aziende di espandersi e contrarsi in base a un maggior o minor carico di richieste. 

• Nello stack tecnologico: Un’applicazione monolitica è costruita con un'unica tecnologia. Se da una parte ciò comporta una minor richiesta di competenze specifiche e limitate ad una sola tecnologia, dall’altra, coesistono problemi di scalabilità generazionale e di eterogeneità. Infatti, risulta difficile adottare un componente di nuova generazione o passare a una versione più recente dello stesso poiché, come spesso accade, la versione inizialmente adottata di un servizio viene personalizzata a tal punto da renderla parte integrante del sistema. Il monolite, inoltre, a causa dello stack tecnologico unico, dipende fortemente da un solo vendor, impedendo all’azienda di liberarsi da alcuni servizi non più convenienti senza causare impatti negativi sull’intero sistema informatico. 

Tuttavia, l’architettura monolitica presenta alcune caratteristiche positive che l’hanno portata ad essere la scelta primaria per sviluppare applicazioni fino a pochi anni fa. La realizzazione di un monolite come un oggetto unico e coeso permette di semplificare l’intero processo di sviluppo, utilizzando un singolo ambiente di sviluppo e un unico stack tecnologico. Ciò richiede meno competenze interne rispetto all’uso dei microservizi e permette una messa in esercizio più agevole, tramite la “pacchettizzazione standard dell‘applicazione” e la successiva consegna al team Ops per la messa in produzione.  
Inoltre, l’architettura a microservizi richiede diversi punti di attenzione, tra cui: 
• La complessità del sistema: con un numero maggiore di servizi distribuiti, l'interazione tra di essi può diventare complessa da gestire e richiedere l’implementazione di nuove pratiche collaborative, come DevOps, per coordinare lo sviluppo, il testing, la distribuzione e l'operazione dei microservizi; 
• Maggiori skill di progettazione e gestione: questo pattern architetturale richiede delle competenze specifiche e un’organizzazione bilanciata del team in grado di far crescere velocemente le figure junior; 
• Maggiore complessità nella gestione dei processi transazionali: è richiesto un meccanismo di coordinamento per garantire l'integrità dei dati e la coerenza delle operazioni; 
• Difficoltà con un dominio innovativo: quando i bounded context non sono “stabili” possono portare a sovrapposizioni o lacune funzionali tra i servizi, causando problemi di responsabilità e coordinamento;

L’adozione di architetture a microservizi presuppone delle modalità di gestione agili in grado di supportare l’intero ciclo di vita di ogni servizio. L’aumentato grado di complessità dell’architettura a microservizi richiede una rafforzata collaborazione tra Dev e Ops per supportare pienamente la molteplicità dei servizi, la differenza dei linguaggi di sviluppo e il processo di deployment degli stessi.

A proposito di questo tipo di trade-off architetturali, recentemente è stato pubblicato un caso studio da parte di Amazon Prime Video sulla transizione da microservizi a monolite, creando dibattito negli ambienti IT. L’architettura a microservizi, ampiamente riconosciuta come una best practice per lo sviluppo e la modernizzazione delle applicazioni, è stata considerata da una diversa prospettiva: quella del suo impatto sui costi dell’infrastruttura. Nonostante, soprattutto per applicazioni complesse, è generalmente conveniente dal punto di vista economico il ricorso a architetture a microservizi, per questo caso specifico è stato dimostrato che era possibile ridurre i costi del 90% passando da microservizi a un’applicazione monolitica. In particolare, in origine il team aveva utilizzato componenti serverless ( per esempio, AWS Step Functions or AWS Lambda) per creare una funzionalità di monitoraggio dei video visualizzati con componenti distribuiti. Tuttavia, si sono resi conto che questa architettura poteva essere semplificata tornando ad un approccio monolitico piuttosto che distribuito. Di conseguenza, hanno deciso di impacchettare tutti i componenti in un’unica unità logica e di utilizzare l'orchestrazione per controllarne i componenti, arrivando così a ridurre drasticamente i costi infrastrutturali.