Non esiste un'architettura di default

Ogni discussione di architettura in cui vengo chiamato ha già la sua risposta decisa prima che io arrivi. Non per analisi: per moda, o per quello che diceva l’ultimo talk a una conferenza, o per il lavoro precedente di un senior. La risposta arriva per prima e il ragionamento viene montato dietro.

Il ragionamento di solito è buono. È questo a renderlo difficile da contestare. Quello che manca non è la logica, è il passo prima della logica: nessuno ha scritto i vincoli.

La domanda che riordina la stanza

Quando un team mi dice che andrà a microservizi, chiedo una cosa sola: chi fa il deploy di questa roba un mercoledì pomeriggio, quando qualcosa non va?

Non “riusciamo a scalarlo”. A quella sanno rispondere tutti, e la risposta è sempre sì. La domanda del mercoledì è diversa, perché riguarda il sistema come verrà davvero gestito, dalle persone che lo gestiranno davvero, nel giorno che nessuno aveva previsto.

Le risposte sono rivelatrici. A volte c’è un team di piattaforma di sei persone con una reperibilità, e i microservizi sono una risposta ragionevole a un problema di coordinamento vero. Molto più spesso ci sono due sviluppatori, uno dei quali fa anche il frontend, e la risposta onesta è nessuno, e ce ne accorgeremmo giovedì.

Non è un argomento contro la distribuzione. È un argomento sul fatto che distribuire ha un costo operativo, che quel costo lo pagano persone con nome e cognome, e che dovrebbe stare sul tavolo accanto al beneficio.

Quali sono davvero i vincoli

Nelle aziende piccole e medie, i vincoli che decidono l’architettura non sono quasi mai quelli che stanno nel diagramma dell’architettura. Sono:

• Quante persone lo manterranno, e per quanto tempo. Un design che ha bisogno di quattro ingegneri per restare coerente marcisce con due.
• Cosa l’azienda già gestisce. C’è un ERP, un gestionale contabile, un CRM. Sono portanti. Qualsiasi design che dia per scontato di poterli sostituire è il design per un’altra azienda.
• Quanto è davvero il budget infrastrutturale. Non la cifra aspirazionale: quella sulla fattura.
• Quanto in fretta cambia il dominio. Un dominio stabile tollera confini rigidi. Un dominio ancora in scoperta li punisce, perché li tracci nel posto sbagliato e poi difendi l’errore.

Nessuno di questi è tecnico. Ed è il motivo per cui un’architettura scelta su basi solo tecniche è di solito scelta sulle basi sbagliate.

Quattro forme, e quando ciascuna si guadagna il posto

Il monolite modulare. Confini interni netti, una sola unità di deploy, un solo database su cui ragionare. È il default corretto molto più spesso di quanto gli venga riconosciuto, ed è la forma per cui mi trovo più spesso a perorare contro un team che ha già deciso altrimenti. Il suo vantaggio vero non è la semplicità: è che i confini costano poco da spostare. Li hai tracciati male; li traccerai male; in un monolite è un refactor invece che una migrazione.

L’orientata ai servizi. Servizi divisi lungo le linee di responsabilità, con contratti versionati di proposito. Si guadagna il posto quando le cadenze di rilascio di più team hanno cominciato a scontrarsi — quando il costo di coordinamento di un deploy condiviso è diventato più grande del costo operativo di deploy separati. È una soglia vera e si attraversa. È solo molto più lontana di quanto i team credano.

L’event-driven. I sistemi emettono eventi; le reazioni sono disaccoppiate da ciò che le ha provocate. È la forma giusta quando un processo attraversa davvero strumenti che nessuno vuole accoppiare — dove l’alternativa è una ragnatela di integrazioni punto a punto che nessuno riesce a disegnare su una lavagna. È la forma sbagliata quando viene applicata uniformemente, come cerimonia attorno a chiamate che in ogni senso utile sono sincrone.

La pipeline dati e ML. Ingestione, preprocessing, training, serving, ciascuno osservabile per conto suo. Quando il prodotto è la previsione, questa non è un’architettura tra le tante: è la forma del problema. L’errore qui è trattare il modello come il sistema e la pipeline come idraulica, che è al contrario: nella pipeline sta la riproducibilità, e senza riproducibilità un modello è un aneddoto.

La parte che non è architettura

Quasi tutto ciò su cui si discute come architettura è in realtà una domanda sull’organizzazione. La legge di Conway viene citata di solito come osservazione, ma funziona meglio come vincolo di progetto: se non sei disposto a cambiare chi parla con chi, non sei libero di scegliere la forma che preferisci.

Quindi la sequenza utile è: prima i vincoli, poi l’organizzazione, poi la forma. Farlo nell’ordine opposto produce un diagramma su cui in riunione sono tutti d’accordo e che nessuno riesce a far funzionare di mercoledì.

Cosa consiglio davvero

Parti dalla forma più piccola che regge il vincolo che sai di avere, e progetta i confini perché una forma più grande resti raggiungibile. In concreto significa quasi sempre: un deploy solo, confini interni veri, nessun modulo che entra nei dati di un altro, e integrazione attraverso contratti espliciti.

È una postura che costa quasi nulla da mantenere e tiene aperte tutte le porte. Estrarre un servizio più avanti è l’evoluzione di un modulo che aveva già un confine. Estrarre da un monolite senza confini è una riscrittura, ed è il motivo per cui tante migrazioni a microservizi finiscono come la versione distribuita dello stesso disordine.

Non esiste un’architettura di default. Esiste solo la più piccola che sopravvive ai tuoi vincoli — e la disciplina di scrivere quei vincoli prima che qualcuno disegni un rettangolo.