Alessio Cantarella in Connected enterprise. Costruire l’impresa connessa: architetture, dati e AI, vol. 2, giugno 2026, pp. 24-26
Negli ultimi anni, il superamento delle architetture monolitiche è stato raccontato come un passaggio inevitabile verso sistemi più agili, scalabili e resilienti. Microservizi, cloud-native e containerizzazione hanno promesso una nuova era di semplicità.
Ma nella pratica molte organizzazioni hanno scoperto una verità meno intuitiva: distribuire un sistema non lo rende più semplice. Lo rende diverso e, spesso, molto più difficile di prima.
La complessità non scompare. Si sposta. E quando si sposta, diventa più difficile da riconoscere.Dove prima esisteva un unico blocco difficile da modificare, oggi esistono centinaia di servizi che devono coordinarsi, comunicare, evolvere senza rompersi. Il problema non è più solo scrivere codice, ma orchestrare comportamenti. In questo scenario, l’architettura smette di essere una scelta tecnica e diventa una disciplina strategica.
Quando la distribuzione è il problema
Il monolite aveva un vantaggio spesso sottovalutato: la coerenza. Un’unica base di codice, un unico deployment, una visione centralizzata del sistema. Le architetture moderne, al contrario, introducono autonomia e indipendenza, ma al prezzo di una maggiore frammentazione.
Ogni microservizio è semplice. Il sistema che emerge dalla loro interazione non lo è.
Molte aziende adottano approcci cloud-native senza una reale necessità architetturale. Il risultato non è agilità, ma un aumento incontrollato della complessità: dipendenze implicite, contratti fragili, duplicazioni di logica.
In questi casi, il monolite non viene superato. Viene sostituito con un sistema distribuito che nessuno controlla davvero. La vera sfida, dunque, non è spezzare il monolite, ma capire quando ha davvero senso farlo.E se il monolite fosse ancora la scelta giusta?
In un contesto dominato da microservizi e cloud-native, mettere in discussione la distribuzione può sembrare controintuitivo. Eppure, per molte organizzazioni, il monolite non è un compromesso. È la scelta migliore.
Non tutte le complessità sono uguali. Molte vengono introdotte senza una reale necessità.
Un monolite ben progettato offre coerenza, semplicità operativa e una curva di apprendimento più accessibile. Riduce il numero di variabili in gioco, facilita il debugging e permette ai team di concentrarsi sul dominio, invece che sull’infrastruttura. Per molti business, è esattamente ciò che serve per crescere in modo sostenibile.
Il problema non è il monolite in sé, ma quando diventa “incontrollato”: rigido, opaco, difficile da evolvere. E lo stesso vale per i sistemi distribuiti. La differenza è che, in un’architettura distribuita, gli errori si moltiplicano più velocemente.
Non esiste nulla di moderno nel distribuire un sistema che non ha bisogno di essere distribuito.
La vera domanda non è quando abbandonare il monolite, ma quando farlo per le ragioni giuste.La complessità distribuita è il nuovo campo di battaglia
Quando la distribuzione è necessaria, emergono problemi diversi. Più sottili. Più difficili da diagnosticare.
In un’architettura distribuita, elementi un tempo marginali diventano centrali: la latenza di rete, la consistenza dei dati, la resilienza agli errori, la gestione degli stati. Concetti teorici come l’eventual consistency smettono di essere teoria e diventano compromessi operativi, con impatti diretti sul business.
Anche l’osservabilità cambia natura. Non basta più monitorare un’applicazione, ma bisogna ricostruire il comportamento di un sistema attraverso segnali parziali: log, metriche, trace. Capire cosa è successo diventa un esercizio di interpretazione, non di osservazione.
La complessità non è un bug, ma una proprietà del sistema. Le organizzazioni più evolute non cercano di eliminarla, ma di renderla visibile, comprensibile e gestibile.Platform engineering
Di fronte a questa complessità, improvvisare non è più un’opzione. È qui che emerge il platform engineering.
Si tratta della costruzione di una piattaforma interna che astrae la complessità infrastrutturale e offre ai team strumenti standardizzati per sviluppare, rilasciare e operare software.
Non è un ulteriore layer tecnologico. È una disciplina che riduce l’entropia.
Una piattaforma ben progettata non impone vincoli, ma definisce percorsi: standardizza ciò che deve essere coerente – deployment, sicurezza, osservabilità – e lascia autonomia dove servono innovazione e velocità.
In questo modello, gli sviluppatori non sono più soli di fronte alla complessità distribuita. Operano su fondamenta condivise, che riducono il carico cognitivo e permettono di concentrarsi sul valore applicativo.
La piattaforma diventa così un acceleratore invisibile: non limita la velocità, la rende sostenibile.La developer experience è la nuova leva strategica
Se la complessità è inevitabile, l’esperienza di chi la gestisce diventa centrale. La developer experience non è più un tema di comfort, ma di efficacia organizzativa.
Un sistema difficile da comprendere rallenta le decisioni, aumenta il rischio di errore e rende fragile ogni evoluzione. Al contrario, un’architettura che espone chiaramente responsabilità, flussi e dipendenze permette ai team di muoversi con sicurezza.
Documentazione, naming, coerenza degli standard, qualità delle API interne: elementi spesso considerati secondari diventano leve strategiche. Perché un’architettura non è solo ciò che fa il sistema, ma ciò che permette alle persone di capirlo.Responsabilità distribuita: “you build it, you run it”
Le architetture moderne portano con sé un cambiamento culturale profondo: chi sviluppa un servizio è anche responsabile del suo funzionamento in produzione.
Questo principio – noto come “you build it, you run it” – rompe la separazione tradizionale tra sviluppo e operation, ma introduce una nuova sfida: la responsabilità distribuita.
Ogni team diventa proprietario di una parte del sistema, ma nessuno ne controlla l’interezza.
Per evitare che questo modello degeneri in disallineamento, servono pratiche condivise, visibilità trasversale e una cultura della collaborazione che superi i confini dei singoli servizi.
La tecnologia abilita la distribuzione. La cultura la rende sostenibile.Il ruolo del CTO
In questo scenario, il ruolo del CTO evolve profondamente: scegliere le tecnologie, definire le roadmap e progettare il software non è più sufficiente. Serve una visione capace di tenere insieme autonomia e coerenza, velocità e controllo, senza perdere governabilità.
Il CTO diventa un architetto di sistemi complessi, organizzazioni ed ecosistemi operativi, in cui definire confini, responsabilità e interazioni.Dalla semplificazione alla consapevolezza
In definitiva, le architetture moderne non rappresentano una scorciatoia verso la semplicità, ma un passaggio verso una complessità più evoluta.
Le aziende che avranno successo non saranno quelle che adotteranno più microservizi o più cloud, ma quelle che sapranno sviluppare una consapevolezza profonda dei propri sistemi: come funzionano, come evolvono, dove possono rompersi.
Il futuro non appartiene a chi elimina la complessità, ma a chi decide quale complessità valga davvero la pena affrontare.