Simplexity: domare la complessità senza farsi male 🚴‍♂️

Se ti consola, non sei tu a essere complicato: è il sistema. O meglio, sono i sistemi che costruiamo ogni giorno, pezzo dopo pezzo, sprint dopo sprint, workaround dopo workaround. 😅

Negli ultimi anni si è iniziato a parlare sempre di più di simplexity: non come la solita parola d’ordine da conferenza, ma come una postura mentale per progettare sistemi che restano semplici da usare pur accettando che, sotto, la complessità sia inevitabile.

L’idea è stata rilanciata in grande stile dal keynote di Werner Vogels ad AWS re:Invent 2024, ma il punto non è “fare come AWS”. Il punto è chiedersi: come faccio, nel mio contesto molto meno glam, a non annegare nella complessità che io stesso creo?

Spoiler: no, “tenere le cose semplici” non basta. Serve disciplina, onestà intellettuale e un po’ di sana paranoia. Vediamo perché.

Che cos’è davvero la simplexity? 🚦

La definizione operativa, quella utile a chi scrive codice e disegna sistemi, potrebbe essere:

La simplexity è l’arte di spostare la complessità dove pesa meno, mantenendo semplice ciò che gli utenti vedono e toccano.

Qui entra in gioco una legge che dovremmo stampare e attaccare sopra la scrivania:

“La complessità non può essere eliminata, solo spostata” — Tesler’s Law

Tradotto: se rendi semplice qualcosa per qualcuno, qualcun altro sta pagando il conto. Può essere il team di piattaforma, può essere il database, può essere il futuro te stesso che tra sei mesi dovrà capire cosa hai fatto.

La domanda giusta diventa quindi: chi deve portare il peso della complessità, e perché?

La metafora della bicicletta: più pezzi, meno fatica 🚲

Uno dei passaggi più riusciti del keynote è la metafora un po’ controintuitiva tra monociclo, triciclo e bicicletta:

• il monociclo ha pochi componenti, ma richiede abilità enormi per essere usato;
• il triciclo è super stabile, ma goffo e limitato;
• la bicicletta ha più parti degli altri due, ma offre l’equilibrio migliore tra controllo, flessibilità ed esperienza d’uso.

Da fuori, il sistema più “semplice” è spesso quello che dentro ha più ingegneria, più vincoli, più automazioni. Non è minimalista: è intenzionalmente complesso nel posto giusto.

In altre parole: contare i microservizi non è misurare la complessità. La complessità è come quei componenti interagiscono, quanto sono prevedibili, quanto è fragile la catena quando qualcosa va storto.

Complessità intenzionale vs complessità che ti prende alle spalle 🐸

Vogels distingue fra due tipi di complessità:

• intenzionale: quella che introduci consapevolmente per scalare, aumentare resilienza, gestire nuovi casi d’uso;
• non intenzionale: quella che si infila “tra le righe” come il proverbiale ranocchio nell’acqua che si scalda piano.

La seconda è quella che uccide i sistemi (e i team). I segnali sono subdoli, ma ricorrenti:

• non riesci più a farti una mappa mentale di come funziona un servizio;
• debug sempre più lenti e dolorosi;
• feature velocity in caduta libera;
• pattern architetturali incoerenti fra team e componenti;
• dipendenze ovunque e nessuno che sappia perché esistano.

La simplexity, qui, significa una cosa molto poco glamour: riconoscere questi segnali presto e avere il coraggio di fermarsi a ripulire, non solo ad aggiungere altro sopra.

Evolvibilità: se non può cambiare, prima o poi si rompe 🔧

Uno dei punti fissi del keynote è che l’evolvibilità non è un nice to have, è un requisito progettuale.

Spesso confondiamo:

• manutenibilità: fare piccole correzioni locali, bugfix, tweak;
• evolvibilità: poter cambiare struttura, modelli dati, confini di responsabilità, senza dover riscrivere il mondo.

La simplexity chiede di progettare pensando al prossimo salto di scala, non solo al prossimo sprint. In pratica significa:

• scegliere confini che abbiano senso di business, non solo tecnici;
• evitare “mega servizi” che nessuno capisce per intero;
• accettare che ad ogni ordine di grandezza in più (utenti, dati, traffico) l’architettura vada rivista seriamente.

È un patto con il futuro: so che la complessità aumenterà, quindi preparo il terreno perché aumenti in modo governabile.

Spezzare la complessità senza fare finta che siano microservizi 🧩

“Spezzare la complessità” è una di quelle frasi che suonano bene nelle slide e male nei log di produzione.

Simplexity qui vuol dire una cosa molto precisa:

• separare in blocchi ad alta coesione, che fanno poche cose ma le fanno bene;
• definire API chiare e stabili, che non cambiano ogni due settimane;
• tenere ogni servizio abbastanza piccolo da poter stare nella testa di una singola persona competente.

Non è un invito a creare decine di servizi inutili, ma l’opposto: evitare monoliti cognitivi ingestibili. Il metro non è tecnico, è umano: se nessuno riesce a capirlo interamente, quella cosa è troppo grande.

