Marco e la Sua Equazione Impossibile: Perché Abbiamo Costruito il Primo Conversational CloudOS
Da CMP a CloudOS: Il Salto Che Cambia Tutto
Alcuni giorni dopo il lancio di CloudsomeOS — e dopo aver letto l'annuncio — Marco mi richiama. Scettico.
"OK, ho letto il tuo annuncio. Il primo Conversational CloudOS.
Ma cosa cambia davvero rispetto a tutte le altre piattaforme che sto testando?"
"Sto provando varie soluzioni di 'vibe-coding' dove puoi distribuire direttamente dall'app. Cosa c'è di diverso? Perché un altro strumento? Non avevamo concordato che dovevamo semplificare?" Perché chiamarlo un CloudOS e non semplicemente un nuovo CMP con un po' di AI?"
Tutte domande legittime, che mi aspettavo. Perché sono le stesse che ci siamo posti. E in effetti, è proprio dalle stesse riflessioni di Marco che siamo partiti.
—-
Il punto di partenza: Cloudsome è nato (quasi) come un CMP
Prima di tutto: Cloudsome non è nato come un CloudOS. Inizialmente, il nostro lavoro assomigliava molto a quello di un "moderno" CMP.
Nel nostro backend, maturato nel tempo, abbiamo costruito:
tutte le primitive IaaS per creare, modificare e orchestrare risorse (VM, reti, volumi, sicurezza, ecc.);
tutte le primitive PaaS per distribuire servizi e applicazioni (build, deploy, routing, scaling);
un motore di automazione che unificava provisioning, networking, sicurezza, osservabilità, backup.
In pratica: un motore di automazione IaaS + PaaS unificato, progettato per rendere la complessità trasparente all'utente finale.
Era il "motore cloud" che oggi si trova sotto il "cofano" di CloudsomeOS. Nato su AWS in un ambiente gestito, è stato poi esteso per funzionare su qualsiasi istanza di hyperscaler, su OpenStack, e per gestire stack applicativi eterogenei in qualsiasi contesto. Il team di Cloudsome creava l'ambiente, l'infrastruttura di distribuzione e una semplice ricetta eseguibile di istruzioni, e con un semplice "push" potevi distribuire la tua applicazione dalla riga di comando o dal tuo repository Git.
A quel punto il ragionamento naturale era:
creare un front-end;
aggiungere dashboard e visualizzazioni di governance;
renderlo self-service;
impacchettarlo come una "piattaforma di gestione cloud evoluta".
In altre parole: un CMP con un backend particolarmente potente.
Ma mentre progettavamo, abbiamo preso una pausa. Una domanda ci ha fermato: "Stiamo davvero risolvendo il problema di Marco?"
—-
Cosa fanno (bene) i CMP, e dove si fermano
Torniamo alla domanda di Marco:
"Cosa cambia davvero rispetto a un CMP con un po' di AI sopra?"
L'onesta risposta è: i CMP fanno molto, ma si fermano a un certo livello.
i CMP "infrastruttura-first" sono eccellenti per: governance, politiche, costi, ruoli, compliance.
i CMP "deploy-first" migliorano il giorno 2 degli sviluppatori: CI/CD integrato, template, gestione degli ambienti, un po' di automazione guidata.
Ma entrambi partono dalla stessa assunzione: l'unità di lavoro è la risorsa, lo strumento, il flusso di lavoro.
Ti aiutano a gestire meglio i mezzi. Ma non si occupano del significato di ciò che stai cercando di ottenere.
Ti chiedono: "Dimmi come configurare" ma non: "Dimmi cosa vuoi ottenere"
—-
I limiti naturali del "vibe-coding"
Affrontiamo anche il secondo punto di Marco:
"Le soluzioni in-app che sto testando non sono male. Perché non è sufficiente?"
Perché il loro modello funziona finché:
la distribuzione è lineare;
il numero di servizi è limitato;
le integrazioni sono poche o nulle;
c'è solo un fornitore.
Non appena:
aggiungi più microservizi,
in lingue diverse (diciamo un frontend Node.js e un backend Python),
gestisci ambienti diversi (dev, staging, prod, demo),
devi collegarti a servizi esterni (DB, cache, code, sistemi di terze parti),
lavori in un vero multi-cloud o su OpenStack privato,
il linguaggio "deploy from app" non regge più. Non può rappresentare, né orchestrare, quella complessità.
Non è un difetto: è il loro scopo. Sono strumenti perfetti per casi circoscritti.
In altre parole, anche guardando le soluzioni più recenti e "developer-first", il problema non era lo strumento stesso, ma il fatto che tutto continuava a chiedere a Marco di pensare nei termini del sistema, invece dei suoi.
—-
La domanda che ci ha davvero fermato: abbiamo davvero bisogno di un altro pannello di controllo?
Mentre il backend si maturava, il panorama è cambiato rapidamente nell'ultimo anno:
i CMP "infra-first" sono rimasti centrali per governance e costi;
nuove piattaforme "developer-first" promettevano distribuzioni veloci e UX semplificata;
le soluzioni di "vibe-coding" con distribuzione in-app hanno iniziato a comparire;
esperienze "tutto-in-uno" come DigitalOcean hanno dimostrato che un cloud semplice è possibile — ma solo nel loro sandbox.
Guardando tutto questo, il rischio era chiaro: stavamo per costruire un altro strato di interfacce sopra gli strumenti, non un livello diverso di comprensione.
La domanda è cambiata:
"Se alla fine l'utente deve ancora pensare in termini di risorse, configurazioni e script, stiamo davvero semplificando o solo riorganizzando la complessità?"
È stato anche grazie all'accelerazione degli LLM che abbiamo iniziato a chiederci:
"E se il problema non fosse come mostri le cose, ma in quale linguaggio permetti loro di esprimerlo?"
E volevamo partire da un'ipotesi diversa: l'intento dovrebbe essere in grado di gestire sia casi semplici che complessi senza cambiare né forma né sostanza.
Da lì, il passo successivo non è stato "aggiungiamo una chat al pannello." È stato: cambiare il livello del linguaggio.
—-
Le quattro domande fondamentali (di Marco, e anche le nostre)
Ad un certo punto, il ragionamento si è ridotto a quattro semplici domande:
Perché devo ancora pensare come un sistema? Se ogni piattaforma mi chiede ancora di ragionare in termini di risorse, configurazioni, pipeline, sto solo spostando il problema a un livello superiore.
Perché devo scegliere tra semplicità e libertà? I modelli "tutto-in-uno" funzionano alla grande... purché accetti di rimanere legato a un singolo fornitore.
Perché i modelli app-centrico non scalano a architetture reali? Le soluzioni di "vibe-coding" o app-centrico funzionano bene per applicazioni semplici; non appena aggiungo servizi, ambienti, integrazioni, la magia scompare.
Perché il multi-cloud esiste solo sulla carta? La maggior parte delle piattaforme supporta più fornitori, ma non offrono semantiche comuni: ogni cloud rimane un mondo a sé.
Tra le quattro domande, una è particolarmente rivelatrice:
Perché devo scegliere tra semplicità e libertà?
Per fare un esempio pratico, DigitalOcean — come pochi altri modelli "tutto-in-uno" — ha dimostrato che un cloud semplice e coerente con un linguaggio unificato è possibile. Ma funziona solo all'interno del loro perimetro, con la loro infrastruttura, con le loro regole.
È un modello molto simile a iOS: perfettamente integrato, coerente, ma legato al proprio hardware. Funziona solo lì.
Un Conversational CloudOS, specialmente se vuoi davvero gestire il multi-cloud, dovrebbe invece somigliare di più a Android: uno strato che rende coerenti diversi ambienti, anche eterogenei, indipendentemente da chi li gestisce o dove vengono eseguiti.
Questa non è la vera risposta a tutte e quattro le domande, ma è il segnale aggiuntivo che ci ha fatto intuire la direzione giusta.
Il Conversational CloudOS è nato qui: come risposta a queste quattro domande, ancor prima di diventare un prodotto.
—-
Il momento Satori: separare l'intento dai mezzi
L'illuminazione è stata questa:
Il problema non è solo l'automazione. Il problema è il linguaggio che usiamo per attivarla.
Finché il linguaggio è:
"configurare",
"provisionare",
"configurare",
"scalare",
"collegare questa rete a quell'istanza",
Marco è costretto a pensare come il sistema.
Ciò che vuole realmente dire è:
"Rilascia la nuova versione dell'applicazione."
"Prepara uno staging identico a produzione per il team mobile."
"Aggiungi un Redis con le stesse impostazioni di quello esistente."
"Le prestazioni sono calate: raccogli e confronta i log dell'ultima versione."
Per anni, abbiamo tradotto manualmente questi intenti in pipeline, script, manifest, playbook. La domanda diventava:
Possiamo avere un sistema operativo cloud che faccia questa traduzione, invece che persone o un insieme di strumenti?
È qui che nasce l'idea di CloudOS, e il motivo di "Conversational".
—-
Guidato dall'intento nella pratica: dal dire al fare
La parte "conversazionale" di CloudsomeOS non è un gadget. È come entri nel sistema operativo.
La catena, semplificata, è questa:
Intento in linguaggio naturale Marco formula ciò che vuole, non la ricetta tecnica:
"Rilascia la nuova versione dell'app Python su OpenStack con autoscaling."
"Prepara uno staging identico a produzione per il team mobile."
"Aggiungi un Redis al deployment copiando la configurazione di redis-prod-01."
"Analizza il calo delle prestazioni confrontando i log dell'ultima versione."
Comprensione del contesto CloudsomeOS mappa semanticamente il modello infrastrutturale e connette:
modelli di applicazione (blueprint),
infrastrutture disponibili,
politiche,
dipendenze,
ambienti.
Traduzione deterministica Qui l'AI non "inventa":
compila la ricetta eseguibile (manifest),
genera piani di creazione delle risorse,
applica regole di rete,
definisce scaling e sicurezza,
allinea tutto con le politiche esistenti.
Orchestrazione su substrati L'intento è lo stesso, ma viene eseguito su:
OpenStack,
hyperscalers, gestiti e non gestiti, e nel prossimo futuro:
componenti IaaS di ambienti come VMware o Proxmox,
contesti edge.
Feedback e aggiustamenti Lo stato dell'infrastruttura viene riportato a Marco nella stessa lingua che ha usato per esprimere l'intento.
In questo senso, "conversazionale" non significa "bella chiacchierata." Significa: input in linguaggio naturale, output di architettura tecnica coerente.
—-
Multi-cloud come conseguenza, non come funzionalità
Quando il significato è separato dai mezzi, il multi-cloud smette di essere un elenco di loghi.
Se un intento è:
"Voglio che questa app Python gestisca i picchi di traffico del venerdì sera, utilizzando le risorse più efficienti in termini di costi e latenza."
CloudsomeOS può decidere di:
distribuirlo su OpenStack privato,
spostare parte di esso su un hyperscaler,
utilizzare zone o regioni diverse,
senza che Marco debba cambiare modo di formulare la richiesta.
Nuovi fornitori? Nuovi connettori. Stessa lingua.
Ricordi la metafora iOS vs. Android? Qui è dove il confronto con Android diventa naturale:
non è il cloud a dettare il linguaggio,
è il CloudOS che fornisce un linguaggio comune su diversi cloud.
——
Un (molto concreto) esempio
Torniamo a Marco.
PRIMA (pensiero CMP) Marco scriverebbe:
"Configura un deployment Python con 3 repliche, politica di rete per Redis, HPA basata su CPU > 70%, ServiceMonitor per Prometheus..."
DOPO (pensiero CloudOS): "Distribuisci la nuova app Python con autoscaling, collegala al Redis esistente"
CloudsomeOS: "Fatto. Distribuzione attiva su OpenStack prod-cluster-1, collegata a redis-prod-01, monitoraggio attivo."
Tutte le parti:
"quanti pod",
"quale rete",
"quale classe di storage",
"quale orchestratore",
"quale fornitore esatto",
non sono scomparse dal mondo. Sono semplicemente non più il modello mentale richiesto a Marco.
—-
Perché lo chiamiamo CloudOS
A questo punto, la risposta alla domanda iniziale di Marco è più semplice:
"Perché un CloudOS, e non un CMP con un po' di AI?"
Perché non stiamo:
aggiungendo una chat a una piattaforma,
né aggiungendo AI a un piano di controllo esistente,
né semplificando un singolo ambiente.
Stiamo introducendo:
un linguaggio di intento sopra l'infrastruttura;
un motore di traduzione deterministica intento → azione;
uno strato di astrazione multi-cloud che non dipende da un singolo fornitore;
un modo unificato di descrivere i risultati, non i mezzi.
In altre parole:
I CMP aiutano a governare il cloud. Un CloudOS cambia il nostro modo di pensare al cloud.
La parte conversazionale non è un capriccio: è la porta naturale per questo nuovo livello.
—-
Cosa rimane (e cosa scompare) per Marco
Cosa non scompare:
politiche,
architetture,
vincoli,
costi,
responsabilità.
Cosa scompare — progressivamente — è la necessità di:
pensare come un orchestratore;
parlare come un file di configurazione;
ricostruire mentalmente la mappa degli strumenti;
"tradurre" ogni richiesta aziendale in tre diversi strumenti.
——
CloudsomeOS non promette "zero complessità." Promette qualcosa di meglio:
La complessità non scompare. Semplicemente non pesa più sulle persone.
Marco può concentrarsi esclusivamente su ciò che conta davvero.
E tu?
Quando è stata l'ultima volta che la tua infrastruttura ha funzionato senza che tu ci pensassi?