Su DevOps e Snowflake

Di questi tempi nell'IT non si riesce quasi a fare un passo senza sentire la gente parlare di DevOps. DevOps è il nuovo argomento di tendenza nel settore, che raccoglie il testimone da dove si era fermato il discorso sul cloud, e a sentire come ne parlano le persone si potrebbe credere che l'amministrazione di sistema tradizionale sia già morta e sepolta.

Per prima cosa dobbiamo parlare di cosa intendiamo con DevOps. Questo può creare confusione perché, come per il cloud, spesso si prende in prestito un termine più vecchio per indicare qualcosa di diverso o, nel migliore dei casi, collegato a qualcosa che già esisteva. Il DevOps tradizionale era la fusione dei ruoli di sviluppatore e operativo. Dagli anni '60 fino agli anni '90, questo era il modo standard di gestire i sistemi. In quel mondo le persone che scrivevano il software erano generalmente le stesse che lo distribuivano e lo mantenevano. Da qui la fusione di “developer” (sviluppatore) e “operations” (operativo), dove operations è un termine semi-standard per il ruolo di amministratore di sistema. Questi ruoli non furono comunemente separati fino all'ascesa del “reparto IT” negli anni '90 e 2000. Da allora, il ritorno alla fusione dei due ruoli ha ricominciato a guadagnare popolarità, principalmente per il modo in cui i due possono operare insieme con grande valore in molte situazioni moderne di applicazioni web ospitate.

Là dove oggi si parla spesso di DevOps non si intende una rigorosa fusione degli sviluppatori e del personale operativo, ma una modifica del personale operativo con un'attenzione molto maggiore alla scrittura di codice, non dell'applicazione stessa, ma alla definizione delle infrastrutture applicative come codice, come naturale estensione delle architetture cloud. All'inizio questo può creare parecchia confusione. Ciò che è importante notare è che il DevOps tradizionale non è ciò che comunemente avviene oggi, bensì un nuovo “finto” DevOps in cui gli sviluppatori restano sviluppatori e gli operativi restano operativi, ma il ruolo operativo si è evoluto in un nuovo ruolo “a forte componente di codice” che continua a concentrarsi sulla gestione di server che eseguono codice fornito dagli sviluppatori.

Ciò che è significativo oggi è che il ruolo dell'amministratore di sistema ha cominciato a divergere in due ruoli collegati, ma significativamente diversi, uno dei quali viene impropriamente chiamato DevOps dalla maggior parte del settore oggi (essendo gran parte del settore troppo giovane per ricordare quando il DevOps era la norma, non l'eccezione, e certamente non qualcosa di nuovo e originale). Mi riferisco a questi due aspetti del ruolo di amministratore di sistema, qui, come agli approcci DevOps e Snowflake.

Uso il termine Snowflake (fiocco di neve) per riferirmi alle architetture tradizionali dei sistemi perché ogni singolo server può essere visto come un “Snowflake unico”. Sono tutti diversi, perlomeno nella misura in cui non vengono gestiti in un qualche modo tale da mantenerli identici. Questo non significa che debbano essere tutti unici, solo che conservano la possibilità di esserlo. Negli ambienti tradizionali un amministratore di sistema accede a ciascun server individualmente per lavorarci. Una certa quantità di scripting è comune per agevolare le attività di amministrazione, ma alla base il ruolo comporta molto tempo speso a lavorare su singoli sistemi.

Agevolare l'amministrazione delle architetture Snowflake spesso comportava tentativi di minimizzare in modi ragionevoli le differenze tra i sistemi. Questo generalmente comincia con cose come la scelta di un unico sistema operativo e versione standard (Windows 2012 R2 o Red Hat Enterprise Linux 7) anziché permettere che ogni installazione di server sia un sistema operativo o una versione diversa. Questa standardizzazione può sembrare elementare, ma molte aziende ne sono prive ancora oggi.

Un passo successivo consiste comunemente nel creare una metodologia di deployment standard o un'immagine gold master che viene usata per realizzare tutti i sistemi, così che il sistema operativo di base e tutti i pacchetti di base, spesso comprese le personalizzazioni del sistema, i pacchetti di monitoraggio, i pacchetti di sicurezza, la configurazione dell'autenticazione e modifiche simili, siano standard e distribuiti in modo uniforme. Questo fornisce un punto di partenza comune per tutti i sistemi, così da minimizzare la divergenza. Ma tecnicamente garantiscono solo un punto di partenza standard e, nel tempo, la divergenza nella configurazione va prevista.

