Microservizi: 7 motivi per usarli

I Microservizi sono diventati ormai un "trend". Ma non c'è diciamo un approccio standard o guidato per il design o l'implementazione di un'architettura a Microservizi. Anzi sembra più che altro vigere l'adozione per sentito dire, o per motivazioni superficiali del tipo: lo facciamo a microservizi perché è scalabile, oppure tutti i grandi nomi usano i microservizi o peggio ancora per moda.

I pionieri dei microservizi come Netflix e Amazon hanno di fatto adottato (e inventato) questa architettura per necessità, capendo che stava diventando difficile riuscire a gestire l'aspetto operativo e logistico dei loro servizi attuali e futuri. Solo dopo i provider l'hanno anche reso un business.

In generale però non è detto che adottare un'architettura a microservizi sia la scelta migliore, e anzi potrebbe anche essere un grosso sbaglio. La verità, poco pubblicizzata in realtà, è che:

Un microservizio singolo è semplice da implementare e gestire. Inoltre da solo probabilmente serve a poco.
Al contrario un'architettura a microservizi può essere molto complessa da progettare, implementare e monitorare. Non è detto poi sia veramente necessaria, o molto spesso lo è solamente in parte.

Per questo ho individuato 7 ragioni per cui ha senso adottare un'architettura a microservizi, anche solo in parte o marginalmente.

Non le prendete come ragioni assolute, sono più che altro quelle che reputo più importanti (in riferimento anche al panorama italiano) e frutto delle mie esperienze sia di successo che insuccesso.

1 - Scalabilità (Orizzontale)

Questo è sicuramente uno degli obiettivi principali, dove ogni servizio dell'architettura può essere scalato in modo indipendente a seconda del bisogno. C'è da fare attenzione però, perché più l'architettura è granulare e più complesso diventa il lavoro di integrazione e monitoraggio. Spesso basta individuare i colli di bottiglia o le funzionalità più critiche e concentrare proprio li gli sforzi.

Attenzione, quando un microservizio è scalabile?
In generale non è detto che un microservizio sia scalabile a prescindere. Sono facilmente scalabili task asincroni, servizi stateless o che ricevono lo stato nella richiesta, servizi atomici e poco accoppiati tra loro. In generale quindi scalano molto bene task autocontenuti, mentre tanto più un servizio ha bisogno di uno stato condiviso e tanto più sarà difficile, o meglio saranno necessari altri meccanismi a contorno di caching e stati distribuiti.

2 - Vincoli Tecnologici

Spesso capita che per risolvere un problema o implementare una particolare feature esista un linguaggio o una tecnologia che vince rispetto alle altre. Ad esempio, nel mondo del Data Science e Machine Learning sicuramente il Python ti apre la strada con numerose librerie, framework e anche community molto attive.

Consigli
Incapsulare le funzionalità che necessitano di linguaggi e tecnologie dedicate in microservizi dedicati. Sarà importantissima l'interfaccia di comunicazione e di fruizione di servizio ( API REST, gRPC, ecc..).

Una volta definita l'interfaccia (magari versionata), il servizio è indipendente e può evolvere sfruttando in ogni momento la tecnologia più adatta.

3 - Team Distribuiti e Multidisciplinari

A volte i Microservizi diventano parte dei processi aziendali con i così detti feature team. Questo succede principalmente in aziende distribuite e che lavorano con team in remoto. In questo caso il lavoro di Analisi e Progettazione diventa fondamentale e guida le scelte operative distribuite sui team. Il microservizio può diventare quindi l'artefatto prodotto da singoli team, che ne sono responsabili in ogni sua parte.

La comunicazione è fondamentale
Il successo dei team distribuiti è la comunicazione, che si ripercuote sulla qualità dell'intero sistema. Di solito più team entrano in gioco e più diventa necessario un allineamento, pattern, e best practice comuni sulle interfacce dei servizi. Quello che si lascia completamente al team è l'implementazione interna del servizio.

Ad esempio a livello aziendale è meglio convergere su una particolare tecnologia per la comunicazione tra servizi, a seconda della tipologia asincrona o sincrona e ovviamente in assenza di vincoli tecnologici sulla comunicazione.

