<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=1267344923293614&amp;ev=PageView&amp;noscript=1">

Red Blog

Perché l’automazione è così importante per l’approccio DevOps

Davide Costanza,

approccio devops_collaboration_automation

Oggi torno a parlarvi di DevOps. Nel precedente articolo, Che cosa è il DevOps e perchè dovrebbe interessarti, vi ho parlato dell’importanza della collaborazione tra Dev e Ops. Tuttavia, questa rappresenta solamente un primo passo nella giusta direzione, ma non è sufficiente.

 

Scarica subito: "IT trend 2018 - le tendenze della Digital Transformation"

 

Preso singolarmente, infatti, questo unico aspetto del ben più complesso approccio DevOps potrebbe esser definito come ToyOps: l’offrire il proprio toy-ops a ciascun team dev, non comporta alcun cambiamento culturale, in quanto l’Ops continuerà a svolgere i compiti tipici dell’Ops mentre i dev... continueranno a fare i dev.

In questo modo, gli ops continuano a “subire”: i dev delegano loro qualcosa, ma essendo di natura “problem solver”, hanno la tendenza a risolvere i problemi da soli e ciò comporta necessariamente fraintendimenti, mancanza di sintonia tra i due team e/o errori.

Ciò che fa scalare il devops ad un altro livello è l’Automazione, ed oggi vi parlerò proprio di questo.

metodologia devops_automation

Dal lato Ops:

L’automazione serve a rendere automatici, appunto, dei processi che tipicamente vengono realizzati in maniera manuale.

Quando sono gli sviluppatori a doversi preoccupare di questi processi manuali, dal momento in cui non si tratta di scrivere codice sorgente, capita che questo venga fatto in maniera un po’ disorganizzata in quanto non si tratta del loro focus, per cui è un aspetto che spesso nei progetti viene lasciato da parte.

Nell’area sistemi, invece, questo è un problema che si è iniziato ad affrontare ormai da tempo, grazie a tool di configuration management. Tuttavia, mentre un tempo questi strumenti erano difficili da programmare, negli ultimi tempi sono diventati più facili da usare ed implementare. Un esempio è Ansible, utilizzato per fare provisioning di macchine virtuali. Ansible è in grado di controllare l’installazione del software all’interno dei sistemi operativi, ma non solo. In una virtual machine è in grado di controllare le installazioni, tramite dei piccoli file di configurazione che devono essere scritti dagli ops.

Gli Ops quindi passano dal fare (virtual machine) al descrivere (file): viene così introdotta una descrizione di una determinata cosa da fare a livello infrastrutturale come codice.

Per cosa passa l’automazione? L’automazione nasce nel momento in cui si va ad introdurre il concetto di infrastructure as code. Tu, Ops, descrivi le cose, non le fai.

devops_iron_man

Dal lato Dev:

Qual è qui il problema principale? I dev non fanno tanta automazione.

Se devono gestirsi infrastrutture (es. manipolazione dell’ambiente che vanno a sviluppare), utilizzano delle procedure manuali. Anche solo per sviluppare il software, tipicamente il dev fa tanto manualmente: i test vengono fatti manualmente, gli ambienti di deploy e test vengono configurati manualmente, e così via.

Configurare manualmente le cose, però, è male: comporta errori oppure può accadere che una volta la configuri in un modo, la volta dopo in un altro e quando le vai a rivedere successivamente può accadere che non sai più quale delle due era stata fatta bene, senza errori. Questo concetto viene definito Configuration drift: la deriva della configurazione che rappresenta la conseguenza del fare le cose manualmente. La manualità spesso comporta il gestire qualcosa in cui non sai cosa c’è dentro. Per minimizzare il rischio di errore, bisognerebbe quindi avere dei sistemi che siano sempre in uno stato noto, vale a dire uno stato per cui, da qualche parte, esiste una descrizione formale.

DevOps, automazione e Openshift.jpg

Come si fa a gestire le cose in maniera tale che sia gestito in uno stato noto?

Con l’automazione! Questa permette infatti di descrivere in maniera formale lo stato di un sistema. Uno stato noto rappresenta infatti uno stato di un sistema di automazione descritto in maniera dichiarativa e formale in un documento; tale descrizione dichiarativa dello stato di un sistema ti dice in sintesi “questo sistema a t0 è fatto così”, ti offre quindi una fotografia del sistema al tempo 0.

Ora, supponiamo vogliate variare lo stato di questo sistema, ci sono due modalità per farlo:

1) vecchia maniera (back to the 60s!): vai sull’oggetto, sul binario e lo modifichi direttamente;

2) maniera più efficiente: se hai un codice sorgente da cui può essere costruito quel sistema, puoi modificare il sorgente. È più facile lavorare col codice sorgente. In questo modo infatti non vai a modificare l’artefatto finale ma sempre la descrizione formale. E questo puoi farlo con strumenti automatici.

Il nostro racconto sul DevOps continua... Stay tuned!

Red Hat Open Source Day 2017

OSD2017.jpg

Come Advanced Business Partner Red Hat, saremo all'Open Source Day 2017 organizzato da Red Hat, che si terrà a Milano e Roma rispettivamente il 7 e 9 Novembre.

Durante la conferenza di Milano, terrò un incontro dal titolo "Miglioramento del processo di sviluppo mediante DevOps e OpenShift", mentre il mio collega Luigi De Masi (Middleware and integration specialist di Extra Red) a Roma parlerà di "Monitoraggio delle applicazioni su OpenShift con Prometheus".

Vi invito a partecipare, registrandovi all'OSD 2017. La partecipazione all'evento è gratuita ed è una grande opportunità per chiunque operi nel mondo IT! 

Per approfondire le vostre conoscenze sulla metodologia DevOps, ma anche su tutti gli altri trend della Digital Transformation, come Cloud e IoT, vi invito a scaricare il nostro ebook gratuito "IT trend 2018: le tendenze della Digital Transformation".

Scarica l'ebook IT trend 2018: le tendenze della Digital Transformation

Share this post

  

Commenti

Prova Red Cloud Gratis per 30 Giorni

Iscriviti alla newsletter

Condividi questo blog

   

Post correlati