GCP-PCD · API management e messaging

Gestione delle API: Apigee, API Gateway, Cloud Endpoints

Google Cloud offre tre livelli di API management e la scelta dipende da scenario, costo e complessità.

Apigee è la piattaforma full-stack per l’API management enterprise: monetizzazione, developer portal, analytics avanzate, policy di trasformazione/mediation, rate limiting sofisticato, versioning e proxy verso backend eterogenei (anche on-prem o multi-cloud). È la risposta corretta quando lo scenario parla di programma API aziendale, partner esterni, quote a pagamento o governance centralizzata.

API Gateway è un gateway managed leggero e serverless, pensato per esporre backend serverless (Cloud Run, Cloud Functions) e servizi HTTP tramite una config OpenAPI. Gestisce autenticazione (API key, JWT, service account) e routing con costo e overhead ridotti. È la scelta quando serve un gateway semplice davanti a microservizi serverless, senza le funzionalità enterprise di Apigee.

Cloud Endpoints usa un proxy ESP/ESPv2 (basato su Envoy) affiancato al backend, tipicamente su GKE/Compute, e supporta anche gRPC. Adatto quando il proxy deve stare vicino al servizio e serve controllo su OpenAPI/gRPC senza il pricing di Apigee.

Messaging con Pub/Sub

Pub/Sub è il servizio di messaging asincrono per event fanout, disaccoppiamento produttore/consumatore e ingest ad alto throughput.

Push vs pull: in pull il subscriber estrae i messaggi e controlla il ritmo (ideale per throughput elevato e batching); in push Pub/Sub invia i messaggi a un endpoint HTTPS (ottimo per target serverless come Cloud Run che scalano sulle richieste). Il push richiede un endpoint pubblico o autenticato con token OIDC.
Dead-letter topic: dopo N tentativi falliti, il messaggio viene dirottato su un dead-letter topic per l’analisi, evitando loop infiniti di redelivery.
Ordering: l’ordinamento è garantito solo attivando le ordering key e pubblicando nella stessa regione; ha un costo in termini di throughput e va abilitato solo se il caso d’uso lo richiede davvero.
Pub/Sub garantisce at-least-once delivery: i consumer devono essere idempotenti perché sono possibili duplicati.

Cloud Tasks e Cloud Scheduler

Cloud Tasks gestisce l’esecuzione asincrona di singoli task HTTP con rate limiting, concurrency control, retry configurabili e scheduling/ritardo del singolo task. Serve quando devi proteggere un backend da picchi (dispatch controllato), disaccoppiare una richiesta lunga dalla risposta all’utente, o garantire consegna a un endpoint specifico. Differenza chiave con Pub/Sub: Cloud Tasks è task-oriented con controllo fine sul singolo destinatario e sulla velocità di dispatch; Pub/Sub è event fanout many-to-many senza rate limiting per subscriber.

Cloud Scheduler è il cron managed: invoca su schedule un endpoint HTTP, un topic Pub/Sub o un job. Perfetto per batch periodici, cleanup e trigger ricorrenti. Un pattern comune è Cloud Scheduler che pubblica su Pub/Sub o crea un Cloud Task, il quale poi invoca in modo controllato un servizio Cloud Run.

Client library, autenticazione e integrazione dati

Consuma le API Google con le client library ufficiali, che gestiscono retry, paginazione e Application Default Credentials (ADC). Su Google Cloud l’autenticazione avviene tramite l’identità della workload (Workload Identity su GKE, service account associata a Cloud Run/Functions): niente service account key su file. Per accedere a risorse cross-project usa l’impersonation. I secret (stringhe di connessione, chiavi di terze parti) vivono in Secret Manager, mai hardcoded nel codice o in env in chiaro.

Dall’applicazione integri Firestore (database documentale, per accessi chiave/documento e scala automatica, non join relazionali), Cloud SQL (relazionale, connessione via Cloud SQL connector/Auth Proxy con IAM), e Cloud Storage (oggetti; usa signed URL per dare accesso temporaneo a upload/download senza esporre le credenziali).

Trappole tipiche d’esame

Programma API con partner esterni, monetizzazione e developer portal → soluzione: Apigee. API Gateway e Endpoints non offrono monetizzazione né portale; scegliere loro qui è l’errore indotto.
Gateway semplice davanti a Cloud Run/Functions serverless → soluzione: API Gateway. Apigee sarebbe sovradimensionato e costoso per un semplice routing serverless.
Chiamare un backend HTTP a ritmo controllato con retry per non sovraccaricarlo → soluzione: Cloud Tasks, non Pub/Sub. Pub/Sub fa fanout di eventi ma non offre rate limiting per destinatario.
Garantire l’ordine dei messaggi → soluzione: ordering key con pubblicazione nella stessa regione; non basta usare Pub/Sub “normale”, che di default non ordina e consegna at-least-once (serve idempotenza).
Job schedulato ricorrente (cron) → soluzione: Cloud Scheduler, non Cloud Tasks. Tasks esegue singoli task on-demand; lo scheduling ricorrente è di Scheduler.
Accesso temporaneo a un file su Cloud Storage senza esporre credenziali → soluzione: signed URL, non rendere pubblico il bucket né distribuire service account key.
Autenticazione delle workload verso le API Google → soluzione: ADC con Workload Identity/service account associata e impersonation; le service account key scaricate sono l’anti-pattern che l’esame propone come distrattore.