La transizione verso l’approccio DevOps richiede un’evoluzione di mentalità e cultura aziendali. In poche parole, un modello DevOps punta alla rimozione delle barriere tra due team (Dev e Ops) che in genere non comunicano tra loro (il muro che deve essere distrutto), gli sviluppatori e il team operativo. In alcune organizzazioni i due gruppi potranno addirittura essere fusi in un’unica unità, in cui i tecnici potranno occuparsi di problematiche operative e di business mentre gli operativi acquisiranno abilità degli sviluppatori.
Nell’approccio DevOps, i due team collaborano a stretto contatto per ottimizzare sia la produttività degli sviluppatori sia l’affidabilità delle operazioni. Essi tendono a comunicare con maggiore frequenza per ottenere una maggiore efficienza e migliorare la qualità dei servizi che forniscono ai clienti. Inoltre, mantengono sempre il controllo sui propri servizi, spesso oltre la definizione tradizionale del loro ruolo, perché sono concentrati sulle esigenze del cliente finale e desiderano contribuire a soddisfare tali esigenze. Anche i team dedicati a controllo della qualità e sicurezza spesso sono coinvolti più direttamente nei compiti di questi team. Le aziende che adottano un modello DevOps, indipendentemente dalla loro struttura organizzativa, dispongono di team che annoverano tra le loro responsabilità il controllo dell’intero ciclo di vita di sviluppo e infrastruttura.
Una prassi fondamentale è aumentare la frequenza degli aggiornamenti e diminuirne le dimensioni. Questo è uno dei modi con cui un’azienda può innovare più rapidamente a beneficio dei propri clienti. Quando la frequenza degli aggiornamenti è maggiore e le dimensioni minori, è più facile tenere sotto controllo il rischio. I bug vengono risolti più rapidamente perché è più facile individuare quale implementazione ha provocato il problema. Anche se la cadenza e le dimensioni degli aggiornamenti variano, le aziende che adottano un modello DevOps distribuiscono aggiornamenti più di frequente rispetto a quelle con modelli di sviluppo di software tradizionali. Sarà inoltre possibile usare un’architettura di microservizi per rendere le applicazioni più flessibili e facilitare l’innovazione. L’architettura di microservizi suddivide sistemi grandi e complessi in progetti semplici e indipendenti. Le applicazioni vengono spezzate in singoli componenti (i servizi), ciascuno dei quali ha una sola funzione e opera in modo indipendente sia rispetto agli altri servizi sia rispetto all’applicazione.
Questa architettura riduce il carico di lavoro di coordinamento per aggiornare le applicazioni; quando tutti i servizi sono assegnati a team agili e di piccole dimensioni che gestiscono ogni singolo servizio, anche l’azienda nel suo insieme è più agile. L’utilizzo di microservizi e la maggiore frequenza delle release aumentano tuttavia il numero di distribuzioni, il che può presentare problemi dal punto di vista operativo. Le prassi DevOps come l’integrazione continua e la distribuzione continua risolvono questi problemi e consentono alle organizzazioni di velocizzare le distribuzioni in modo sicuro e affidabile. Le prassi di automatizzazione dell’infrastruttura, come ad esempio l’infrastruttura come codice e la gestione della configurazione, aiutano a mantenere elasticità e tempi di risposta ottimali delle risorse di organizzazione. Monitoraggio e registrazione di log, inoltre, aiutano i tecnici a tenere sotto controllo le prestazioni di applicazioni e infrastruttura, per rispondere in modo tempestivo ai problemi. In sintesi, globalmente, queste prassi sono uno strumento eccezionale per fornire aggiornamenti più rapidi e affidabili ai clienti.
Corso DevOps Foundation di DevOps Institute al link https://www.hrv-swiss.consulting/it/01-devops-fnd/