Oltre a questi passi, gli ambienti Snowflake usano tipicamente script di amministrazione personalizzati e su misura o strumenti di gestione per mantenere nel tempo una certa standardizzazione tra i sistemi. Maggiori sono i punti in comune tra i sistemi, più facili sono da mantenere e da risolvere in caso di problemi, e minore è la conoscenza necessaria al personale di amministrazione. Più standardizzazione significa meno sorprese, meno incognite e capacità di test molto migliori.

In un ambiente con un singolo amministratore di sistema, con buone pratiche e buoni strumenti, gli ambienti Snowflake possono raggiungere un alto grado di standardizzazione. Ma negli ambienti con molti amministratori di sistema, specialmente quelli supportati 24 ore su 24 da molte regioni, e con un gran numero di sistemi, la standardizzazione, anche con pratiche molto scrupolose, può diventare molto difficile. E questo ancora prima di affrontare gli ovvi problemi legati al fatto che su sistemi che svolgono ruoli diversi sono necessari pacchetti diversi e, possibilmente, versioni diverse dei pacchetti.

L'approccio DevOps cresce in modo organico a partire dal modello dell'architettura cloud. L'architettura cloud è progettata attorno a sistemi creati e distrutti automaticamente, ampiamente identici (perlomeno a gruppi), che vengono controllati attraverso un'interfaccia programmatica o API. Questo modello si presta, in modo abbastanza ovvio, a essere controllato centralmente attraverso un sistema di gestione anziché attraverso gli sforzi manuali di un amministratore di sistema. L'amministrazione manuale è di fatto impossibile e del tutto impraticabile con questo modello. I singoli sistemi non sono unici come nel modello Snowflake e qualsiasi divergenza creerà seri problemi.

L'idea che è emersa dal mondo dell'architettura cloud è quella secondo cui l'architettura dei sistemi dovrebbe essere definita centralmente “nel codice” anziché sui server stessi. All'inizio questo sembra confuso, ma ha molto senso quando lo esaminiamo più a fondo. Per supportare questo modello ha cominciato a emergere un nuovo tipo di strumento di gestione dei sistemi che non ha ancora assunto un nome davvero standard, ma che viene spesso chiamato strumento di automazione dei sistemi, framework DevOps, strumento di automazione IT o semplicemente strumento di “infrastructure as code”. Tra i toolset comuni in questo ambito figurano Puppet, Chef, CFEngine e SaltStack.

L'idea alla base di questi toolset di automazione è che un servizio centrale venga usato per gestire e controllare tutti i sistemi. Questa autorità centrale gestisce i singoli server tramite descrizioni basate su codice di come il sistema dovrebbe apparire e comportarsi. Nel mondo di Chef, queste vengono chiamate “recipes” (ricette) per essere simpatici, ma l'analogia funziona bene. Il codice di ciascun sistema potrebbe includere informazioni come un elenco di quali pacchetti e versioni di pacchetti dovrebbero essere installati, quali configurazioni di sistema dovrebbero essere modificate e quali file copiare sulla macchina. In molti casi le decisioni su questi deployment o modifiche vengono gestite attraverso una logica potenzialmente complessa e da qui la necessità di codice vero e proprio anziché di qualcosa di più semplicistico come markup o template. I sistemi vengono quindi raggruppati per ruolo e gestiti a gruppi. Il ruolo “web server” potrebbe indicare a un insieme di sistemi di installare Apache e PHP e di configurare la memoria in modo da fare swapping il meno possibile. Il ruolo “SQL Server” potrebbe installare MS SQL Server e speciali strumenti di backup usati solo per quell'applicazione e configurare la memoria in modo che sia ottimizzata come desiderato per un pool di macchine SQL Server. Questi sono solo esempi. Tipicamente un'organizzazione avrebbe moltissimi ruoli, alcuni dei quali potrebbero essere generici come “web server” e altri molto più specifici per supportare applicazioni molto particolari. I ruoli possono generalmente essere stratificati, così un sistema potrebbe essere sia un “web server” sia un “java server”, soddisfacendo le esigenze combinate di entrambi.

