[section_title title=Parte uno]
A cura di Paolo Arcagni, Systems Engineer Manager Italy&Malta di F5 Networks
Distribuite un’applicazione: dopo tre giorni, senza che nulla venga cambiato, all’improvviso si blocca. La causa? Un memory leak.
Distribuite un’applicazione: passano tre settimane senza che nulla venga cambiato ma, improvvisamente, smette di funzionare. Il motivo? Una query del database torna indietro vuota e l’applicazione web impazzisce cercando di manipolare un valore nullo e decidendo infine di fermarsi.
Altra ipotesi, distribuite un servizio di bilanciamento del carico: dopo tre mesi, senza che nulla venga cambiato, improvvisamente il bilanciamento del carico dell’applicazione si interrompe. Perché? Una delle porte su uno switch intermedio è saltata dando letteralmente vita a un buco nero e il bilanciamento del carico non riesce più a trovare le applicazioni.
Esistono probabilmente altri cento e più esempi di questo tipo che potremmo citare per dimostrare che non effettuare dei cambiamenti non garantisce che le cose continueranno a funzionare come prima. Capita che l’hardware, che in ultima analisi sostiene tutte le risorse principali necessarie a eseguire e distribuire le applicazioni, a volte non funzioni, un bug nelle applicazioni appaia solo dopo un uso continuativo, quando ci sono carichi di lavoro intensi o quando l’utente immette una combinazione che non è stata testata in precedenza.
Il fatto di non avere effettuato cambiamenti non è un indicatore del successo nel tempo. Eppure, ancora oggi, sembra essere il modus operandi più diffuso nelle organizzazioni che sostengono: “meno cambiamo, meglio è!”
Le modifiche vengono autorizzate solo dopo lunghe discussioni e revisioni, e infine programmate di nascosto durante il weekend quando si spera che nessuno vi presti attenzione. Il motivo? Perché il cambiamento rappresenta il male assoluto!
Credo però esista una via di mezzo tra una modalità operativa di controllo estremo e il caos, con una conseguente entropia introdotta proprio dal cambiamento e dal desiderio del business di potersi trasformare più rapidamente, mutando con maggiore frequenza. Infatti, il vero problema non è cambiare, ma farlo in modo incontrollato.
Le difficoltà nascono con le modifiche e le patch di mezzanotte che non vengono documentate, l’aggiunta manuale di un route o la cancellazione di un ACL che non viene tracciata.
Il cambiamento non documentato e senza controllo è quello che mina l’equilibrio dell’intero sistema, creando una spirale negativa di problemi. Il reale problema è la piena comprensione dello stato dell’infrastruttura di erogazione delle applicazioni, ed il mantenerla in uno stato tracciabile e consistente: questo è possibile con un disaccoppiamento dell’infrastruttura (“data plane”) dal suo stato conosciuto (control plane).
Chiamatelo SDN, DevOps, automazione e orchestrazione, infrastruttura immutabile. Comunque preferiate definire tutto questo, l’obiettivo è lo stesso: una migliore operatività, che non significa solo migliorare il time to market, anche se questo è un vantaggio decisivo che si sposa perfettamente con le priorità di business. Si tratta anche di introdurre nell’ambiente una maggiore stabilità, che può essere raggiunta solo con la conoscenza dello stato di tutta l’infrastruttura in ogni momento specifico e con la capacità di cambiare in modo sicuro.
Per proseguire la lettura vai alla pagina seguente.
