I modelli di servizio: IaaS, PaaS, SaaS
Nel cloud la responsabilità è condivisa fra te e il provider, e i tre modelli di servizio descrivono dove passa il confine. Con IaaS (Infrastructure as a Service) affitti risorse virtualizzate — macchine, storage, rete — e resti responsabile di sistema operativo, runtime e applicazione: massima flessibilità, massimo carico operativo. Con PaaS (Platform as a Service) il provider gestisce anche sistema operativo e runtime, e tu ti concentri solo su codice e dati: meno controllo, molto meno overhead. Con SaaS (Software as a Service) consumi un’applicazione già pronta (per esempio Google Workspace) senza gestire nulla dell’infrastruttura sottostante.
Per l’esame il ragionamento chiave è di business: più ci si sposta da IaaS verso SaaS, più si riducono time-to-market e costo operativo, ma diminuisce anche il controllo sulla configurazione. Non esiste un modello “migliore”: esiste quello adatto al livello di controllo che il caso d’uso richiede.
Lo spettro del compute su Google Cloud
Google Cloud offre una gamma di opzioni di compute che va dal controllo massimo al pieno serverless.
Compute Engine fornisce macchine virtuali (IaaS): scegli CPU, memoria e sistema operativo mantenendo il controllo completo. È la scelta per il lift-and-shift di applicazioni legacy, per carichi che richiedono un kernel specifico o GPU, o quando serve replicare fedelmente un ambiente esistente.
Google Kubernetes Engine (GKE) è Kubernetes gestito: orchestra container su larga scala. È indicato per architetture a microservizi complesse, quando serve portabilità fra ambienti (hybrid o multi-cloud) e controllo fine su networking e scaling dei container.
Cloud Run esegue container in modalità serverless: scala automaticamente, anche fino a zero istanze quando non c’è traffico, e paghi solo per l’uso effettivo. Dà la portabilità dei container senza l’onere di gestire un cluster; ideale per servizi web e API stateless con traffico variabile o intermittente.
App Engine è la piattaforma PaaS: distribuisci il codice e Google gestisce l’infrastruttura sottostante, con scaling automatico. Adatto a web app e API quando vuoi minimizzare l’overhead operativo senza necessariamente containerizzare.
Cloud Functions esegue singole funzioni event-driven (FaaS): un frammento di codice reagisce a un evento — un file caricato su Cloud Storage, un messaggio su Pub/Sub, una chiamata HTTP. È il “collante” leggero fra servizi, non pensato per applicazioni monolitiche.
Come scegliere: controllo, overhead, portabilità, traffico
I criteri decisionali dell’esame sono ricorrenti. Il primo è controllo contro overhead operativo: Compute Engine massimizza il controllo, il serverless (Cloud Run, Cloud Functions) minimizza la gestione. Il secondo è la portabilità: se il carico è containerizzato, GKE e Cloud Run lo rendono portabile fra ambienti. Il terzo è il pattern di traffico: traffico intermittente o imprevedibile premia le opzioni che scalano a zero (Cloud Run, Cloud Functions), mentre carichi costanti e prevedibili si prestano bene a istanze gestite.
Il compute non vive da solo: per gli oggetti — immagini, backup, file statici, dati non strutturati — la scelta è Cloud Storage, storage a oggetti scalabile e durevole, non un’opzione di compute. Distinguere “dove gira il codice” da “dove risiedono i dati” è essenziale per non cadere nei distrattori.
Trappole tipiche d’esame
- Kernel custom, GPU o lift-and-shift di VM esistenti → Compute Engine: quando il requisito è il controllo completo dell’ambiente, la risposta è la VM, non un servizio gestito.
- Basta eseguire un container senza gestire un cluster → Cloud Run: se la domanda cita Kubernetes o orchestrazione complessa la risposta è GKE, ma “solo un container serverless” indica Cloud Run.
- Scala a zero, paga-per-uso, traffico intermittente → Cloud Run (o Cloud Functions): la parola chiave “scala a zero” esclude Compute Engine e GKE standard.
- Codice event-driven che reagisce a un singolo evento → Cloud Functions: l’upload di un file o un messaggio Pub/Sub sono segnali di FaaS, non di App Engine.
- Minimo overhead per una web app senza containerizzare → App Engine: PaaS quando vuoi distribuire codice, non gestire infrastruttura né immagini container.
- Archiviare file o oggetti → Cloud Storage, non un compute: un distrattore frequente propone una VM per “salvare i file”; gli oggetti vanno su Cloud Storage.