Molti di noi ci sono passati. Stai disegnando un nuovo sistema alla lavagna. Deve essere containerizzato, deve scalare e deve essere resiliente. La mano si avvicina al pennarello e disegna il familiare esagono: Kubernetes.
È lo standard del settore. È ciò che fanno i “grandi player”. Ma io credo che l’infrastruttura debba essere una risposta a un requisito, non un’impostazione predefinita.
Sono stato anch’io colpevole della mentalità “K8s-first”. Ma nel 2026, la “Tassa sulla Complessità” (Complexity Tax) di un cluster è più difficile da giustificare che mai.
Per cosa stai effettivamente pagando?
Quando scegli GKE (o qualsiasi altra variante K8s), non stai solo scegliendo un modo per eseguire container. Stai scegliendo di gestire:
- Node Pool: Dimensionarli, scalarli e preoccuparti del bin-packing.
- Control Plane: Gestire aggiornamenti e compatibilità di versione.
- Il labirinto dell’Ingress: Gestire SSL, load balancer e complessi manifest di rete.
Per un massiccio mesh di microservizi con complesse dipendenze inter-servizio, questo è un prezzo equo da pagare. Ma per una raccolta di API stateless o worker in background, è spesso eccessivo (“overkill”).
L’Evoluzione del Container “Serverless”
Il motivo per cui molti di noi in passato hanno evitato il “Serverless” era perché sembrava troppo restrittivo. Volevamo la potenza di una microVM, non le limitazioni di una “funzione”.
Tuttavia, Cloud Run si è evoluto in una potenza che colma questa lacuna. Non è più solo per le API “Hello World”. Con gli ambienti di esecuzione di seconda generazione, è diventato la scelta pragmatica per i carichi di lavoro pesanti.
Oltre l’API: Il Pool di Worker Serverless
Uno dei pattern meno utilizzati per Cloud Run è usarlo come pool di worker distribuiti.
Grazie alla sua profonda integrazione con Eventarc e Pub/Sub, puoi costruire un sistema che:
- Ascolta messaggi da Kafka, RabbitMQ o Pub/Sub.
- Scala da zero a mille istanze in pochi secondi.
- Elabora il job e scala immediatamente di nuovo a zero.
Ottieni la stessa potenza di elaborazione parallela di un consumer group GKE, ma con zero costi di inattività e zero gestione dei nodi.
Perché “Senior” significa “Semplice”
La mossa architettonica più “senior” non è scegliere lo strumento più potente; è scegliere lo strumento che ti permette di eliminare il maggior sovraccarico di gestione.
Se riesci ad adattare il tuo caso d’uso a un ambiente gestito come Cloud Run — sfruttando i sidecar per l’osservabilità e i mount persistenti per lo stato — liberi il tuo team per potersi concentrare sul codice Go, non sullo YAML.
Regola empirica: Se la tua infrastruttura richiede più tempo della tua logica di business, stai pagando una tassa troppo alta.