DevOps: cos'è e perché adottarla

Nascondi

Quella che segue è una trascrizione automatica dell'episodio.

Pensieri in codice. Idee dal mondo del software, a cura di Valerio Galano. Buongiorno a tutti ragazzi e ben ritrovati per un nuovo episodio di Pensieri in codice, il podcast in cui parliamo di argomenti presi dal mondo del software, di internet e della programmazione. L’episodio di oggi uscirà con un certo ritardo rispetto alla tabella di marcia ed ecco perché sto registrando in questo orario in fausto nonostante il traffico, la pioggia, le campane e tutti i disturbi audio possibili e immaginabili. Purtroppo però l’argomento di oggi è un territorio abbastanza nuovo anche per me e quindi ho riscritto questo episodio almeno due volte. Spero però che ne venga fuori qualcosa di abbastanza comprensibile e che tutti questi rumori non ci diano troppo fastidio. In caso contrario vi invito a farmelo sapere nei commenti oppure venendomelo a dire sul gruppo Telegram di Pensieri in codice di cui trovate il link in descrizione. Prima di procedere però con l’argomento di oggi vi rubo giusto un minuto per fare un paio di avvisi. Innanzitutto sabato 16 11 ho avuto il piacere di partecipare in qualità di ospite ad un episodio del podcast l’intelligenza artificiale spiegata semplice con Giacinto Fiore e Pasquale Viscanti. Abbiamo parlato di auto a guida autonoma, acquisti tramite voce, app per bambini non udenti e molto altro. Vi lascio quindi il link della puntata in descrizione e mi raccomando andate a recuperarla. Secondo avviso nell’episodio precedente il numero 21 sull’anatomia di un sito web abbiamo accennato al concetto di indirizzo IP e come mi faceva notare Cristiano nel gruppo Telegram di Pensieri in codice ho detto che i numeri che compongono gli indirizzi IP vanno da 1 a 255. In realtà però questo non è vero perché essi possono variare da 0 a 255 e quindi mi scuso per aver fatto confusione. Fatta quindi questa doverosa precisazione possiamo ora procedere e provare insieme a capire che cosa si intende e a cosa serve la DevOps. Negli ultimi tempi la parola DevOps sta iniziando a diffondersi anche al di fuori degli ambienti prettamente tecnici dello sviluppo software e di sicuro chiunque abbia mai avuto contatti con il mondo del software o con i suoi relativi processi di produzione avrà almeno sentito nominare questa parola. Ora per chi lavora in un contesto moderno di produzione del software il concetto sarà o almeno dovrebbe essere ben chiaro ma per chi invece ne viene in contatto solo marginalmente magari perché non si occupa principalmente di software o perché si trova ancora in ambienti che implementano processi di tipo tradizionale o ancora perché è agli inizi della propria carriera di programmatore beh allora forse l’idea di DevOps potrebbe essere un po’ confusa se non addirittura oscura. Questo episodio sarà quindi principalmente dedicato a chi di DevOps conosce fondamentalmente solo il termine ed è interessato a capire perché scegliere i propri fornitori tra coloro che utilizzano questa metodologia oppure implementare i propri processi di sviluppo tramite DevOps sia al momento la scelta migliore. Come abbiamo anticipato la DevOps è dunque una metodologia il che significa che è essenzialmente un modo particolare di svolgere determinate attività un insieme cioè di direttive la cui applicazione ha effetti benefici su di uno o più processi. Nel discorso che andremo a fare è importante tenere a mente che questa metodologia può essere applicata essenzialmente al processo di sviluppo dei software in cloud. Quei software cioè che per funzionare hanno bisogno di essere installati su infrastrutture server più o meno complesse in gergo si dice deployati. Nel metodo tradizionale di sviluppo del software la produzione passa attraverso le mani di varie figure professionali l’analista o programmatore che scrive il codice sulla base delle richieste del cliente, il collaudatore che fa i test, l’amministratore di sistema che installa il software nei vari ambienti di testing produzione eccetera. Come però abbiamo detto più volte fin dai primi episodi di questo podcast un software difficilmente è un’entità statica. Esso infatti può essere affetto da bug o può essere necessario implementare nuove funzionalità e quindi un prodotto che tuttora è in produzione va sia monitorato per identificare eventuali problematiche sia se necessario vanno pianificate delle modifiche o correzioni che dovranno essere sviluppate, testate e installate a loro volta dando così via ad una sorta di processo a ciclo continuo. Lo scopo della metodologia DevOps è essenzialmente quello di rendere il più agile possibile l’intero processo di produzione a partire dallo sviluppo del software fino ad arrivare al monitoraggio in produzione passando ovviamente per i test e i deploy sui vari server dell’infrastruttura. L’idea alla base è rendere più fluido il rapporto di collaborazione tra chi scrive il codice, chi lo testa, chi gestisce le infrastrutture su cui verrà deploiato e chi ne monitora il funzionamento e l’efficienza. Tutto questo spingendo sui vari meccanismi di collaborazione fino ad arrivare al caso ottimale in cui le figure coinvolte nel processo si fondono in un’unica professionalità. Le aziende che applicano quindi l’approccio DevOps allo stato dell’arte possono contare su di un insieme di tecnici che formano un unico team, quello appunto di DevOps, le cui competenze spaziano lungo tutto il processo produttivo del software, differentemente dalle aziende tradizionali che hanno i classici team che operano separatamente. La metodologia DevOps punta quindi a snellire l’intero processo di sviluppo del software e per ottenere questo risultato prescrive l’impiego di una serie di prassi, che in inglese prendono il nome di best practice, che agiscono sulle varie fasi del ciclo di produzione. La prima e sicuramente fondamentale fra queste prassi consiste nell’aumentare la frequenza degli aggiornamenti del software e diminuirne al tempo stesso le dimensioni. In questo modo le modifiche al codice saranno più circoscritte rispetto agli aggiornamenti monolitici previsti dal processo tradizionale, ma grazie alla maggiore frequenza sarà comunque possibile preservare, se non addirittura aumentare, la quantità di funzionalità e correzioni rilasciate nel tempo. Contemporaneamente, per via delle minori dimensioni dei rilasci, diventerà automaticamente più difficile introdurre nuovi bug e più semplice risolvere quelli che eventualmente dovessero presentarsi. Nella stessa direzione è orientata anche la seconda best practice della DevOps, che consiste nell’utilizzo dei microservizi. In un’architettura a microservizi, infatti, un sistema complesso viene suddiviso in parti più piccole, che funzionano singolarmente e che poi comunicano fra loro per riprodurre il comportamento del sistema iniziale. Ognuna di queste parti prende appunto il nome di microservizio e si adopera al fine di svolgere un’unica funzione. All’occorrenza, poi, è in grado di interloquire con gli altri microservizi tramite interfacce personalizzate e a basso impatto sulle prestazioni. Come per la riduzione dei rilasci, il principio di base è sempre quello della semplificazione. Infatti un’architettura del genere, innanzitutto, riduce le dimensioni dei singoli componenti, diminuendo anche la quantità di codice da manutenere e da lavorare. E inoltre riduce il carico necessario per lo sviluppo, perché è possibile affidare il compito di gestire ogni microservizio ad un team che potrà essere di minori dimensioni e potrà quindi lavorare in modo più reattivo. Come molti avranno già intuito però, il fatto di effettuare aggiornamenti più frequenti e quello di affidarsi ad una struttura a microservizi avranno anche delle ripercussioni negative sulle operazioni. La quantità dei rilasci necessari per gestire tutta l’infrastruttura, infatti, aumenteranno notevolmente. Al posto di un unico grande aggiornamento se ne avranno tanti più piccoli e non sarà più necessario rilasciare un unico software monolitico, ma un certo numero, anche abbastanza sostenuto, di microservizi. Questo potrebbe apparire come un problema dal punto di vista delle prestazioni dell’intero team, ma ovviamente DevOps ha una serie di best practice anche per risolvere questa tipologia di problema. La continuous integration, ad esempio, che in italiano diventa integrazione continua, consiste proprio in un metodo di sviluppo secondo cui i programmatori caricano le modifiche al codice su di un unico repository centralizzato e da questo vengono poi create le build e i relativi test in maniera automatica. Adottare una soluzione automatizzata del genere significa abbattere notevolmente i tempi rispetto al modello tradizionale nel quale queste operazioni di impacchettamento e verifica vengono normalmente svolte a mano e pertanto sono sicuramente più lente e soggette a possibili errori umani. Come estensione dell’integrazione continua poi esiste la distribuzione continua o continuous delivery in cui oltre alla preparazione delle build e dei test il codice aggiunto al repository centralizzato viene anche rilasciato nei vari ambienti compresa la produzione, eliminando così ulteriori passaggi manuali e velocizzando ancora di più il processo. Come accade per i rilasci però anche l’infrastruttura richiesta da DevOps cresce e si complica notevolmente rispetto a quella tradizionale. Questo perché diventa necessario supportare l’intero ecosistema dei microservizi e ciascuno di essi potrebbe avere requisiti differenti e sicuramente un server o un contenitore apposito. Quindi l’approccio DevOps prevede una prassi specifica anche per ciò che riguarda la gestione degli ambienti e dei relativi server. Questa prassi prende il nome di Code Infrastructure o in italiano infrastruttura come codice e consiste nell’applicare le metodologie di controllo di versione e integrazione continua anche ai processi di provisioning e gestione e configurazione dell’infrastruttura. Nella DevOps infatti vengono ampiamente utilizzati i servizi in cloud che espongono interfacce automatiche sia per la creazione che per la gestione di server e contenitori virtuali sui quali verranno poi deploiati i microservizi e i vari componenti software. I programmatori possono quindi sviluppare proprio del software che comunichi con i servizi in cloud dicendo loro quali e quanti server istanziare, quali servizi attivare, come collegarli fra loro e come configurarli. Questo codice che di fatto descrive le caratteristiche dell’intera infrastruttura e non delle funzionalità potrà essere esso stesso archiviato in un repository centralizzato, testato e lanciato in maniera automatica al pari del codice vero e proprio del software. I vantaggi di un approccio simile sono che innanzitutto è possibile configurare più ambienti perfettamente identici ridurre così il rischio di sviluppare software incompatibile con le destinazioni finali sulle quali dovrà essere deploiato. In secondo luogo diventa molto più semplice scalare cioè variare il numero di server o container per i microservizi o le risorse che essi hanno a disposizione. A valle poi di tutti questi processi la DevOps prescrive anche delle best practice riguardanti il monitoraggio delle risorse e l’archiviazione dei log. In questa nuova ottica di rapidità infatti eventuali problemi come errori del software o cali di prestazioni vanno evidenziati il prima possibile e questo può avvenire tramite configurazione di allarmi automatici o di analisi in tempo reale. Solo in questo modo il team potrà essere al corrente dell’esperienza vissuta dall’utente finale e potrà intervenire per correggere malfunzionamenti o scalare risorse all’interno del sistema nel minor tempo possibile. In ultimo ma non certo per importanza affinché tutto quello che abbiamo finora descritto possa funzionare in modo corretto DevOps prescrive anche l’adozione di strumenti dedicati alla collaborazione interna e alla condivisione delle informazioni. Se ai vari membri del team è infatti richiesto di sapere agire su tutta la catena di produzione è anche necessario che essi siano al corrente di ogni informazione importante riguardante i processi e all’occorrenza abbiano un modo ben definito per reperire documentazione e dettagli sui vari componenti, sull’infrastruttura, sugli strumenti eccetera. L’applicazione di una o più delle meccaniche di cui abbiamo parlato in questo episodio hanno un enorme impatto sia sul prodotto finale che sulle performance dell’intero team coinvolto nel processo. In definitiva più si sarà in grado di adottare e rispettare la metodologia DevOps e maggiori saranno i vantaggi che ne deriveranno. Velocità, affidabilità, aggiornamenti continui e bug fix più semplici e veloci. Bene ragazzi siamo dunque giunti alla fine di questo episodio. Io mi rendo conto che forse l’argomento è un po’ complicato. Voi fatemi sapere se vi interessa, se vi è piaciuto e se l’episodio è stato sufficientemente comprensibile. Io vi ricordo che in descrizione trovate tutti i link alle fonti, ai vari social e al programma di affiliazione amazon se volete sostenere questo progetto. Per ora quindi è tutto, vi saluto e vi do appuntamento al prossimo episodio.

Nascondi