E se dovessi progettare il tuo processo DevOps IT per una nuova azienda? Cosa automatizzeresti per migliorare le capacità predittive e accelerare la distribuzione delle applicazioni?
Visualizza tutti i capitoli
"Molte aziende esistono grazie alle applicazioni, questo significa che, se si esclude il fatturato, le prestazioni delle applicazioni sono il parametro più critico", afferma Chris Farrell, Vice President di Automation Value Services Software presso IBM. "Quando l'applicazione è il tuo business, la velocità è un'arma e al contempo un indicatore di qualità per la tua stessa applicazione".
In questo mondo di iper-implementazione, secondo Farrell è fondamentale che le organizzazioni "stravolgano il copione" del modo in cui pensano di conseguire integrazione e distribuzione continue (CI/CD). "Anziché parlare del numero di giorni tra una distribuzione e l'altra, bisognerebbe parlare del numero di aggiornamenti in un certo arco di tempo" sostiene. "Quanto più breve è l'intervallo, quanto più si sale di livello."
La serie "Ripensa e automatizza" di IBM invita i leader a reimmaginare i processi di business e IT comuni affrontandoli da una prospettiva completamente nuova e adottando l'automazione. Il tipico processo DevOps è una serie ciclica di otto passaggi: pianificazione, codifica, build e test, seguiti da rilascio, distribuzione, operazioni e monitoraggio. Quando uno degli otto passaggi rallenta, frena l'intera pipeline.
"Al di là del mondo 'nativo digitale', migliorare la velocità può essere ancora più critico per le grandi imprese storiche", scrive Hans A.T. Dekkers di IBM in "The speed of smarter architecture", saggio pubblicato da IBM Institute for Business Value. “Quando vediamo la durata della vita media delle aziende incluse nell'indice S&P 500 scendere da 60 anni (negli anni '60) a meno di 20 anni (oggi), con una tendenza accelerata verso un turnover ancora più elevato, è la diretta conseguenza del fatto di avere, o non avere, velocità."
Scopri nuovi modi per migliorare il tuo processo DevOps IT in un workshop gratuito sull'innovazione dell'automazione.
In una prospettiva di CI/CD, gli sviluppatori devono mirare a un'unica build, implementazione ovunque e gestione costante delle pipeline. Ecco come Farrell ridisegnerebbe il ciclo tipico utilizzando l'automazione, sottolineando che qualsiasi miglioramento richiede "un impegno totale in ambito DevOps e aspirare alla distribuzione continua".
Passa dal monitoraggio all'osservabilità
"Potrebbe sembrare strano, ma se dovessi riprogettare il processo DevOps da zero, il mio primo obiettivo sarebbe l'ultimo step: il monitoraggio", afferma Farrell. "Sarebbe necessario sbarazzarsi degli strumenti appartenenti alla sfera del monitoraggio tradizionale e passare all'osservabilità il più rapidamente possibile. Infatti, quanto maggiore è il numero di workload a cui si applica l'osservabilità, tanto più in fretta e accuratamente qualsiasi membro Ops sarà in grado di arrivare da un problema alla sua causa principale, senza coinvolgere sviluppatori e altri esperti in materia".
In ambito IT l'osservabilità si riferisce a strumenti e pratiche software che consentono di aggregare, correlare e analizzare un flusso costante di dati prestazionali provenienti da un'applicazione distribuita, insieme con quelli dell'hardware e della rete su cui è eseguita, in modo da poter risolvere i problemi ed eseguire il debug dell'applicazione e della rete in modo più efficace. L'osservabilità è un'evoluzione naturale del monitoraggio delle prestazioni delle applicazioni (APM) per affrontare meglio la natura sempre più rapida, distribuita e dinamica delle implementazioni di applicazioni cloud-native.
Al di fuori del monitoraggio, ogni passaggio DevOps può già contare su molti strumenti che accelerano, integrano e automatizzano il processo. "Con pipeline accelerate e i moderni stack tecnologici i tradizionali strumenti di monitoraggio stentano, in particolare perché l'esecuzione manuale di setup, riconfigurazione e/o ridistribuzione rallenta tutto", afferma Farrell. La piattaforma di osservabilità offre comprensione, vale a dire visibilità nel contesto, e si adatta a qualsiasi modifica in tempo reale, il che significa che è sempre aggiornata.
L'osservabilità inoltre lega insieme applicazioni e infrastruttura, il che è necessario nel momento in cui i confini tra codice applicativo, infrastruttura basata sul codice e stack hardware si confondono. "Se si pensa all'esigenza di celerità in tutta la pipeline, è indispensabile che le piattaforme siano altrettanto flessibili e veloci dello stesso codice applicativo", sostiene Farrell.
Automatizza l'osservabilità per migliorare velocità e risultati
"Giungere all'osservabilità è un'esigenza assoluta, ma deve essere automatizzata", afferma Farrell. Una piattaforma di osservabilità automatizzata dotata di analytics engine consente alla piattaforma stessa di fornire comprensione, consigli e correzione dei problemi. Non è più necessario dedicare tempo alla diagnostica, l'operazione viene eseguita automaticamente.
Oltre alla velocità, l'automazione dell'intero processo DevOps IT offre numerosi vantaggi. Il feedback continuo mette in grado gli sviluppatori di agire in modo rapido e deciso per il miglioramento costante. L'aumentata capacità di rilevamento degli errori consente loro di apportare correzioni prima di possibili conseguenze che Farrell definisce "catastrofiche". Infine, l'integrazione di sistema accresce la collaborazione, consentendo a tutti i tecnici IT e DevOps all'interno del team di modificare il codice, reagire al feedback e apportare rettifiche senza rallentare i colleghi.
Detta anche "velocità di distribuzione del software", indica la velocità di sviluppo e degli aggiornamenti (e ciò su cui le organizzazioni dovrebbero concentrarsi per migliorare il proprio processo DevOps)
Il tempo necessario affinché il software (o qualsiasi aggiornamento) inizi a generare capitale
Quanto efficacemente un'organizzazione (e le sue applicazioni) è in grado di rispondere ai cambiamenti nell'ambito del business
Secondo il report DORA 2018 Accelerate: State of DevOps (link esterno a ibm.com), le "organizzazioni d'élite" hanno implementazioni di codice 46 volte più frequenti, tempi di consegna dal commit alla distribuzione 2.555 volte più rapidi, un tasso di fallimento delle modifiche introdotte 7 volte inferiore e sono 2.604 volte più veloci nel ripristino da incidenti. È evidente il vantaggio esponenziale di distribuzioni più frequenti che comportano rilasci accelerati di nuovo software nonché risoluzioni di incidenti migliaia di volte più rapide. "Una delle mie correlazioni preferite è la riduzione del tasso di fallimento delle modifiche introdotte, anche con una distribuzione più rapida", afferma Farrell.
Quando automatizzano tutti gli otto passaggi del processo, le organizzazioni possono aspettarsi una qualità superiore e una migliore soddisfazione dei clienti. Il beneficio favorito da Farrell tuttavia è la velocità. "Ne ho visto un esempio in una banca. Per avere un'idea di un prodotto e poi lanciarlo sul mercato occorrevano circa 10-12 mesi. Con i nuovi processi DevOps, questo periodo si è ridotto a due settimane", afferma. "È possibile vedere risultati di successo diretti e assoluti sul marketplace.”