Progettare a partire dai requisiti

Un architetto non sceglie un servizio perché è “moderno”, ma perché risponde a requisiti misurabili: pattern d’accesso (letture vs scritture, accesso per chiave vs query complesse), scala e crescita attesa, modello di consistenza, distribuzione geografica (regionale vs globale), RPO/RTO, vincoli di costo e di compliance. Il ragionamento è sempre un trade-off tra controllo, costo operativo e scala. La regola pratica: parti dal dato e dai suoi pattern d’accesso, poi scegli il compute che serve meglio quel carico. All’esame le domande descrivono uno scenario e nascondono la risposta dietro parole chiave come “globale”, “consistenza forte”, “serverless”, “petabyte” o “analisi”: il lavoro è mapparle sul prodotto corretto senza farsi distrarre dai distrattori plausibili.

Scegliere il compute

Compute Engine offre il massimo controllo: VM con accesso a livello OS, GPU, sole-tenant nodes per isolamento e compliance, BYOL per le licenze esistenti. È la scelta per lift-and-shift, workload legacy o requisiti di kernel/driver specifici. Per carichi prevedibili applica committed use discount; per l’elasticità usa Managed Instance Group con autoscaling.

GKE è Kubernetes gestito: adatto a microservizi containerizzati numerosi, portabilità, service mesh e controllo fine su networking e scaling. Scegli GKE quando hai già investito in Kubernetes o servono orchestrazione complessa e workload stateful. La modalità Autopilot riduce l’onere operativo gestendo i nodi al posto tuo.

Cloud Run esegue container stateless in modalità serverless con scale-to-zero e pagamento a consumo: ideale per API, servizi event-driven e traffico spiky o imprevedibile, con gestione minima. App Engine resta un PaaS per web app senza gestire container, ma per nuovi progetti serverless Cloud Run è di norma la scelta più flessibile.

Criterio sintetico: più controllo e responsabilità → Compute Engine; container con orchestrazione → GKE; container stateless con zero ops → Cloud Run.

Scegliere il database

Cloud SQL è relazionale gestito (PostgreSQL, MySQL, SQL Server), regionale, con HA tramite failover in un’altra zona e read replica anche cross-region. Va bene per OLTP tradizionale a scala moderata; scala verticalmente, quindi ha un tetto.

Cloud Spanner è relazionale distribuito globalmente con consistenza forte (external consistency basata su TrueTime) e scala orizzontale: la scelta quando servono SQL, scala globale e alto throughput di scrittura oltre i limiti di una singola istanza (es. ledger finanziari, inventario globale). Costa di più: non usarlo dove basta Cloud SQL.

Bigtable è NoSQL wide-column per throughput elevatissimo e bassa latenza su scala petabyte, con accesso per chiave: perfetto per time-series, IoT e telemetria; niente join né query SQL relazionali.

Firestore è NoSQL documentale, serverless, con sincronizzazione real-time e supporto offline: ottimo backend per app mobile e web con dati gerarchici.

BigQuery è il data warehouse serverless per analitica OLAP: SQL su petabyte, storage colonnare, per BI, reporting e ML sui dati. Non è un database transazionale: non usarlo per letture/scritture OLTP a bassa latenza.

Trappole tipiche d’esame

  • Relazionale “globale” con consistenza forte → Cloud Spanner: se lo scenario cita più regioni/continenti, scala orizzontale e transazioni forti, non è Cloud SQL (regionale, scala verticale).
  • Analitica su petabyte → BigQuery, non Bigtable: “query ad hoc / BI / data warehouse” indica OLAP; “throughput chiave-valore o time-series a bassa latenza” indica Bigtable.
  • Traffico spiky e stateless → Cloud Run, non GKE: se non servono orchestrazione complessa o stato, Cloud Run con scale-to-zero abbatte costo e ops; GKE qui è overkill.
  • Lift-and-shift o licenze/kernel specifici → Compute Engine: se serve accesso OS, GPU o BYOL, non forzare container o serverless.
  • App mobile con sync real-time → Firestore, non Cloud SQL: listener real-time e supporto offline sono nativi in Firestore, non in un RDBMS gestito.
  • Carico prevedibile 24/7 → committed use discount su Compute Engine/GKE: per costi stabili non affidarsi solo all’autoscaling on-demand a prezzo pieno.