DevOps è un termine coniato circa sette anni fa da Patrick Debois, attualmente un IT consultant indipendente, e consacrato da una serie di convention a tema, i “DevOps Days”. Ma che cosa significa esattamente DevOps e quali sono le ragioni che hanno portato alla sua diffusione nel mondo dell’IT? Cercheremo di spiegarlo nel post odierno.
DevOps è un neologismo nato dalla fusione delle parole development ed operations, ciascuna delle quali si riferisce a specifici e cruciali ambiti dell’ecosistema IT: gli sviluppatori ed il personale (amministratori di sistema o sysadmin) incaricato di garantire l’affidabilità e l’uptime dell’infrastruttura . La filosofia DevOps può essere presentata in sintesi come la risposta agli inadeguati modelli organizzativi che il settore si trascinava ormai da decenni e che impedivano a developer e system administrator di collaborare tra loro con efficacia. Per spiegare meglio quanto sia complesso il rapporto tra gli uni e gli altri riprendiamo un post di James Turnbull.
Lo scenario “tipo”
La situazione più frequente, scrive Turnbull, è la seguente: uno sviluppatore conclude il proprio lavoro su un’applicazione dalle immense potenzialità e caratterizzata da funzionalità inedite. L’applicazione deve essere naturalmente implementata nel sistema, compito che spetta al team operations. Il deploy di un’applicazione è un evento “delicato” per l’admin che è solito sollevare una o più delle seguenti questioni:
- l’applicazione non può funzionare perchè è troppo vecchia, non ha i requisiti adatti, l’infrastruttura non supporta quella determinata versione;
- l’architettura dell’applicazione non è compatibile con gli standard infrastrutturali (storage, network, sicurezza etc.);
- l’applicazione non può essere mandata in produzione perchè il team operation non è stato consultato per tempo su cruciali questioni (provisioning, sicurezza, backup etc.).
Nonostante tutto, prosegue Turnbull, l’admin procede al deploy “forzato” apportando alcune modifiche all’infrastruttura in modo da mandare in produzione il tutto. Questa pratica può tuttavia rivelarsi controproducente per l’applicazione che non funzionerà come originariamente pensato dal developer. A questo punto l’admin, dopo aver riscontrato alcune problematiche, invia una segnalazione al team di sviluppatori che risponde prontamente:
- che le problematiche derivano da una errata implementazione dell’applicazione – il cui codice è impeccabile;
- che sui computer degli sviluppatori l’applicazione funzionava perfettamente (rimandando al primo punto)
Si crea così una situazione di stallo dove un team addossa all’altro la responsabilità del “fallimento”. L’approccio DevOps, come vedremo nel paragrafo successivo, ha esattamente l’obiettivo di scongiurare questo scenario.
DevOps e linee guida
DevOps è un insieme di idee e princìpi, aggiunge Turnbull, per incentivare la cooperazione fra team e migliorarne la capacità di apprendimento e coordinamento. In un ambiente DevOps, admin e sviluppatori creano relazioni, processi e strumenti che migliorano le interazioni ed il servizio al cliente. L’approccio DevOps è inoltre applicabile ad altre aree di lavoro, non solo al deploy del software: dal provisioning al networking fino all’automazione ed al monitoraggio è possibile migliorare la qualità delle interazioni fra i team. Per Turnbull le linee guida di un ambiente DevOps sono le seguenti:
- semplicità. Consente di migliorare la rapidità delle comunicazioni ed evitare fraintendimenti, aiuta a ridurre eventuali errori di progettazione ed implementazione, permette di risparmiare tempo prezioso da dedicare ad altre task. Le soluzioni a determinate problematiche devono essere semplici, riutilizzabili e ripetibili;
- relazioni umane. Il confronto e l’interazione tra i team deve essere costante. Gli sviluppatori devono coinvolgere gli admin nel processo generale di progettazione dell’applicazione invitandoli ai meeting, condividendo idee ed eventuali modifiche, istruendoli sull’architettura dell’applicazione ed il codice alla base di quest’ultima. L’avanzamento dei lavori deve esser sempre accompagnato da test di deploy, backup, sicurezza, monitoraggio e funzionalità in modo da individuare il maggior numero di bug, anche grazie al supporto degli admin.
Gli admin devono a loro volta coinvolgere gli sviluppatori condividendo eventuali piani di aggiornamento dell’infrastruttura, in modo da rendere più facile l’implementazione di future applicazioni. Gli admin possono imparare molto dagli sviluppatori e rendere l’ambiente di lavoro più facile da gestire ed efficiente. Imparare le basi della programmazione o perfezionarle è un’altra buona idea, aggiunge Turnbull;
- automazione e processi. L’automazione è ottenibile con la realizzazione o l’impiego di strumenti semplici ed espandibili. Soluzioni come Puppet, che permettono di configurare i vari elementi di un’infrastruttura e le modalità di interazione fra di essi, sono ideali. L’automazione ed i medesimi strumenti devono essere utilizzati anche dal team di sviluppatori in modo che, mano mano che nuove linee di codice entrano in produzione, si possano testare contemporaneamente il deploy, la gestione e le nuove funzionalità dell’applicazione di turno. In maniera analoga, i processi operativi non devono essere considerati come competenza esclusiva di un team bensì come la parte conclusiva di un iter condiviso avviatosi in un ambiente di sviluppo. Il deploy del software non è quindi un processo operativo quanto l’atto finale dell’iter di sviluppo di un’applicazione. Riallacciandoci a quando detto nel secondo punto, l’unificazione dei processi non fa altro che aumentare le interazioni fra team con i benefici descritti in precedenza;
- innovazione continua. Il miglioramento e l’integrazione dei processi è una pratica continua. La tecnologia si evolve rapidamente, ricorda Turnbull, così come le esigenze dei clienti. Non bisogna mai smettere di apprendere ed in quest’ottica anche un’interruzione di servizio (outage) può essere un’ottima occasione per imparare dai propri errori, coinvolgendo amministratori e sviluppatori.
Il perchè la filosofia DevOps abbia avuto successo è stato probabilmente chiarito dai punti appena elencati.
