Lo dico senza girarci intorno: la maggior parte delle startup che conosco non aveva bisogno di Kubernetes il giorno in cui l'hanno adottato. L'hanno fatto perché "è lo standard", perché in un talk lo usavano tutti, perché su LinkedIn sembra che chi non ha un cluster sia rimasto indietro. E ci hanno messo mesi a scoprire che avevano comprato un problema molto più grande di quello che stavano risolvendo.
Non è una provocazione da titolo acchiappa-click. È quello che vedo, progetto dopo progetto, quando entro in un cliente per "un problema veloce" e mi ritrovo tre giorni dentro YAML, RBAC e networking overlay per un'applicazione che gira comodamente su una singola VM da 8GB.
Quando adotti Kubernetes non stai solo scegliendo un orchestratore. Ti stai iscrivendo a un intero corso di specializzazione che non finisce mai: networking a livello di cluster, DNS interno, service mesh (o la sua assenza, che è un problema altrettanto grande), RBAC, gestione dei secret, autoscaling che va tarato e non semplicemente attivato, e un sistema di IAM che deve federarsi con tutto il resto.
Ho passato ore — letteralmente ore — a diagnosticare un timeout TCP pod-to-pod che in un ambiente non containerizzato non sarebbe mai esistito. Il problema non era nell'applicazione, non era nel database, non era nel codice che avevamo scritto: era nel modo in cui due pod nello stesso namespace si parlavano attraverso il CNI. Un cliente con tre sviluppatori e un prodotto in fase di validazione non ha il tempo, e spesso nemmeno le competenze interne, per gestire questa classe di problemi mentre dovrebbe concentrarsi su una cosa sola: capire se il prodotto ha un mercato.
Prendi un caso che ho vissuto più volte: Keycloak come identity provider centralizzato, con federazione LDAP/Active Directory, dietro un API Gateway come Kong per la validazione JWT. Architetturalmente è pulito, è quello che consiglierei a un'azienda strutturata con più servizi e team diversi che devono condividere un sistema di autenticazione.
Ma quando qualcosa si rompe — un pool di connessioni HikariCP mal dimensionato su Postgres, un VIP con un idle timeout troppo aggressivo che droppa le connessioni di Keycloak al database, un header X-Forwarded-Proto che Kong non passa correttamente e manda in loop l'admin console tra HTTP e HTTPS — il debug richiede di conoscere contemporaneamente Kubernetes, Keycloak, Kong, il comportamento di un load balancer e le specifiche RFC dei protocolli coinvolti. Per una startup con un prodotto, non un dipartimento infrastrutturale, questo è un costo nascosto enorme: ogni ora spesa lì è un'ora non spesa a parlare con i clienti.
Non sto dicendo che Kubernetes sia sbagliato in assoluto — sarebbe un'affermazione tanto pigra quanto quella che critico. Ha senso quando:
Se ti riconosci in questi punti, è uno strumento eccellente — ci lavoro ogni giorno e non lo sto sconsigliando in generale. Il punto è un altro: la domanda giusta non è "Kubernetes o non Kubernetes", è "questo problema esiste già, o lo sto importando in anticipo perché ho paura di non sembrare abbastanza serio?"
Un monolite Spring Boot ben strutturato, containerizzato con Docker Compose, dietro un reverse proxy con TLS, su una singola VM (o due, per l'alta disponibilità minima) regge tranquillamente il traffico della stragrande maggioranza delle startup nei primi 1-2 anni di vita. Quando l'app inizierà davvero a scalare oltre quello che una VM ben dimensionata regge, saprai esattamente dove tagliare i confini dei servizi — perché li avrai visti emergere dall'uso reale, non disegnati a tavolino prima di avere un solo utente pagante.
Lo dico da chi passa gran parte delle sue giornate dentro cluster GKE a risolvere esattamente i problemi che ho descritto sopra: la competenza per gestire Kubernetes bene è preziosa, ma va spesa quando il problema che risolve è già arrivato — non come rito di passaggio per sentirsi un'azienda "vera".
E voi? Avete adottato Kubernetes dal giorno zero o ci siete arrivati quando il dolore di non averlo era diventato più grande del dolore di impararlo? Sono curioso di leggere le vostre esperienze, soprattutto quelle in cui la scelta si è rivelata sbagliata in entrambe le direzioni.
Sviluppatore dalla nascita, oggi mi occupo di architetture Front-end e Back-end in ambito enterprise. Credo fermamente che la tecnologia debba essere condivisa: per questo ho aperto questo blog, dove riverso tutto ciò che imparo tra una riga di codice e l'altra. Quando non sono davanti a un terminale, mi trovi su un palco teatrale o su un campo sportivo. Qui condivido la mia visione sulla programmazione e la sicurezza informatica, cercando di rendere semplice ciò che è complesso. [..]
