Google Cloud Platform per Sviluppatori: Guida Pillar Definitiva • Meteora Web Agency

Il tuo carico cresce, i server scoppiano, la fattura del cloud ti fa venire l'ansia. Oppure sei ancora indeciso su quale servizio Google Cloud usare e come farli lavorare insieme. In entrambi i casi, sei nel posto giusto.

Noi, di Meteora Web, lavoriamo con GCP su progetti reali dal nostro primo cliente in produzione nel 2018. Abbiamo costruito piattaforme che gestiscono centinaia di richieste al secondo su Cloud Run, analizzato dataset milionari con BigQuery e ottimizzato costi cloud per aziende che risparmiavano il 70% solo modificando qualche parametro. Non ti raccontiamo teoria: ti spieghiamo come usare GCP senza perderti, con esempi che puoi copiare e decisioni che devi prendere.

Da zero su GCP: account, IAM e prima applicazione

Prima di tutto: un account GCP, un progetto e una carta di credito. Google chiede la carta anche per il tier gratuito (300$ di credito per 90 giorni). Noi consigliamo di attivare subito un alert di fattura (budget alerts) per non svegliarti con un addebito a sorpresa.

IAM: chi fa cosa

Il primo errore che vediamo in progetti clienti: usare l'account owner per tutto. IAM ruoli minimi: dai a ogni utente o service account solo il permesso necessario. Per un deploy su Cloud Run, un service account con ruoli cloudrun.developer e storage.objectViewer basta.

Primo deploy: una web app su Cloud Run in 5 minuti

Crea un file Dockerfile per un'app Node.js o Python. Poi:

gcloud auth login
gcloud config set project [PROJECT_ID]
gcloud builds submit --tag gcr.io/[PROJECT_ID]/myapp
gcloud run deploy myapp --image gcr.io/[PROJECT_ID]/myapp --platform managed --region europe-west1 --allow-unauthenticated

Se non hai ancora un'app di esempio, parti da Cloud Run Quickstart. Nota: l'opzione --allow-unauthenticated è comodo per test, ma in produzione usa IAM o Cloud IAP.

Cloud Run: serverless container che scala

Cloud Run è il nostro servizio preferito per applicazioni web e API. Prezzo basato sulle richieste: paghi solo quando il codice viene eseguito. Se un servizio non riceve traffico, scala a zero istanze e non paghi nulla. Lo abbiamo usato per il backend di una piattaforma social per il turismo siciliano: gestiva picchi di traffico nei weekend e costava meno di 20€ al mese.

Configurazione intelligente

Parametri chiave:

min-instances: imposta a 0 per risparmiare. Solo se hai latenza critica (es. app real-time) usa 1-2.
max-instances: limita per evitare sorprese finanziarie in caso di attacco DDoS. Calcola il tetto massimo che puoi sostenere.
CPU always-on vs throttled: se la tua app fa background processing, usa cpu-boost.

Esempio di deploy ottimizzato:

gcloud run deploy my-service \
  --image gcr.io/[PROJECT_ID]/my-service \
  --region europe-west1 \
  --min-instances 0 \
  --max-instances 10 \
  --concurrency 80 \
  --cpu 1 \
  --memory 512Mi

Attenzione: Cloud Run non è ideale per job lunghi oltre i 60 minuti. Per quei casi usa Cloud Run Jobs o Batch.

Cloud Functions: serverless functions per eventi

Cloud Functions (1st gen e 2nd gen – consigliamo la 2nd gen basata su Cloud Run) è perfetto per microtask: elaborazione di immagini, webhook, integrazioni con Pub/Sub.

Python HTTP function

import functions_framework

@functions_framework.http
def hello_http(request):
    name = request.args.get("name", "Mondo")
    return f"Ciao {name}!"

Deploy con gcloud functions deploy function-name --runtime python312 --trigger-http --allow-unauthenticated.

Quando scegliere Functions vs Run: se la logica è semplice (una funzione, senza dipendenze complesse), usa Functions per rapidità. Se hai un'intera applicazione con routing e dipendenze, usa Cloud Run: più controllo, stesso costo base.

BigQuery: analytics senza limiti

BigQuery è il nostro tool per ogni progetto che genera dati: log eventi, metriche di vendita, analisi di traffico. Paghi per i dati scansionati, non per il tempo di esecuzione. Ottimizza le query con SELECT su colonne specifiche e uso di tabelle partizionate.

Esempio: analisi di un dataset di eventi ecommerce

SELECT
  DATE(event_date) as giorno,
  COUNT(DISTINCT user_id) as utenti_unici,
  SUM(event_value) as valore_totale
FROM `mydataset.events`
WHERE event_date >= DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY)
GROUP BY giorno
ORDER BY giorno

BigQuery si integra con Looker Studio per dashboard live. In un progetto per un brand di moda, abbiamo collegato i dati di fatturazione con quelli di Google Ads: report di ritorno sull'investimento in tempo reale.

