Di Paolo Arcagni, System Engineer Manager di F5 Networks
A cosa pensi quando senti il termine “DevOps”? A un concetto astruso, impenetrabile, che ha a che fare con un nuovo mondo solo per i più coraggiosi? Nulla di tutto questo? O forse non hai nemmeno sentito parlare di DevOps? Non preoccuparti, ne sentirai parlare sempre di più.
In passato, la delivery del software avveniva in modo relativamente semplice. Tutti i requisiti erano definiti con il cliente prima della fase di coding e del testing di Quality and Assurance (Q&A). Il team responsabile delle Operation a un certo punto interveniva e distribuiva tutto. In modo semplice, limpido e perfettamente ordinato.
Non è più così: oggi affrontiamo una pressione crescente che porta le aziende a dovere introdurre nuove funzionalità e servizi nel modo e nel momento in cui sono necessari.
Fino a quando la velocità e l’efficienza non rappresentano un problema, il vecchio modello funziona bene. Tuttavia, lo status quo progressivamente diventa sempre più incompatibile con le ambizioni moderne.
Considerate, ad esempio, la situazione in cui più team di sviluppatori si trovino a lavorare a un progetto in parallelo, cosa che per altro avviene quasi sempre.
Cosa succede se una volta che tutto è stato codificato – e magari è stata finalizzata anche l’intera applicazione – questi sviluppatori scoprono che alcuni componenti sono incompatibili? A quel punto è necessario attendere che tutti team terminino l’attività prima di riunire il codice in un’unica applicazione, e questo rappresenta uno spreco di tempo notevole.
Il dinamismo dello sviluppo in questo caso svanisce e si rischia d cadere in un lungo e tortuoso esercizio di pulizia o di retrofitting.
Ora, immaginiamo uno scenario differente, in cui l’integrazione del codice avviene con successo e il team Q&A richiede al team delle Operation un ambiente specifico per testare la propria applicazione. Senza l’automazione, le Operation potrebbero avere bisogno di giornate intere prima di fornire l’ambiente richiesto. Nel frattempo, è probabile che gli sviluppatori continuino a programmare.
Dobbiamo tenere presente che, se viene rilevato un bug, avviene durante i test, quindi il pericolo è che gli sviluppatori continuino a sviluppare il codice su uno più bug già esistenti. Alla fine, anche in questo caso lo sviluppo non è più dinamico, e il rischio potenziale è quello di dover avviare un’importante revisione di tutto il processo di codifica.
Un ulteriore aspetto critico è legato al ritmo con cui le Operation sono in grado fornire l’ambiente giusto per testare il codice. Nelle organizzazioni più grandi, possiamo incorrere in ritardi consistenti, che comportano intere settimane di lavoro e possono coinvolgere più di un dipartimento.
Quindi, come possiamo contrastare tutti questi ritardi e far sì che la delivery avvenga in modo coerente e continuo? La risposta è proprio nel DevOps, che funziona in modo differente e che si fonda su sei aspetti fondamentali, il suo ABC:
• Al primo posto troviamo la continuous integration (CI). L’approccio DevOps, infatti, utilizza una metodologia agile in cui, in genere, blocchi funzionali di codice più piccoli sono integrati regolarmente e perfettamente nello sviluppo principale dell’applicazione. Gli errori sono individuati e corretti rapidamente attraverso un processo di integrazione continua.
I piccoli pezzi di codice che entrano in gioco sono creati all’interno di un loro ambiente isolato (containerizzato) in cui ciascun componente ha in genere un punto di comunicazione per “parlare” con altri componenti noti come API (Application Programming Interface). Questo approccio offre allo sviluppatore una flessibilità sufficiente per aggiungere o rimuovere uno o più componenti senza influire sugli altri. Un concetto noto come “architettura dei microservizi”, in cui ogni componente ha fondamentalmente una capacità plug-and-play.
• Secondo elemento, non meno importante, è la continuous delivery (CD). A seguito dell’integrazione continua, il codice integrato viene automaticamente testato tramite diversi ambienti, per tutto il processo fino alla pre-produzione in cui è pronto per essere distribuito.
• Alcune aziende non automatizzano ulteriormente, realizzando la terza fase, ma preferiscono il deployment manuale. L’interazione tra CI e CD è definita come CI/CD. Segue, quindi, il Continuous Deployment (CD) per giungere all’obiettivo finale del DevOps: integrazione continua seguita da delivery continua e distribuzione continua (CI / CD²). In questo modo, il deployment delle applicazioni alla produzione avviene in modo automatico.
• Nell’ABC del DevOps non possiamo trascurare l’approccio cloud centrico perché il DevOps prospera nel cloud, che supporta in modo nativo i sui strumenti e rende possibile quella velocità e automazione necessarie per promuovere innovazioni rivoluzionarie.
• Al quinto posto troviamo l’infrastructure as a Code, cioè una infrastruttura altamente automatizzata ideale per il team di sviluppo che vuole distribuire automaticamente il codice in ogni punto, dal test all’ambiente di distribuzione. Noto anche come IaaS, rappresenta un antidoto potente ai potenziali colli di bottiglia tra Dev e Ops. Una IaaS adeguata dovrebbe comprendere strumenti di provisioning dell’infrastruttura, che permettono di creare e distribuire l’infrastruttura con un semplice clic o compilando rapidamente un template. I servizi cloud ne sono un buon esempio. Tale infrastruttura dovrebbe includere anche strumenti di gestione della configurazione (ad esempio, la possibilità di aggiornare, con un singolo comando, anche 10.000 server).
• Ultimo elemento ma imprescindibile, è la collaborazione. Ancor più che in altri ambiti dell’IT, il successo del DevOps dipende in larga misura da una collaborazione intensa e coordinata tra clienti, sviluppatori e team di IT Operation. Gli sviluppatori devono concentrarsi sulla codifica, le Operation sulla gestione dell’infrastruttura automatizzata, ed entrambi devono confrontarsi per scoprire nuovi modi di innovare e migliorare sia i processi che i risultati. Lavorare a silos è ormai un retaggio del passato.
In sintesi, per avviare il DevOps è fondamentale una pratica che consenta di ottimizzare la pipeline di distribuzione delle applicazioni, promuovendo l’efficienza, ottimizzando i processi, rimuovendo i silos, utilizzando gli strumenti di automazione, standardizzando le piattaforme e stabilendo una forte cultura di collaborazione. È un modo efficace per aggirare i colli di bottiglia che lo sviluppo tradizionale e le norme imposte dall’infrastruttura comportano, rappresentando una forza inarrestabile per l’innovazione.
DevOps significa tutto questo, e molto di più. Fino ad oggi, infatti, l’influenza concreta del DevOps si è manifestata solo parzialmente. Potremo affrontare le nuove sfide solamente mantenendo la nostra curiosità accesa, la mente aperta e la collaborazione tra i team di sviluppo viva.