Un appunto su approcci Agili
L'agile in questo caso ha terreno fertile e diventa il collante di processo dei vari team operativi. Tanti più team entrano in gioco e tanto più sarà fondamentale il lavoro di management e coordinazione (Scrum Master, ecc..).

4 - Integrazione con sistemi proprietari (e monoliti)

Questo punto probabilmente riguarda in primis il panorama italiano dove prodotti e sistemi legacy sono sicuramente molto diffusi. Quello che succede spesso è la necessità di integrazione con sistemi e librerie di terze parti diciamo più recenti o sviluppati con filosofie e tecnologie moderne.

Il verso dell'integrazione, se verso il sistema legacy o verso il tool di terze parti o ambedue si solito determina l'entità dell'intervento sul sistema. Sicuramente il caso ideale per lo sviluppo di un microservizio (o più di uno) è quando il sistema legacy deve poter essere interrogato od esporre funzionalità. In questo caso si può decidere se sviluppare un microservizio di integrazione o magari spostare anche parte della business logic in uno o più microservizi e iniziare il processo di Breaking Down the Monolith.

Consigli
I sistemi legacy sono complessi, le funzionalità e il dominio applicativo è accoppiato e dipendente dal framework sottostante (a volte proprietario). Non è assolutamente facile portare fuori funzionalità core, e l'approccio che consiglio in primis è creare microservizi di integrazione e comunicazione, con poca business logic (in sostanza degli Adapter).

5 - Debito Tecnico

Di Debito Tecnico soffrono tutti quei progetti o parti del software che hanno raggiunto una complessità elevata ma che non hanno ricevuto a contorno un adeguato controllo di tale complessità. Capita, purtroppo spesso, di mettere le mani a sistemi di cui si ha una scarsa comprensione delle logiche funzionali del sistema per svariate ragioni, di solito dovute a processi aziendali inadeguati o inesistenti: perdita di conoscenza da turnover, mancanza di documentazione, mancanza di test, ecc...

L'ho messo volutamente dopo il punto 4 perché di solito il Debito Tecnico si paga proprio quando il sistema ha bisogno di integrazione o evoluzione.

Consigli
Quando esistono parti di sistemi dove nessuno vuole mettere le mani, o tecnologicamente obsoleti e non più controllabili ed è necessario aggiungere funzionalità o fare degli interventi... forse è arrivato il momento di ripensarli... In questo caso microservizi dedicati potrebbero essere la scelta giusta.

Attenzione, i microservizi non sono una soluzione per il breve periodo
Se pensate che introdurre microservizi sia una strategia per risolvere i problemi del breve periodo state per fare un enorme sbaglio. Il debito tecnico si paga, sempre!!

In sostanza l'adozione dei microservizi deve essere una strategia di processo, con obiettivi di lungo periodo.

6 - Continuous delivery e Velocità di Deployment

I microservizi sono l'architettura ideale quando si vuole creare una pipeline di Continuous Delivery. In breve quando si ha bisogno di rilasci ed adattamenti frequenti conviene puntare su un'architettura facilmente modulabile e rimodulabile. Adottare un approccio classico rallenta il time to market di nuove feature (anche se solo di test) dato che il deploy della soluzione è unico e impatta tutti i team contemporaneamente. Diventa anche molto difficile tornare ad un checkpoint e/o isolare problemi su nuove feature, i rilasci saranno infatti corposi e poco frequenti.

Attenzione, anche il continuous delivery è parte del processo
Affinché funzioni occorre utilizzare strumenti adeguati. Il continuous delivery deve diventare parte integrante del processo aziendale e deve essere quanto più possibile automatizzato.

7 - Riduzione dei costi e Migrazione a servizi Cloud

In questo caso di solito l'adozione di microservizi sono una conseguenza delle volontà di migrare applicativi o servizi da infrastrutture in house a provider cloud di terze parti. Spesso le motivazioni principali sono legate alla volontà di minimizzare i costi di infrastruttura, migrando da un'infrastruttura in-house ad un provider cloud indirizzando i costi alle sole risorse utilizzate.

La migrazione al cloud deve essere quindi vista come un occasione per l'introduzione di microservizi per riuscire ad ottenere i vantaggi sperati dal punto di vista dei costi.

Attenzione, il monolite non va semplicemente spostato
Spostare il monolite sul Cloud senza interventi architetturali rischia di far lievitare i costi invece che ridurli.