Il vero problema non è cambiare, ma farlo in modo incontrollato

L’importante è cambiare mantenendo il controllo. Riflessioni 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.

Conoscere esattamente lo stato dell’infrastruttura – dalla rete, alle capacità di calcolo, allo storage e ai sistemi – permette di introdurre dei cambiamenti senza causare problemi, perché non sussistono più aspetti nascosti in conflitto con la modifica da effettuarsi o capaci di interagire con essa in un modo devastante. Per fare un esempio, la situazione è simile a quella di un medico che prima di prescrivere un farmaco per una brutta influenza vuole sapere cosa il paziente sta già assumendo; ha bisogno di capire come le medicine interagiscono tra loro e quali effetti collaterali potrebbero causare.
Allo stesso modo, il medico dell’IT deve sapere cosa sta attualmente succedendo nell’architettura, in modo da capire cosa l’introduzione di una nuova variabile e un eventuale cambiamento potrebbe comportare. Solo così i cambiamenti si possono fare più rapidamente e più spesso, perché non si deve attendere un momento in particolare o un giorno predefinito in cui introdurli. Si può pensare di fare le modifiche una volta a settimana, ad esempio, come nel caso della metrica di frequenza dei rilasci associata a DevOps, in base a cui viene misurato il successo di molte startup che operano nel cloud.

La realtà è che essere maggiormente rapidi e intervenire spesso oggi sono aspetti sempre più rilevanti, in particolare se si considera la frequenza con cui le applicazioni mobile vengono aggiornate in azienda. Secondo un sondaggio sponsorizzato da Oracle, il 35 per cento delle organizzazioni aziendali di medie e grandi dimensioni aggiorna il proprio portfolio applicativo mensilmente, mentre un ulteriore 34 per cento lo fa su base trimestrale. L’82 per cento (più di 4 quinti) degli intervistati si aspetta questi cambiamenti saranno sempre più frequenti nei prossimi due anni.

In sintesi, credo che il cambiamento controllato tramite l’utilizzo dell’automazione, dell’orchestrazione e di un approccio centralizzato consenta di mantenere l’allineamento tra il concetto di infrastruttura immutabile e il suo stato reale, permettendo alle organizzazioni di superare la paura del cambiamento e abbracciarne le potenzialità.