Quando si tratta di IT, non mancano e non mancheranno mai nuove strutture e visioni, ogni anno o quasi sembra che qualche novità arrivi sempre e proprio come c’è stata la grande spinta per ITIL, ora c’è per DevOps.
Per l’IT la sfida non consiste solo nell’infinito susseguirsi di acronimi ma su come tutta questa serie di elementi e cambiamenti in atto possano impattare sulla sua operatività: seppure da sempre abbastanza flessibile nell’adattarsi alla natura mutevole della tecnologia, ora si trova infatti a dover gestire dinamiche e fattori provenienti da ambiti diversi dal proprio, con manager che cercano di attribuirgli etichette e condizioni. Sono sconcertanti sia la quantità di risorse umane sia i costi complessivi richiesti dalla struttura grezza di molti framework di riferimento – ITIL, per esempio – ed è naturale quindi che molte aziende propendano per l’adozione solo di alcune parti di una nuova struttura, procedendo poi con l’inserirle in quegli ecosistemi IT dove hanno senso per il business e hanno comunque un impatto. Il grande svantaggio del costo di DevOps apre ad un’opzione più economica: l’adozione frammentaria.
DevOps ha un prezzo
DevOps, per definizione, è un insieme di pratiche che combinano lo sviluppo del software con le operations IT per accorciare i cicli di vita e favorire la delivery continua ad alta qualità, un obiettivo che suona invitante ma allo stesso tempo anche molto complesso e costoso da raggiungere.
Inoltre, DevOps funziona solo per alcune applicazioni software. La maggior parte delle organizzazioni non si impegna in rilasci multipli giornalieri, come invece per esempio accade nel settore della finanza o della sanità, è quindi la tipologia di applicazioni in uso che guida le scelte organizzative relative all’adozione di DevOps indicando se è la decisione corretta ed esistono alcuni fattori importanti di cui tenere conto.
La descrizione di DevOps non va mai in dettaglio su come portare avanti i vari task – un altro svantaggio – ma è proprio in questa ambiguità che le organizzazioni IT possono individuare alcuni concetti che rispondono ai loro bisogni di business, senza essere obbligati ad un passaggio completo al DevOps. Mentre ci sono diversi passi che avvengono nello stack completo di DevOps, esistono due aree chiave che possono avere un impatto sostanziale: il controllo versione (control version) e l’automazione.
Control version
Gli strumenti e le tecniche di controllo versione sono cambiati nel corso degli anni, ma la loro premessa di base è rimasta invariata: quando si effettua un cambiamento, si incrementa una lettera di revisione o un build number, per registrare la modifica. Sembra ingannevolmente semplice, ma risponde all’unica domanda che affligge l’IT quando qualcosa si danneggia: cosa è cambiato?
Ma il controllo versione non è il controllo del cambiamento, riguarda la documentazione e il tracciamento dei cambiamenti e non la gestione delle varie modifiche attraverso step di approvazione sulla documentazione.
DevOps, d’altra parte, riguarda l’agilità e la riduzione di quella finestra temporale e il controllo del cambiamento può influire sulla velocità, a seconda della durata del processo di approvazione. Sostituire il controllo modifiche con il controllo versione permette ulteriore agilità e velocità, mantenendo la responsabilità e la rendicontazione, ma senza pause per l’approvazione.
Alcuni sostengono che questo metodo aumenti il rischio e l’iter che ostacola il procedere della revisione della documentazione potrebbe coinvolgere professionisti non IT che non colgono la portata e l’effetto del cambiamento proposto. Le organizzazioni IT devono assicurare che la documentazione sia corretta, indipendentemente dal flusso di lavoro in atto, ma, idealmente, eliminare i ritardi inutili per le revisioni effettuate da inesperti.
Automazione
Sono pochi i processi e i workflow che non traggono beneficio dall’automazione e tra questi ci sono il controllo della qualità e i rilasci del software, entrambi processi in cui non contano solo gli spesso citati miglioramenti in termini di velocità. Quando si tratta di test e rilascio di software, è infatti la coerenza l’aspetto fondamentale che fa andare avanti il processo, la velocità resta un beneficio aggiuntivo.
L’introduzione di variabili può produrre risultati inaspettati nei test che poi creano ritardi nel rilascio: un piano di test solido e coerente permette ai team IT di restringere l’ambito e filtrare i dati in base al singolo cambiamento effettuato in modo che i risultati siano una rappresentazione diretta della modifica compiuta e niente di più. In questo modo si riduce la presenza di dati casuali o irrilevanti. Adottare un approccio più mirato e frammentario al DevOps può permettere al personale di svolgere più ruoli gestendo meglio il proprio tempo. I cambiamenti, come il controllo di revisione, non sono così grandi da avere un impatto sull’insieme dei workflow esistenti.
Uno svantaggio significativo di DevOps è l’ambiguità: è infatti un concetto molto vasto e complesso che per le organizzazioni IT non è facile tradurre in una misura esatta. L’alternativa giusta al DevOps totale è quella di scegliere i pezzi ideali per il proprio business; il cherry picking à la carte è una decisione tollerabile se non comprensibile in un settore IT in continuo cambiamento.