Organizzazione e architettura: se non sono allineate, vince il caos 🧬

Un’altra lezione forte: la tua organizzazione è almeno complessa quanto il tuo software.

Se l’architettura è teoricamente modulare ma i team sono organizzati per strati (frontend, backend, database) e non per domini, quello che ottieni è:

• rilasci lenti perché devi orchestrare mezzo organigramma per ogni cambiamento;
• responsabilità diluita: “non è colpa mia, è colpa dell’altro team”;
• decisioni prese lontano da dove i problemi si manifestano davvero.

La simplexity chiede allineamento: team piccoli, con ownership chiara, che vivono e respirano il dominio che gestiscono. E una cultura dove ci sia una leggera “paura costruttiva”: non panico, ma consapevolezza che il sistema è delicato e va trattato con rispetto.

Cell-based architecture: mettere argini ai problemi 🌐

Quando i sistemi crescono, l’operatività diventa lei stessa un problema complesso. Una delle risposte è pensare in termini di celle:

• ogni cella gestisce un sottoinsieme di clienti o carichi;
• le celle sono isolate, così un incidente rimane confinato;
• sopra c’è un livello di routing e controllo che orchestra il tutto.

È un modo strutturato per applicare simplexity: accetti la complessità del coordinare molte unità più piccole in cambio di una superficie di impatto ridotta quando qualcosa va storto.

Nel quotidiano, il principio si traduce in una domanda semplice: “Se questo servizio esplode, chi porto giù con lui?” Se la risposta è “mezzo ecosistema”, non sei in modalità simplexity.

Prevedibilità batte sofisticazione: l’ossessione per i pattern costanti ⏱️

Uno dei passaggi più controcorrente del keynote riguarda la gestione delle configurazioni e dei flussi operativi: invece di pattern super reattivi ed eleganti, l’enfasi è su pattern prevedibili e costanti.

Il motivo è tanto semplice quanto impopolare: l’incertezza è una forma di complessità. Sistemi che reagiscono in modo diverso a seconda dell’ora, del carico o dell’umore dei retry sono difficili da capire, testare e mettere in sicurezza.

La simplexity favorisce:

• lavoro costante invece che picchi ingestibili;
• polling prevedibile invece di eventi ingestibili se il volume esplode;
• flussi lineari dove possibile, delegando l’intelligenza pesante a componenti progettati apposta.

È meno “cool” da raccontare a conferenza, ma molto più gentile con il tuo on-call.

Automazione: non cosa, ma cosa non automatizzare 🤖

Un altro ribaltamento salutare: invece di chiedersi “cosa possiamo automatizzare?”, la domanda diventa:

“Cosa non dobbiamo automatizzare, perché richiede davvero giudizio umano?”

La simplexity qui è spietata: tutto ciò che è ripetibile, definibile e verificabile va automatizzato. Non per moda, ma perché lascia agli esseri umani lo spazio per occuparsi di casi ambigui, trade-off e scelte di valore.

Altrimenti rischi l’opposto: umani usati come cron job rotti, e sistemi che restano fragili proprio dove dovrebbero essere più solidi (sicurezza, provisioning, recovery).

Il prezzo della semplicità è la disciplina 🧠

Il punto forse più scomodo del discorso sulla simplexity è questo: la semplicità non è un talento, è una disciplina.

Significa accettare che:

• ogni scorciatoia oggi è un debito di complessità domani;
• “poi lo sistemiamo” in realtà vuol dire “poi qualcun altro pagherà il prezzo”;
• dire di no a una feature mal definita è a volte l’atto più etico verso il sistema e verso chi lo dovrà mantenere.

A livello personale, è anche una questione di identità professionale: vuoi essere la persona che aggiunge strati su strati, o quella che è conosciuta per rendere le cose più chiare e più gestibili?

Come portare la simplexity nel tuo team, domani mattina 🧪

Senza rifare l’architettura del mondo, ci sono alcune domande molto concrete che puoi iniziare a porre in team:

• “Chi sta pagando oggi il prezzo della nostra semplicità?” (utenti, SRE, futuro noi?)
• “Questo servizio entra ancora nella testa di qualcuno?” Se no, va sezionato.
• “Abbiamo warning chiari che ci dicano quando la complessità sta esplodendo?” O aspettiamo l’incidente.
• “Cosa stiamo ancora facendo a mano che potremmo automatizzare senza rimpianti?”
• “La nostra struttura di team riflette davvero i nostri domini, o è un retaggio storico?”

Non servono slide, servono conversazioni oneste e un minimo di coraggio. Simplexity non è un pattern architetturale, è un cambiamento culturale: decidere consapevolmente dove mettere la complessità, invece di subirla.

E sì, alla fine l’obiettivo è proprio questo: costruire più biciclette e meno monocicli esistenziali. Perché andare veloci è bello, ma arrivare vivi al traguardo lo è un po’ di più. 😉