# Come Kubernetes cambia il modello di failure del tuo sistema # Come Kubernetes cambia il modello di failure del tuo sistema ![immagine-articolo](img.png) Kubernetes non è solo un orchestratore di container. È un cambio radicale nel modo in cui il tuo sistema fallisce. Molti team adottano Kubernetes pensando in termini di scalabilità, deploy e automazione. Ma il vero impatto — quello più profondo e spesso sottovalutato — è sul **failure model**. E se non aggiorni il tuo modo di pensare, Kubernetes non renderà il tuo sistema più robusto. Lo renderà semplicemente più complesso. --- ## Dal deterministico al probabilistico Prima di Kubernetes, la maggior parte dei sistemi era implicitamente **deterministica**: - server noti - failure localizzati - infrastruttura relativamente stabile Se un server cadeva, lo sapevi. Se un processo crashava, lo vedevi. Con Kubernetes, entri in un mondo **probabilistico**: - i pod sono effimeri - il scheduling è dinamico - i restart sono automatici - la topologia cambia continuamente Non puoi più chiederti: > “Il sistema fallirà?” Ma devi chiederti: > “Quando fallirà, e in che modo?” Il failure non è più un’eccezione. È una proprietà del sistema. --- ## Failure invisibili e falsa affidabilità Uno degli effetti più pericolosi di Kubernetes è che **nasconde i failure locali**. - un pod crasha → viene rimpiazzato - un nodo muore → i workload vengono rischedulati - un container fallisce → restart automatico Dal punto di vista superficiale, tutto sembra funzionare. Ma sotto: - errori transienti aumentano - retry silenziosi mascherano problemi - degradazioni lente passano inosservate Questo crea una **false sense of reliability**. > Kubernetes non elimina i failure. Li rende meno visibili. E quando emergono, spesso lo fanno in modo sistemico. --- ## Kubernetes non è resilienza Uno dei miti più diffusi: > “Se uso Kubernetes, il mio sistema è resiliente.” Non è vero. Kubernetes non rende il tuo sistema fault-tolerant. Espone i tuoi difetti architetturali. Esempi concreti: - servizi non idempotenti → problemi con retry automatici - dipendenze sincrone → cascading failure - database centralizzato → single point of failure invariato - timeout mal configurati → saturazione delle risorse > Kubernetes non è fault-tolerance. È fault-exposure. --- ## Il nuovo blast radius Prima: - un failure era spesso confinato a una macchina Dopo Kubernetes: - retry aggressivi - autoscaling - service mesh - load balancing dinamico possono trasformare un piccolo errore in un problema globale. Esempi tipici: - **retry storm** - **thundering herd** - saturazione di servizi downstream Il blast radius non è più fisico. È logico e distribuito. --- ## Osservabilità: da optional a requisito di sopravvivenza In un sistema Kubernetes: - i log non bastano - le metriche isolate non bastano - serve correlazione Diventa fondamentale: - distributed tracing - correlazione tra eventi - visibilità end-to-end Se non riesci a osservare il sistema, non lo stai realmente gestendo. > In Kubernetes, if you can’t observe it, you don’t own it. --- ## Cambia il tipo di competenze richieste Kubernetes non è solo un cambiamento tecnologico. È un cambiamento culturale. Gli sviluppatori devono capire: - retry - timeout - circuit breaker - idempotenza Gli Ops devono capire: - comportamento applicativo - pattern di comunicazione tra servizi Nasce un vero mindset di **Platform Engineering**. Non esiste più: > “non è un problema mio” Il sistema è una responsabilità condivisa. --- ## Il testing non è più sufficiente I test tradizionali non bastano più. Serve introdurre: - failure injection - chaos engineering - test in condizioni realistiche di rete e carico Perché molti problemi emergono solo: - sotto stress - in condizioni distribuite - nel tempo --- ## La dimensione temporale del failure Con Kubernetes, i problemi diventano: - transienti - intermittenti - difficili da riprodurre Un bug può: - apparire per pochi secondi - sparire dopo un restart - non manifestarsi mai in ambiente locale Il debugging cambia natura: > Non è più uno snapshot. È una timeline. --- ## Il costo cognitivo Kubernetes introduce un livello significativo di complessità: - più layer (container, pod, node, cluster) - più astrazioni - più punti di failure La root cause analysis diventa più difficile. > Kubernetes è un moltiplicatore di complessità, non solo di scalabilità. E questa complessità ha un costo: - onboarding più lento - debugging più difficile - maggiore dipendenza da tool di osservabilità --- ## Quando NON usare Kubernetes Kubernetes non è sempre la scelta giusta. Potrebbe non esserlo se: - il team è piccolo o inesperto - il sistema è semplice e monolitico - non hai reali esigenze di scalabilità distribuita - non hai maturità su osservabilità e resilienza > Se non hai già problemi distribuiti, Kubernetes potrebbe introdurli. --- ## Conclusione Kubernetes non rende il tuo sistema affidabile. Rende il tuo sistema **onestamente inaffidabile**. Ti costringe a: - affrontare il failure come parte del design - migliorare le tue pratiche ingegneristiche - crescere come organizzazione tecnica Ed è proprio questo il suo valore. > Kubernetes non risolve i problemi. > Ti obbliga a vederli davvero.