Attenzione ai costi: usa partizionamento (per data) e clustering (per categorie) per ridurre le scansioni. Imposta quotas per evitare che una query sbagliata scansioni 10 TB e bruci il budget.

Google Cloud Storage: object storage per ogni esigenza

Cloud Storage è il cervello per file statici: immagini, backup, log, asset di siti. Noi lo usiamo come origine CDN per i siti dei nostri clienti: carichi le immagini su un bucket, attivi il Cloud CDN e il caricamento vola.

Classi di storage

Standard: per dati accessibili frequentemente.
Nearline: accessi meno di una volta al mese (es. backup settimanali).
Coldline: ogni 90 giorni (log storici).
Archive: oltre 365 giorni (dati di compliance).

Policy di ciclo di vita

Imposta regole per spostare automaticamente i file tra classi: dopo 30 giorni diventa Nearline, dopo 90 Coldline, dopo 365 cancella. Risparmierai fino all'80% sui costi di storage.

Firebase vs GCP: quando usare cosa

Firebase è un layer di prodotti gestiti sopra GCP. È perfetto per MVP, app mobile, siti statici. Ma se il tuo progetto cresce e hai bisogno di BigQuery, VPC, Cloud Run, machine learning personalizzato, devi abbracciare GCP nativo. La nostra regola: Firestore per dati semplici con sincronizzazione real-time, ma se hai relazioni complesse migra a Cloud SQL. Authentication di Firebase è comodo: puoi usarla anche su Cloud Run.

Vertex AI: Machine Learning su GCP

Vertex AI permette di addestrare e deployare modelli ML con AutoML o custom code. Noi abbiamo usato AutoML Tables per un cliente che doveva prevedere il tasso di abbandono dei clienti: in poche ore avevamo un modello esposto tramite endpoint, integrato in una dashboard.

Per modelli custom (es. PyTorch, TensorFlow), puoi usare Vertex AI Workbench o spedire job su GPU. Ricorda: l'AI amplifica, non sostituisce. Ogni output va verificato. Per approfondire il tema dell'affidabilità dei modelli, leggi il nostro articolo su "Incertezza Fedele" di Google Research.

Cloud SQL vs Cloud Spanner: database gestiti

Cloud SQL offre MySQL, PostgreSQL e SQL Server gestiti, con backup automatici, failover regionale. Per il 90% delle applicazioni web, Cloud SQL è la scelta giusta. Costo prevedibile: paghi per l'istanza. Cloud Spanner è un database relazionale distribuito globalmente con consistenza forte – serve solo se hai milioni di utenti in tutto il mondo e non puoi permetterti repliche in lettura. Il costo è molto più alto; valuta seriamente se ti serve davvero.

Networking su GCP: VPC, Load Balancer, Cloud CDN

Per applicazioni in produzione, devi progettare la rete: VPC con subnet, firewall rules, load balancer. Cloud CDN accelera la distribuzione dei contenuti statici: attivalo su un bucket di Cloud Storage o su un backend di Compute Engine.

Esempio: Load Balancer + Cloud Run

Usa un External HTTP(S) Load Balancer come front-end unico per più servizi Cloud Run, gestisci SSL e routing per dominio. Configura gcloud compute url-maps e target-http-proxies.

Costi GCP: come ottimizzare ed evitare sorprese

Qui entriamo nel vivo del nostro background economico. Un cliente aveva Cloud Run con min-instances=1 su due servizi: 24/7 acceso, mai sotto carico. Costo mensile: 90€. Passando a min=0 e usando Cloud Scheduler per risvegliare il servizio prima di picchi previsti (es. ogni ora), è sceso a 18€. Risparmio del 80%.

Consigli pratici

Attiva billing alerts a 50%, 80% e 100% del budget.
Esporta i costi su BigQuery e analizza con Looker Studio.
Usa Committed Use Discounts se hai carichi prevedibili (VM o Cloud SQL per 1-3 anni, risparmi fino al 57%).
Imposta resource hierarchy (folder per progetto) per allocare i costi per reparto.
Sposta gli oggetti di storage su classi inferiori con lifecycle policies.

Con queste pratiche, i nostri clienti risparmiano in media il 30-50% sul conto GCP.

In sintesi – cosa fare adesso

Crea un account GCP e attiva un budget alert. Non superare i 300$ del tier gratuito senza sapere cosa stai facendo.
Deploya una app su Cloud Run con min-instances=0. Impara a monitare costi e latenza.
Importa un dataset in BigQuery (usa un file CSV dal tuo progetto reale) e scrivi una query aggregata. Collega a Looker Studio.
Rivedi la configurazione del tuo progetto attuale: sei ancora su un server sempre acceso? Quanto potresti risparmiare passando a serverless?
Leggi la documentazione ufficiale di Cloud Run e BigQuery – sono chiare e aggiornate.

Se hai domande o vuoi che ti aiutiamo a ottimizzare la tua infrastruttura GCP, contattaci. Noi di Meteora Web lavoriamo con le aziende per far sì che il cloud sia un investimento, non un costo nascosto.