Per chi lavoro
Mi cercano quando il sistema regge, ma nessuno sa spiegare perché. O quando smette di reggere e nessuno sa spiegare cosa è cambiato.
Il CTO con un monolite che nessuno vuole toccare. La startup che ha scalato prima dell'infrastruttura. L'azienda che paga il cloud tre volte quello che dovrebbe, ma non sa dove tagliare senza rompere qualcosa.
Non lavoro solo con chi ha problemi. Lavoro anche con chi vuole capire cosa ha, prima che diventi un problema. Un assessment fatto bene costa meno di un'emergenza gestita male.
Se la tua infrastruttura funziona "perché nessuno la tocca", il problema non è l'infrastruttura.
Come lavoro
Parto sempre dall'assessment. Prima di toccare qualsiasi cosa, guardo cosa c'è e perché è fatto così. A volte la risposta è: non serve cambiare niente.
Non vendo tecnologia. Se il problema si risolve con un processo, lo dico. Se non serve il mio intervento, lo dico. Preferisco un cliente che torna tra un anno a uno che resta per inerzia.
Non arrivo con una soluzione in tasca prima di aver capito il problema. Non propongo di riscrivere tutto da zero, perché quasi mai serve e il rischio è enorme. Non inseguo la moda tecnologica: se il sistema attuale regge, cambiarlo va giustificato, non dato per scontato. Quello che resta dopo il mio intervento è un sistema descritto, costi spiegabili e un team che sa andare avanti senza di me.
Appunti di lavoro
Speranza ben formattata
GitHub Actions diceva tutto verde. Cron eseguito, exit code 0, nessun errore nei log. Sabato 9 maggio 2026, apro il blog. Il briefing della settimana non c'è.
Sei moduli Terraform, due ambienti, zero copincolla
Costruisci staging a mano, poi costruisci produzione a mano, poi passi il resto della vita a chiederti perché sono diversi.
AWS ti dà 50 modi per isolare. Te ne servono 3.
AWS offre cinquanta meccanismi di isolamento. In questo contesto, ne sono serviti tre.