Microservizi ovunque, anche quando non servono a niente

Quando l’organigramma diventa architettura

Nel lontano 1967, Melvin Conway formulò una legge devastante: “Le organizzazioni progettano sistemi che sono copie della loro struttura di comunicazione”. Se hai quattro team che non si parlano, avrai quattro servizi che non si parlano. È l’unica legge dell’informatica che gli executive capiscono istintivamente ma fingono di non conoscere.

La Conway’s Law è l’elefante nella stanza di ogni discussione architetturale. Il sistema rifletterà fedelmente i giochi di potere, le rivalità interdipartimentali e i silos organizzativi dell’azienda. Dibattiti su pattern architetturali che sono in realtà guerre su chi controllerà quale parte del sistema. API disegnate non per facilità d’uso, ma per replicare confini dipartimentali.

La realtà è che l’organigramma è l’architettura. Quel CTO che sogna microservizi eleganti mentre gestisce un’organizzazione monolitica sta vivendo in un mondo di fantasia. I segnali sono evidenti: servizi che riflettono la struttura dei team, interfacce inutilmente complicate tra dipartimenti rivali, meeting architetturali che sembrano partite a scacchi politica.

La spesa in ventidue negozi diversi

L’overhead per gestire microservizi è come fare la spesa in ventidue negozi diversi invece che in un supermercato. Teoricamente ogni negozio è specializzato, ma ti ritrovi a fare il giro della città per comprare ingredienti che prima trovavi tutti nello stesso posto. Alcuni negozi sono chiusi, altri vendono le stesse cose, di alcuni ti sei dimenticato l’esistenza.

I costi operativi sono come trasformare ogni stanza in un mini-appartamento: ogni spazio ha bisogno del proprio impianto. Kubernetes, Docker, monitoring, come assumere un amministratore per ogni singola stanza. E indovinate chi paga?

La gestione distribuita è il primo ostacolo. Se qualcosa va storto in un’architettura classica, è come cercare un oggetto in casa: sai dove guardare. Con i microservizi, cerchi in decine di case diverse, ognuna con il proprio sistema di allarme e le proprie regole. Il debugging diventa una caccia al tesoro distribuita.

La latenza di rete introduce ritardi che prima non esistevano. Per passare il sale a tavola devi spedirlo per posta: funziona, ma non è efficiente. E se fallisce? Servono sistemi di retry e complicazioni non necessarie.

La sicurezza distribuita è un incubo. Controlli di identità non solo all’ingresso, ma a ogni porta. Un token dimenticato, un’API mal protetta, e il sistema diventa un colabrodo.

I microliti: microservizi con complessi di inferiorità

Da qualche anno la moda dei microservizi ha conquistato ogni realtà IT, anche piccole aziende. Farli davvero bene è una sfida immensa. Rispettare tutte le linee guida richiede uno sforzo che spesso si scontra con i limiti di tempo e di energia disponibili.

Il passaggio dal monolite ai microservizi ricorda la persona a dieta che mangia trenta fettine sottili di panettone invece di una fetta intera. Hai porzionato, ma le calorie sono sempre quelle. Anzi, nel mondo tecnologico sono aumentate.

Nasce così il microlite: un microservizio realizzato per poter dire “Abbiamo fatto i microservizi”, ma che non rispetta le best practice. Di fatto è un vecchio monolite con troppe responsabilità, travestito da microservizio. Una parola che suona come una condizione medica, e forse lo è.

Uno di questi microliti gestisce le logiche di tre quarti del sistema, mentre altri dieci sono praticamente inutili. Forse tre o quattro non vengono mai chiamati. Ci vogliono tre ore per deployare tutti i pezzi.

Molti microservizi sono servizi con complessi di inferiorità. Alcuni fanno il lavoro di tre persone mentre altri passano le giornate inattivi. E poi ci sono quelli mai chiamati, come quel parente lontano invitato solo per cortesia.

La figurina da collezione enterprise

Aziende che implementano microservizi come figurine da collezione: “Ho deployato il mio trentesimo microservizio!” “E cosa fa?” “Non ne sono sicuro, ma fa molto enterprise!”

Molte aziende aggiungono servizi fino a quando la struttura crolla sotto il proprio peso. I microservizi servono a vantarsi che il proprio sistema richiede il deployment di cinquantaquattro componenti software diversi.

La necessità di abbandonare il monolite era palese: deployare tutto sullo stesso server non era una buona idea. Oggi abbiamo portato questo concetto all’estremo opposto. Non tutti i sistemi necessitano di quarantadue componenti. Ma almeno possiamo dire di essere cloud native e scalabili.

E se qualcuno suggerisce che forse stiamo esagerando, possiamo rispondere con un altezzoso “Tu non capisci i benefici di un’architettura distribuita”, anche se l’unica cosa distribuita è la pazienza nel gestire tutto questo.

Il consiglio ignorato degli esperti

Riecheggia con una nota amara la celebre affermazione: “Non considerare nemmeno i microservizi a meno che tu non abbia un sistema troppo complesso da gestire come monolite”. Per noi italiani suona come “Non comprare una fuoriserie sportiva se devi solo andare a fare la spesa”.

I microservizi sono l’equivalente di trasformare la propria casa in un condominio, dove ogni stanza diventa un appartamento indipendente e per fare colazione devi chiamare un’API al frigorifero. L’overhead necessario è noto e, in molti casi, non sostenibile nemmeno per aziende strutturate con team vasti.

Il problema non è l’idea dei microservizi in sé, che resta valida nel contesto giusto. La questione è che molte organizzazioni seguono la moda invece di valutare razionalmente le proprie necessità.

La domanda da porsi prima di saltare nel vuoto

I microservizi sono impressionanti sulla carta, ma prima di buttarsi bisogna chiedersi onestamente: la nostra architettura è davvero così ingestibile? Abbiamo le risorse e le competenze per gestire la complessità? O stiamo seguendo una moda, come chi compra attrezzatura da palestra professionale per fare tre flessioni al mese?

Un nuovo progetto con due sviluppatori che parte con microservizi è come usare un cannone per uccidere una mosca. La complessità introdotta supererà qualsiasi beneficio teorico.

La morale è semplice: i microservizi possono essere la soluzione giusta, ma solo quando il problema è quello giusto. Prima di spezzettare tutto in decine di componenti, vale la pena chiedersi se non stiamo creando problemi che prima non esistevano, solo per essere alla moda.

Perché alla fine, quando il sistema crolla sotto il peso della propria complessità distribuita, nessuno si ricorderà che eravate cloud native. Si ricorderanno solo che non funzionava.

Questo articolo è tratto da “Non funziona niente! – I progetti IT in crisi”, il primo libro della collana Nothing Works! — una tragicommedia aziendale per chi ha visto troppi Gantt chart trasformarsi in fiction.

Scopri la collana completa, gli altri libri e le prossime uscite su nothingworks.it

Vuoi il libro subito? Compralo su Amazon

Potrebbe interessarti anche

• Sistemista IT in una PMI: mansioni e competenze
• DIRETTORE ACQUISTI
• Perché documentare gli interventi IT potenzia la posizione del Sistemista?
• BACK OFFICE MANAGER
• Da sistemista IT a IT Manager: un, possibile, percorso di carriera nell’ambito manifatturiero
• SOC MANAGER 
• I problemi quotidiani di un Sistemista IT e come risolverli
• SISTEMISTA
• Quanto guadagna un Sistemista a Torino?
• SISTEMISTA IT