I server non sono gattini

Quelle creature elettromeccaniche erano state accuratamente selezionate sul mercato, spesso assemblate con le proprie mani, battezzate con un nome riconoscibile e portate in datacenter perché iniziassero a erogare servizi.
I nomi venivano scelti – dopo grandi discussioni – assecondando una delle tanti passioni nerd del gruppo di sistemisti. Erano pianeti, divinità di lovecraftiana memoria, personaggi dei Simpson o di Star Trek. Oppure animali domestici. Ognuno di questi server aveva una specifica configurazione, ricercata e raffinata nel tempo, sulla quale si era magari sputato sangue e di cui si andava ovviamente fieri, una configurazione unica come unico era il sysadmin che la gestiva. Da Engine Yard:

I miei server prendevano i nomi dal libro di Douglas Hofstadter, “Gödel, Escher, Bach: un’Eterna Ghirlanda Brillante”. La Tartaruga era la mia istanza principale di httpd in Apache, Achille faceva funzionare Squid in modalità reverse proxy, il Granchio si occupava di MySQL e il Genio era il mio smart host SMTP. Ogni macchina aveva una frase del giorno personalizzata, con una decorazione ASCII colorata e una citazione dal libro.

Nel frattempo tutto è cambiato: già nel 2012 si stimava che Facebook avesse 180 mila server e che Google avesse abbondantemente superato il milione. È evidente i server non sono più coccolabili uno a uno e occorre un approccio più asettico e più industriale; semmai – per mantenere la similitudine – bisogna allevarli come le galline ovaiole o le mucche da latte. Per intenderci, non più homer.azienda.it ma database001.azienda.it.
A questo nuovo approccio si sono facilmente convertite le startup, che hanno subito colto quanto le infrastrutture in cloud consentissero di alleggerire i costi e diminuire il time to market di una nuova iniziativa e quanto i nuovi tool devOps per il configuration management permettessero di generare le configurazioni in modo programmatico distribuendole anche a migliaia di server contemporaneamente.
Il paradigma dell’infrastructure as a code ha reso la singola istanza di server facilmente rimpiazzabile togliendogli di fatto ogni “personalità”. Questo approccio alla gestione delle infrastrutture ha consentito ai software architect di ragionare su infrastrutture elastiche, in grado di autodimensionarsi in base alle richieste degli utenti e rimanere reattive anche in caso di guasto di una porzione dei server.
Se le piccole startup o i colossi del web hanno perfettamente introiettato il modello, tra le imprese tradizionali purtroppo si registra il ritardo maggiore; sembra che l’innovazione si sia fermata alla virtualizzazione e al templating dei server, partire da una configurazione di base per poi specializzarla di volta in volta tenendo traccia, quando va bene, delle modifiche apportate in qualche documento di testo. Può essere sostenibile quando si hanno poche decine di server, ma verso il migliaio di istanze di macchine virtuali diventa ingestibile ed è fonte di problemi di ogni sorta.

Innovazione dal sud(Africa)

In questo senso è interessante l’esperienza che Chef ha compiuto con Standard Bank [1][2][3] la più importante banca del Sudafrica – per dimensioni starebbe tra le top 5 in Italia – che sta cercando di capire come calare le pratiche devOps nella propria realtà. Ecco una prima efficace sintesi delle sue linee guida:

• Non essere un chop.
• Pensa alla velocità; fallo e basta.
• Effettua analisi postmortem senza puntare il dito.
• Pensa come una startup all’essenziale.
• Niente animaletti, solo bestiame.
• Fallisci svelto e fallisci per progredire.
• Applica fiducia e rispetto.
• Questa è una partnership.

Proprio in quel No pets, only cattle si può individuare il grosso balzo concettuale che deve essere effettuato. Il caso della Standard Bank è sicuramente incoraggiante e mostra come anche le realtà più complesse – quali le banche di grandi dimensioni, che hanno ovviamente molti vincoli normativi e tutte le necessarie cautele di sicurezza – possano iniziare un percorso di transizione verso un modo diverso di gestire l’operatività IT.

Come cambia il sistemista

L’ultima riflessione riguarda la figura del sistemista e il modo in cui sta cambiando in questi ultimi anni. L’ondata di rinnovamento culturale che il movimento devOps ha portato – con un ricco patrimonio di nuovi tool – è ancora appannaggio di troppo pochi. Sia il percorso formativo classico del sistemista – università e successive certificazioni dei vendor – sia l’editoria di settore – ovvero il canale più classico di approvvigionamento per chi vuole autoformarsi – ricalcano l’esperienza d’uso dei sistemi operativi degli anni Novanta.
Non c’è niente di intrinsecamente sbagliato nella grande guida a Ubuntu Linux o nella certificazione Linux Essentials, giusto per fare due esempi, visto che insegnano le basi; ma lo fanno in un modo non più efficace nel contesto attuale, un contesto fatto di macchine virtuali di server in cloud e non più di pet server. Qualcosa nei canali più classici fortunatamente si sta muovendo – Amazon ad esempio ha una certificazione per DevOps Engineer – ma se la materia vi interessa, le migliori opportunità sono le conferenze, e in particolare i DevOpsDays. Il prossimo è a Parigi in aprile: se fate i sistemisti, fossi in voi andrei a dare un’occhiata.