Queste definizioni standard fanno sì che i sistemi, una volta designati come appartenenti a un ruolo o a un altro, possano “costruirsi da soli” automaticamente. Un nuovo sistema potrebbe essere creato da un amministratore che richiede un sistema, oppure un sistema di monitoraggio della capacità potrebbe decidere che è necessaria capacità aggiuntiva per un ruolo e generare automaticamente nuove istanze di server senza alcun intervento umano di sorta. Nel momento in cui il sistema viene richiesto, da un essere umano o automaticamente, viene designato il ruolo e il sistema, tramite il framework di automazione, si trasformerà in un “nodo” completamente configurato e aggiornato. Non è richiesto alcun intervento umano di amministrazione di sistema. Il processo è rapido, semplice e, cosa più importante, completamente ripetibile.

Definire i sistemi nel codice ha alcune conseguenze non ovvie. Una è che i backup di sistemi completi non sono più necessari. Perché eseguire il backup di un sistema che puoi ricreare, con uno sforzo minimo, quasi istantaneamente? I dati locali dei sistemi di database dovrebbero essere sottoposti a backup, ma solo i dati del database, non l'intero sistema. Questo può ridurre notevolmente la pressione sulle infrastrutture di backup e rendere i processi di ripristino più veloci e più affidabili.

La quantità di documentazione necessaria per i sistemi già definiti nel codice è molto ridotta. Negli ambienti Snowflake l'amministratore di sistema deve mantenere una documentazione specifica per ogni host e mantenere quella documentazione manualmente. Questo richiede molto tempo ed è soggetto a errori. I sistemi definiti tramite codice centrale necessitano di poca o nessuna documentazione, e la documentazione può essere gestita a livello di gruppo, non a livello di singolo nodo.

Anche testare i sistemi definiti nel codice è facile da fare. Puoi creare un sistema tramite codice, testarlo e sapere che, quando sposti quella definizione in produzione, il sistema di produzione verrà creato in modo ripetibile esattamente come è stato creato in fase di test. Negli ambienti Snowflake è molto comune avere pratiche di test che tentano di fare questo, ma lo fanno attraverso sforzi manuali e sono soggette a essere approssimative e non esattamente ripetibili, e molto spesso la politica interna detterà che è più rapido simulare la ripetibilità che cercare davvero di ottenerla. I sistemi definiti tramite codice aggirano questi problemi, rendendo i test molto più preziosi.

Oltre alla necessità di definire un certo numero di nodi che devono esistere all'interno di ciascun ruolo, il sistema può riprovisionare un'intera architettura, da zero, automaticamente. Ricostruire dopo un disastro o avviare un sito secondario può essere fatto in modo molto rapido e semplice. Anche spostarsi tra sistemi ospitati localmente e sistemi ospitati in remoto, compresi quelli di aziende come Amazon, Microsoft, IBM, Rackspace e altre, è estremamente facile.

Naturalmente, nel mondo DevOps c'è un grande valore nell'usare le architetture cloud per consentire il livello più estremo di automazione, ma usare le architetture cloud non è necessario per sfruttare questo tipo di strumenti. E, naturalmente, avere un'architettura definita tramite codice potrebbe essere usato parzialmente, mentre l'amministrazione manuale potrebbe essere implementata anch'essa, per un approccio ibrido, ma questo è raramente raccomandato sui singoli sistemi. È generalmente molto meglio avere due ambienti, uno gestito come Snowflake e uno gestito come DevOps, quando i due approcci sono entrambi imposti. Questo costituisce un'ibridazione molto migliore. Ho visto questo funzionare estremamente bene in un ambiente enterprise con molte decine di migliaia di server “Snowflake”, ciascuno molto unico, ma con un ambiente dedicato di decine di migliaia di nodi gestito in modalità DevOps perché tutti i nodi dovevano essere identici e intercambiabili usando una di due possibili configurazioni. L'ibridazione si è rivelata molto efficace.

