Compute Engine: le VM come base

Compute Engine fornisce virtual machine gestite. Crei un’istanza scegliendo il machine type (famiglie come e2, n2, c2 per bilanciare CPU/memoria o coprire carichi compute-intensive) e un’immagine (public image Google o custom image tua). Con gcloud compute instances create puoi passare uno startup script via metadata per installare software e configurare la VM al primo boot, evitando setup manuale. Per carichi fault-tolerant (batch, CI, rendering) le Spot VM costano molto meno delle istanze on-demand, ma Google può terminarle (preemption) in qualsiasi momento. Per il least privilege assegna ruoli predefiniti come roles/compute.instanceAdmin.v1, non i basic role roles/owner/roles/editor, troppo ampi.

Instance template, MIG e autoscaling

Per gestire molte VM identiche crei un instance template (immutabile) e da questo un managed instance group (MIG). Il MIG offre due capacità chiave: autoscaling, che aggiunge o rimuove istanze in base a metriche (CPU, carico del load balancer, metriche custom), e self-healing (autohealing), che ricrea un’istanza quando un health check applicativo la segnala non sana. Attenzione: senza health check il MIG ricrea solo le istanze crashate a livello VM, non quelle con l’app bloccata. Il MIG è anche il backend tipico dietro un load balancer e supporta rolling update e distribuzione regionale per l’alta disponibilità.

GKE: Autopilot vs Standard

Google Kubernetes Engine esegue container orchestrati da Kubernetes. In modalità Autopilot Google gestisce nodi, scaling e configurazione: paghi per le risorse richieste dai pod e non amministri le VM sottostanti — la scelta giusta quando non vuoi gestire l’infrastruttura. In modalità Standard gestisci tu i node pool (tipo di macchina, numero, upgrade), ottenendo massimo controllo ma più responsabilità operativa. In entrambe distribuisci i workload con kubectl (Deployment, Service) dopo aver ottenuto le credenziali del cluster. GKE è la scelta per applicazioni containerizzate complesse, multi-servizio o che richiedono portabilità Kubernetes.

Cloud Run e App Engine

Cloud Run è la via serverless per un singolo container: fai gcloud run deploy di un’immagine, il servizio scala automaticamente in base al traffico e scala a zero quando non ci sono richieste (paghi solo l’uso). Ideale per API e microservizi stateless request-driven, senza gestire cluster. Chi può invocare il servizio si controlla via IAM (roles/run.invoker).

App Engine è la PaaS storica. L’ambiente standard esegue codice in runtime supportati dentro una sandbox, scala rapidamente e fino a zero. L’ambiente flexible esegue container Docker su VM Compute Engine: accetta runtime e dipendenze custom ma non scala a zero (mantiene almeno un’istanza attiva). Per un nuovo container serverless oggi Cloud Run è di norma preferito; App Engine flexible resta utile per esigenze specifiche di runtime.

Come scegliere il servizio

Serve controllo completo dell’OS o un lift-and-shift → Compute Engine (con MIG quando serve scala e resilienza). Orchestrazione di container complessa o multi-servizio → GKE (Autopilot se non vuoi gestire i nodi). Un container stateless che deve scalare a zero → Cloud Run. Web app semplice con runtime supportato → App Engine standard.

Trappole tipiche d’esame

  • Workload batch fault-tolerant a costo minimo → Spot VM: costano molto meno ma possono essere terminate con preavviso; non usarle per servizi che devono restare sempre attivi.
  • Ricreare automaticamente una VM con l’app bloccata → MIG con autohealing + health check: l’autoscaling da solo non basta; il self-healing agisce solo se è configurato un health check applicativo.
  • Non voglio gestire i nodi Kubernetes → GKE Autopilot: Autopilot amministra nodi e scaling; se lo scenario chiede controllo sui node pool la risposta corretta è Standard.
  • Container serverless che scala a zero → Cloud Run, non App Engine flexible: flexible mantiene almeno un’istanza attiva; per lo zero-scaling di un container scegli Cloud Run.
  • Configurare molte VM in modo identico all’avvio → instance template + startup script: non configurarle a mano una per una; il template garantisce coerenza e alimenta il MIG.
  • Least privilege sulle istanze → ruolo predefinito, non basic role: assegna roles/compute.instanceAdmin.v1 invece di roles/editor, che concede permessi troppo ampi.