Si fa un gran parlare, e certamente noi di MMUL contribuiamo, di come l’universo dei microservizi stia conquistando (o abbia già conquistato) l’ambito delle applicazioni web e non solo. Certamente c’è tanto di vero, ma allo stesso tempo è bene sottolineare come questo tipo di approccio non sia la panacea di tutti i mali.

Insomma, utilizzare Kubernetes non è sempre indicato a prescindere.

Lo racconta con molta chiarezza Christian Posta, che è CTO di solo.io un’azienda che, manco a dirlo, si occupa principalmente di offrire soluzioni in ambito Kubernetes e microservizi.

In questo suo articolo Posta mette le cose in chiaro da subito:

Microservices is not THE “utopian application architecture”.

I microservizi non sono un’utopistica architettura di applicazioni

Indicando principalmente nell’aumento della complessità, tanto di implementazione quanto soprattutto di analisi delle problematiche, lo scoglio principale che dovrebbe far riflettere chiunque pensi che i Microservizi sono qui per risolvere ogni tipo di problema.

Il caso citato nello specifico è quello di Istio, una piattaforma per il monitoraggio dei servizi composta da numerose componenti (in apparenza indipendenti) che necessitano di comunicare l’una con l’altra. La scelta iniziale per questo progetto è stata quella dei microservizi, per tutte le ragioni di scalabilità, ottimizzazione e sicurezza ben note a chi conosce il tema. Solo che alla lunga la gestione del progetto ha pesantemente risentito di questa scelta, tanto che è stato riportato ad una gestione monolitica, principalmente per tre motivi.

1. La modalità con cui gli utenti finali fruiscono del servizio è poco vicina a come questo viene sviluppato. Chi scarica il prodotto non ha sensibilità su questo aspetto, e sicuramente è più predisposto ad usare un unico contenitore piuttosto che tante frammentarie componenti.
2. La gestione delle release è fisiologicamente complicata: come si può avere percezione di quale componente è compatibile con le altre?
3. Il livello di separazione tra le varie componenti è veramente minimo, tanto che non è realisticamente possibile separarle l’una dall’altra (ad esempio a livello di scaling).

Al di là delle riflessioni totalmente condivisibili che potrebbero essere applicate a progetti simili per attitudine, vedi ad esempio OpenStack, la sostanza è che, in questo specifico caso, l’approccio monolitico è sicuramente il più vincente, tanto che che il sottotitolo della documentazione di design di Istiod recita:

“Complexity is the root of all evil or: How I Learned to Stop Worrying and Love the Monolith”.

La complessità è la base di tutti i mali o: Come ho imparato a non preoccuparmi ed amare il Monolitico

E, non fosse altro per la citazione del dottor Stranamore, non possiamo che essere in pieno accordo.