L'approccio DevOps, tuttavia, comporta anche notevoli avvertenze. Le competenze necessarie per gestire un sistema in questo modo sono di gran lunga maggiori di quelle necessarie per l'amministrazione di sistema tradizionale poiché, come minimo, è ancora necessaria tutta la conoscenza dell'amministrazione di sistema tradizionale, più una solida conoscenza di programmazione, tipicamente di linguaggi moderni come Python e Ruby, e anche la conoscenza degli specifici framework in questione. Questo requisito di base di conoscenze ampliato significa che i professionisti DevOps non solo sono rari, ma anche costosi. Significa inoltre che l'istruzione universitaria, già di gran lunga insufficiente a preparare al mondo professionale sia gli amministratori di sistema sia gli sviluppatori, è ora ancora più lontana dal preparare i laureati a lavorare secondo un modello DevOps.

Gli amministratori di sistema che lavorano in ciascuno di questi due campi hanno la tendenza a vedere tutti i sistemi come se dovessero rientrare nel proprio stampo. I nuovi professionisti DevOps spesso credono che i sistemi Snowflake siano legacy e necessitino di essere aggiornati. Gli amministratori Snowflake (tradizionali) tendono a vedere il movimento dell'“infrastructure as code” come sciocco, pieno di overhead inutile, eccessivamente complicato e molto di nicchia.

La realtà è che entrambi gli approcci hanno un enorme valore ed entrambi rimarranno estremamente validi. Entrambi hanno senso per carichi di lavoro molto diversi e le grandi organizzazioni, sospetto, vedranno comunemente entrambi in uso tramite una qualche forma di ibridazione. Nel mercato delle PMI, dove tipicamente c'è solo un numero esiguo di server, nessuna leva di scalabilità che giustifichi le architetture cloud e un'elevata disparità tra i sistemi, sospetto che il DevOps rimarrà quasi indefinitamente al di fuori della norma, poiché l'overhead e le competenze aggiuntive necessarie per farlo funzionare sono impraticabili o persino impossibili da acquisire. Le organizzazioni più grandi devono valutare i propri carichi di lavoro. Molti carichi di lavoro tradizionali e gran parte del software tradizionale non sono ben adatti all'approccio DevOps, specialmente all'automazione cloud, e richiederanno o un'ibridazione o un livello di scrittura di codice per ciascun sistema così alto da risultare impraticabile, rendendo impossibile giustificare il modello DevOps. Ma i carichi di lavoro costruiti su architetture web o che riescono a scalare orizzontalmente in modo estremamente efficace trarranno grandi benefici dal modello DevOps su larga scala. Questo potrebbe applicarsi alle grandi aziende enterprise o ad aziende più piccole che con ogni probabilità producono applicazioni ospitate destinate al consumo esterno.

Questa differenza di approccio significa che, negli Stati Uniti per esempio, gran parte degli USA è composta da aziende che rimarranno concentrate sul modello di gestione Snowflake, mentre alcune aziende della costa orientale potrebbero valutare efficacemente il modello DevOps e cominciare a muoversi in quella direzione. Ma sulla costa occidentale, dove le architetture più moderne e una concentrazione molto maggiore sulle applicazioni ospitate e sulle applicazioni destinate al consumo esterno sono i fattori economici trainanti, il DevOps sta già passando da novità a normalità matura e consolidata. Gli approcci DevOps e Snowflake rimarranno probabilmente fortemente segregati per regioni in questo modo, proprio come l'IT, in generale, vede competenze diverse migrare verso regioni diverse. Non sarebbe sorprendente vedere il DevOps cominciare a prendere piede in mercati come Austin, dove l'IT tradizionale ha avuto risultati piuttosto scarsi.

Nessuno dei due approcci è migliore o peggiore: sono due approcci diversi che servono due modi molto diversi di provisioning dei sistemi e due esigenze fondamentali diverse di quei sistemi. Con l'ascesa delle architetture cloud e del modello DevOps, tuttavia, è di importanza critica che gli amministratori di sistema esistenti comprendano cosa significhi il modello DevOps e quando si applichi, così da poter valutare correttamente i propri carichi di lavoro e le proprie esigenze uniche. Una larga porzione del mondo dell'amministrazione di sistema Snowflake tradizionale migrerà, nel tempo, verso il modello DevOps. Siamo ben lontani dal raggiungere uno stato stazionario nel settore per quanto riguarda l'equilibrio tra questi due modelli.

Pubblicato originariamente sul Blog di StorageCraft.