Il problema con "tutti usano Kubernetes"
Kubernetes è stato adottato da Netflix, Google, Spotify. Kubernetes funziona in quei contesti perché hanno decine di team dedicati che lavorano sull'infrastruttura, migliaia di microservizi, traffico che varia di ordini di grandezza durante il giorno, e requisiti di deployment che devono essere completamente automatizzati.
Un'azienda con un team di 3 sviluppatori che deployano un'app con 5 container non è Netflix. Trattare l'infrastruttura come se lo fosse aggiunge complessità reale a problemi che non esistono ancora.
I costi nascosti di Kubernetes per team piccoli
Curva di apprendimento non banale
K8s introduce un vocabolario specifico (Pod, ReplicaSet, Deployment, Service, Ingress, ConfigMap, Secret, Namespace, RBAC, PersistentVolume) e un modello di rete e storage completamente diverso da Docker. Per un junior developer, si parla di 2-4 settimane per diventare operativo. Per chi viene da Docker Compose, la curva è più ripida di quanto appaia — le analogie esistono ma le differenze nei dettagli sono significative.
Overhead operativo continuo
Un cluster K8s (anche managed, come EKS o GKE) richiede manutenzione attiva: aggiornamenti periodici (Kubernetes rilascia versioni ogni 4 mesi con EOL rapido), gestione dei certificati, patching dei nodi, monitoring del cluster stesso, gestione del namespace e dei permessi RBAC. Su un team piccolo, questo overhead è solitamente sottostimato del 50% in fase di pianificazione.
Costo infrastrutturale più alto
Un cluster K8s in produzione tipicamente richiede almeno 3 nodi per alta disponibilità del control plane, più un node group per i workload. Il costo minimo su cloud managed è circa 150-400€/mese, contro i 20-60€ di un singolo VPS ben configurato.
Debugging più complesso
Quando qualcosa va storto, trovare il problema richiede familiarità con kubectl, log aggregati, namespace, e l'interazione tra componenti K8s. La superficie di debugging è significativamente più ampia che con Docker Compose.
Quando K8s ha senso anche per team piccoli
- Hai >10 servizi distinti con cicli di rilascio separati
- Il traffico varia di 10x nel corso della giornata
- Hai SLA contrattuale con downtime vicino a zero
- Il cliente/compliance richiede ambienti isolati per ogni tenant
- Il team crescerà e l'infrastruttura deve scalare con lui
- Hai già competenze K8s nel team
- Hai 2-7 container con deployment settimanale o meno
- Il traffico è prevedibile e stabile
- Nessuno nel team ha mai usato K8s in produzione
- Il budget infrastrutturale è limitato
- Il tempo di setup è imputato a un cliente con budget fisso
- L'app ha un singolo ambiente di produzione
Alternative concrete che funzionano in produzione
Docker Compose + Traefik su VPS
Un server dedicato (Hetzner, OVH, Contabo) con Docker Compose per orchestrare i container e Traefik come reverse proxy con TLS automatico via Let's Encrypt. Deployment via SSH o CI/CD con docker compose pull + up -d. Semplice da debuggare, economico, mantenibile da chiunque conosca Docker. Limite: nessun failover automatico se il server muore.
Kamal (ex MRSK)
Kamal è lo strumento che Basecamp ha rilasciato open-source per deployare applicazioni containerizzate su server bare metal via SSH. Zero overhead K8s, zero configurazione Compose: definisci il deployment in un YAML minimale, e Kamal gestisce pull, rolling deploy con zero-downtime, rollback. Ideale per stack Rails/Node/Python su VPS o server dedicati.
Managed container services
Cloud Run (GCP), App Runner (AWS), Render, Railway, Fly.io. Si fornisce l'immagine Docker, la piattaforma gestisce scaling, TLS, deploy. Zero overhead K8s, costo proporzionale all'uso. Limite: vendor lock-in sulla piattaforma di esecuzione.
Non "dovremmo usare Kubernetes?" ma "quali problemi specifici dobbiamo risolvere, e qual è lo strumento più semplice che li risolve?" Se la risposta è "deployare 4 container con blue-green deploy e TLS automatico", Docker Compose + Traefik risolve il problema in un pomeriggio. K8s per lo stesso scenario richiede giorni di setup e settimane di apprendimento.
Il percorso di migrazione sensato
Per team che iniziano piccoli e prevedono crescita, un percorso pratico:
- Fase 1: Docker Compose su VPS o managed service. Investi il tempo risparmiato sul prodotto.
- Fase 2: quando hai >5 servizi e il team cresce, introduce K8s managed (EKS/GKE) su un ambiente non critico per costruire le competenze.
- Fase 3: migra progressivamente i workload di produzione quando le competenze sono solide e il beneficio operativo giustifica il costo.
Il punto chiave: K8s è uno strumento eccellente per i problemi che risolve. Il rischio non è usarlo — è usarlo prima di averne bisogno, quando l'overhead supera il beneficio.