Il punto di partenza
La gestione cloud nel 2026 assomiglia in superficie a quella di tre anni fa (gli stessi fornitori, le stesse primitive, lo stesso vocabolario). Sotto, la forma del carico di lavoro è cambiata abbastanza perché il playbook debba essere riscritto.
I carichi di inferenza, le spese di GPU, la normativa sulla residenza dei dati e le realtà operative dell'esecuzione di funzionalità di IA su scala di produzione hanno fatto passare il cloud da una conversazione di riduzione dei costi a una conversazione di capacità. Il team che lo vede solo come una fattura da ottimizzare non è più competitivo su ciò che l'applicazione può fare.
Questo articolo riguarda cosa è cambiato, l'aspetto dei nuovi default operativi e il modo in cui SDEN affronta i progetti cloud in questo nuovo ambiente.
La fattura è il sintomo, non la malattia
Gli sforamenti di costo cloud nel 2026 sono quasi sempre un problema di architettura, non un problema di sconto.
Uno schema di progetto familiare è il team finanza che fa risalire una fattura cloud raddoppiata in sei mesi. Il riflesso è negoziare più duramente con il fornitore o inseguire i colpevoli evidenti (istanze inattive, database sovradimensionati, snapshot che nessuno usa). Il riflesso cattura risparmi reali al primo passaggio e quasi niente al secondo.
Il vero motore dei costi nei deploy cloud del 2026 è di solito strutturale: uno schema di carico di lavoro che non corrisponde al modello di pricing delle risorse su cui gira. Inferenza di IA a raffica su istanze sempre attive. Query analitiche contro il database operativo. Egress di rete tra regioni che nessuno ha notato alla revisione di architettura. Log e tracce raccolti a piena fedeltà, conservati a tempo indefinito.
Correggere l'architettura produce risparmi di un ordine di grandezza. Negoziare il contratto ne produce di una sola cifra. L'ordine conta.
Dal provisioning alla capacità
L'ingegneria cloud comprende ancora il lavoro che ha sempre compreso: design di architettura, provisioning tramite infrastruttura-come-codice, automazione del deploy, observability e la disciplina operativa di gestire la produzione. È il pavimento.
Ciò che è nuovo è il livello sopra il pavimento. La pianificazione di capacità per carichi di inferenza dai profili di GPU a raffica e costosi. L'architettura multi-regione che rispetta la normativa sulla residenza dei dati in un mondo in cui le regole di UE, Stati Uniti e Svizzera divergono in modo notevole. Modelli ibridi in cui il carico operativo gira sul calcolo meno costoso disponibile e il servizio del modello gira dove la latenza e la licenza lo permettono. Nessuno di questi elementi era al cuore del lavoro dell'ingegnere cloud cinque anni fa. Tutti lo sono ora.
I progetti cloud di SDEN assomigliano sempre più a progetti di architettura (progettare la forma del deploy) anziché a progetti di provisioning. Il provisioning è automatizzato da anni; il design, no.
Default operativi per un carico plasmato dall'IA
I carichi di IA rompono alcune delle ipotesi su cui si appoggiano le architetture cloud classiche. Sono a raffica anziché stabili, costosi per chiamata anziché per byte, dipendenti da fornitori terzi di cui l'architetto cloud non controlla né la latenza né la disponibilità, e sensibili a dove i dati sono fisicamente collocati in un modo in cui il resto dell'applicazione non lo è.
I default operativi che funzionano per questa forma sono diversi. La cache, l'elaborazione in batch e il degrado garbato al livello applicativo diventano preoccupazioni di primo piano. L'astrazione del fornitore al livello del modello diventa obbligatoria, perché ogni trimestre il modello giusto è un modello diverso. E l'observability dei costi deve essere cablata nell'applicazione stessa, non solo nella fattura cloud, perché l'economia unitaria di una funzionalità di IA si decide per richiesta e deve essere visibile per richiesta.
Quando SDEN progetta un'architettura cloud per un prodotto che usa l'IA, è qui che va l'essenziale del lavoro: non nei manifesti Kubernetes, ma nel livello che decide cosa succede quando il modello prende troppo tempo, costa troppo o restituisce la cosa sbagliata.
Tre default su ogni progetto cloud
Non consegniamo cloud. Consegniamo architetture che si trovano a girare su un cloud. I pilastri qui sotto sono quelli a cui teniamo.
Infrastruttura-come-codice, end-to-end
Ogni pezzo dell'infrastruttura è descritto in codice, versionato, revisionato e riproducibile. Non facciamo produzione a clic. Non facciamo nemmeno staging a clic.
Observability dei costi a livello di funzionalità
Il costo è attribuito alle funzionalità e tracciato fino alle richieste che l'hanno provocato. Le sorprese nella fattura diventano eccezioni, non la norma.
Portabilità di regione e di fornitore dove conta
Scegliamo un cloud come base d'appoggio, ma l'architettura tiene aperte vie di uscita per i carichi che potrebbero averne bisogno, per ragioni di residenza dei dati, di cloud sovrano o di costo.
L'infrastruttura in cui il team ha fiducia per crescere
Il successo cloud è invisibile. Il team usa l'infrastruttura e smette di pensarci.
Un'architettura cloud che funziona permette al team di ingegneria di concentrarsi sul prodotto, non sull'idraulica. I deploy sono di routine. La fattura è prevedibile, e quando non lo è, il team può spiegare perché. La capacità è provisionata in anticipo sulla domanda e dismessa quando la domanda finisce. Si risponde alle autorità di regolamentazione con una documentazione che è stata generata, non assemblata a posteriori.
Quando SDEN conclude un progetto cloud, il test è semplice: il team di ingegneria gestisce il sistema senza di noi, comodamente, sei mesi dopo. Se ha bisogno di noi, non abbiamo fatto il lavoro.
La tecnologia sotto il cofano conta meno di questa proprietà. Può essere AWS, GCP, Azure o un ibrido; può essere Kubernetes, Nomad o serverless. Ciò che non può essere è una scatola nera che un solo ingegnere capisce.
Cloud
le domande che ci fanno più spesso.
Risposte dirette alle domande che ci vengono poste più spesso. Se la tua non c'è, scrivi al team.