Guida DevOps: Docker, Kubernetes e Azure DevOps

In questo articolo, impareremo cos’è il DevOps e come si differenzia dalla metodologia Agile. Copriremo anche alcuni strumenti DevOps popolari e i loro ruoli nel ciclo di vita del DevOps.

Imparerai

• Cosa sono Docker, Kubernetes e Azure DevOps
• Cos’è il DevOps e perché ne abbiamo bisogno?
• In cosa differisce il DevOps dall’Agile?
• Quali sono alcuni strumenti DevOps importanti?
• Come aiuta il Docker nel DevOps?
• Come aiuta il Kubernetes nel DevOps?
• Come aiuta l’Azure DevOps nel DevOps?
• Cosa è l’Integrazione Continua e la Consegna Continua (CI/CD)?
• Cosa è l’Infrastruttura come Codice?
• Come aiutano Terraform e Ansible nel DevOps?

Docker

Docker è uno strumento software open-source utilizzato per costruire, testare e distribuire applicazioni containerizzate. Cos’è la Containerizzazione, a proposito? La Containerizzazione è il concetto di raggruppare tutte le librerie e i file insieme al codice dell’applicazione in un’unica unità chiamata “Container” in modo che possa essere eseguita su qualsiasi infrastruttura.

Kubernetes

Kubernetes è un sistema di orchestrare i contenitori che gestisce le applicazioni e i servizi containerizzati. Si occupa delle attività svolte nell’ambiente containerizzato come il ridimensionamento, il rilascio, il bilanciamento del carico, ecc. Kubernetes è portatile, efficiente ed economico, e offre funzionalità come integrazioni di sistema, supporto basato su API, ecc. 

Azure DevOps

Azure DevOps è un prodotto Microsoft che fornisce una vasta gamma di strumenti e funzionalità che rendono il processo di sviluppo e distribuzione del software più veloce e organizzato. Offre un insieme di processi che consente ai programmatori, ai project manager e ad altri collaboratori di lavorare insieme per sviluppare software. Può essere aggiunto agli editor o IDE esistenti per consentire al team di lavorare in modo efficace su progetti di qualsiasi dimensione.  

Iniziamo con un semplice caso d’uso.

Corsi Gratuiti — Impara in 10 Passaggi

• Impara Docker in 10 Passaggi
• Impara Kubernetes in 10 Passaggi
• Impara AWS in 10 Passaggi

Cos’è DevOps?

Come con la maggior parte delle parole di moda nello sviluppo software, non esiste una definizione accettata per DevOps.

Le definizioni variano da semplici, come quella di seguito, a complesse, che possono occupare l’intera pagina di un libro.

DevOps è la combinazione di filosofie culturali, pratiche e strumenti che aumentano la capacità di un’organizzazione di consegnare applicazioni e servizi ad alta velocità — Amazon Web Services (AWS)

Invece di cercare di definire DevOps, cerchiamo di capire come lo sviluppo software è evoluto verso DevOps.

Modello a cascata

Il Modello a cascata è una metodologia che segue un approccio strutturato. È composto da sei fasi: Requisiti, Progettazione, Implementazione, Test, Distribuzione e Manutenzione. Ogni fase si basa sul completamento della precedente. Progredisce attraverso queste fasi senza riprendere i processi precedenti, rendendolo un processo lineare.

I primi decenni dello sviluppo software erano incentrati sul modello a cascata, e affrontavano lo sviluppo software allo stesso modo in cui ci si avvicina alla costruzione di un progetto immobiliare — ad esempio, la costruzione di un ponte.

Si svilupperà il software in più fasi che possono durare da poche settimane a alcuni mesi.

Nella maggior parte dei progetti a cascata, passerebbero mesi prima che l’azienda vedesse una versione funzionante di un’applicazione.

Elementi chiave per costruire un ottimo software

Mentre lavoravamo nel modello a cascata per alcuni decenni, abbiamo compreso alcuni elementi chiave nello sviluppo di ottimi software:

• Comunicazione
• Feedback
• Automazione

Importanza della Comunicazione

La comunicazione tra le persone è essenziale per il successo di un progetto software.

Nel modello a cascata, abbiamo cercato di potenziare la comunicazione preparando documenti di 1000 pagine su Requisiti, Design, Architettura e Implementazione.

Ma, nel tempo, abbiamo scoperto che:

• Il modo migliore per potenziare la comunicazione all’interno di un team è riunirli. E avere una varietà di competenze nello stesso team.
• Team cross-funzionali — con una vasta gamma di competenze — funzionano alla grande.

Importanza del Feedback Precoce

Ricevere feedback rapidamente è importante. Costruire ottimi software significa ottenere feedback veloci.

• Stiamo costruendo un’applicazione che soddisfi le aspettative del business?
• Il tuo software avrà problemi se viene implementato in produzione?

Non vuoi saperlo dopo alcuni mesi. Vuoi scoprirlo il prima possibile perché più presto individuiamo un problema, più facile sarà correggerlo.

Abbiamo scoperto che i migliori team software sono strutturati per consentire un feedback rapido.

Importanza dell’Automazione

L’automazione è fondamentale. Lo sviluppo software coinvolge una vasta gamma di attività. Fare le cose manualmente è lento e soggetto a errori. Comprendiamo che è essenziale cercare sempre opportunità per introdurre l’automazione.

Avendo compreso gli elementi chiave per sviluppare ottimi software, vediamo come siamo evoluti verso Agile e DevOps.

Evoluzione verso Agile

Agile è un approccio che enfatizza il progresso incrementale, il feedback frequente e la capacità di rispondere ai requisiti in evoluzione attraverso il ciclo di sviluppo. Agile promuove team interfunzionali che lavorano in brevi cicli di sviluppo, incoraggiando il miglioramento continuo e offrendo valore agli utenti finali rapidamente. È stato il primo passo nell’evoluzione verso l’implementazione delle nostre conoscenze con una comunicazione migliorata tra i team, ottenendo feedback e introducendo l’automazione. 

Agile ha unito i team aziendali e di sviluppo in un unico team, che lavora per costruire ottimi software in piccole iterazioni chiamate Sprint.

Invece di passare settimane o mesi su ciascuna fase di sviluppo, Agile si concentra sul portare piccoli requisiti chiamati storie utente attraverso il ciclo di sviluppo entro pochi giorni, a volte entro lo stesso giorno.

Come ha potenziato Agile la comunicazione tra i team?

Agile ha unito i team aziendali e di sviluppo.

• Le aziende sono responsabili della definizione di cosa costruire. Quali sono i requisiti?
• Lo sviluppo è responsabile della costruzione di un prodotto che soddisfi i requisiti. Lo sviluppo include tutti coloro coinvolti nella progettazione, codifica, test e confezionamento del software.

Nel metodo Agile, un rappresentante dell’azienda, chiamato Product Owner, è sempre presente con il team, e il team comprende chiaramente gli obiettivi aziendali.

Quando il team di sviluppo non comprende i requisiti e sta prendendo una direzione sbagliata, il Product Owner li aiuta a correggere il tiro e a rimanere sulla strada giusta.

Risultato: Il prodotto finale che il team costruisce è ciò che l’azienda desidera.

Un altro fattore importante è che i team agili hanno competenze trasversali: competenze di codifica (frontend, API e basi di dati), competenze di testing e competenze aziendali. Questo migliora la comunicazione tra le persone che devono lavorare insieme per costruire ottimi software.

Agile e Automazione

Su quali aree di automazione si concentrano i team agili?

I prodotti software possono presentare una varietà di difetti:

• I difetti funzionali significano che il prodotto non funziona come previsto.
• I difetti tecnici rendono la manutenzione del software difficile. Ad esempio, problemi di qualità del codice.

In generale, i team agili sono concentrati sull’utilizzo dell’automazione per individuare i difetti tecnici e funzionali il prima possibile.

I team agili si concentrano anche ampiamente sulla qualità del codice. Strumenti come SONAR sono utilizzati per valutare la qualità del codice delle applicazioni.

È sufficiente avere ottimi test di automazione e ottime verifiche della qualità del codice? La chiave è eseguire questi processi frequentemente. I team Agile enfatizzano l’Integrazione Continua, dove i commit nel controllo versione attivano una serie di azioni. Questo include l’esecuzione di Test Unitari, Test di Automazione e Verifiche della Qualità del Codice, tutti integrati senza soluzione di continuità in un Pipeline di Integrazione Continua. Jenkins, uno strumento CI/CD ampiamente adottato durante i primi anni dell’Agile, ha svolto un ruolo fondamentale nell’orchestrare questi processi automatizzati.

Come ha promosso Agile il feedback immediato?

Il fattore più importante è che un’azienda non deve aspettare mesi per vedere il prodotto finale. Alla fine di ogni sprint, il prodotto viene presentato a tutti gli stakeholder, inclusi i team di architettura e business. Tutti i feedback vengono raccolti mentre si dà priorità alle storie degli utenti per il prossimo sprint. Risultato: il prodotto finale che il team costruisce è qualcosa che l’azienda desidera.

Un altro fattore importante che consente un feedback immediato è l’integrazione continua. Supponiamo che io faccia un commit di codice nel controllo versione. Entro 30 minuti, ricevo feedback se il mio codice provoca un fallimento di un test unitario o di un test di integrazione. Riceverò feedback se il mio codice non soddisfa gli standard di qualità del codice o non ha una copertura di codice sufficiente nei test unitari.

L’Agile è stato un successo? Sì. Di sicuro. Concentrandosi sul miglioramento della comunicazione tra i team di business e sviluppo, e focalizzandosi nel trovare una varietà di difetti precocemente, l’Agile ha portato lo sviluppo software a un livello superiore.

Ho avuto un’esperienza meravigliosa lavorando con alcuni team straordinari utilizzando Agile. L’ingegneria del software, che per me rappresenta tutti gli sforzi per costruire software dai requisiti fino al lancio delle applicazioni, per la prima volta, è stata tanto piacevole quanto la programmazione.

Ma l’evoluzione si ferma? No.

Nuove sfide sono emerse.

Evoluzione delle Architetture a Microservizi

Abbiamo iniziato a muoverci verso un architettura a microservizi e abbiamo iniziato a costruire diverse piccole API invece di costruire grandi applicazioni monolitiche.

Qual è stata la nuova sfida?

Le operazioni sono diventate più importanti. Invece di fare un rilascio monolitico al mese, si stanno facendo centinaia di piccoli rilasci di microservizi ogni settimana. Risolvere problemi tra microservizi e ottenere visibilità su ciò che sta accadendo con i microservizi è diventato importante.

Era tempo di una nuova parola d’ordine nello sviluppo software. DevOps.

Emergenza di DevOps

Qual era l’obiettivo di DevOps?

L’obiettivo di DevOps era migliorare la comunicazione tra i team di sviluppo e quelli operativi.

• Come possiamo rendere più facili i rilasci?
• Come possiamo rendere il lavoro del team operativo più visibile al team di sviluppo?

Come ha migliorato DevOps la comunicazione tra i team?

DevOps ha avvicinato i team operativi ai team di sviluppo.

• Nelle imprese più mature, i team di sviluppo e operazioni hanno lavorato come un’unica squadra. Hanno iniziato a condividere obiettivi comuni e entrambi i team hanno iniziato a comprendere le sfide che l’altro team affrontava.
• Nelle imprese, nelle fasi iniziali dell’evoluzione di DevOps, un rappresentante del team delle operazioni può essere coinvolto negli sprint – standup e retrospettive.

Su quali aree di automazione si concentrano i team DevOps?

Oltre alle aree di focus di Agile – Integrazione continua e automazione dei test – i team DevOps si concentravano sull’aiutare ad automatizzare diverse attività del team delle operazioni come la fornitura di server, la configurazione del software sui server, il rilascio delle applicazioni e il monitoraggio degli ambienti di produzione. Alcuni termini chiave sono rilascio continuo, consegna continua e infrastruttura come codice.

Il rilascio continuo riguarda il rilascio continuo di una nuova versione del software negli ambienti di test. In organizzazioni ancora più mature come Google e Facebook, la consegna continua aiuta a rilasciare continuamente il software in produzione – forse centinaia di rilasci in produzione al giorno.

Infrastruttura come codice riguarda il trattare la propria infrastruttura come si tratta il codice dell’applicazione. Si crea la propria infrastruttura – server, bilanciatori di carico e database – in modo automatizzato utilizzando la configurazione. Si tiene traccia delle modifiche alla propria infrastruttura mediante il controllo di versione – in modo da poter monitorare le modifiche alla propria infrastruttura nel tempo.

Come ha promosso DevOps il feedback immediato?

DevOps unisce i team di operazioni e sviluppo. Poiché le operazioni e lo sviluppo fanno parte dello stesso team, l’intero team comprende le sfide associate alle operazioni e allo sviluppo.

• Eventuali problemi operativi ricevono prontamente attenzione da parte degli sviluppatori.
• Qualsiasi sfida nel portare il software online ottiene l’attenzione anticipata del team delle operazioni.

DevOps incoraggia l’integrazione continua, la distribuzione continua e l’infrastruttura come codice.

• Grazie alla distribuzione continua, se apporto una modifica al codice o una configurazione che potrebbe compromettere un test o un ambiente di staging, lo saprei entro poche ore.
• Grazie a Infrastructure as Code, gli sviluppatori possono auto-provisionare ambienti, distribuire codice e risolvere problemi da soli senza l’aiuto del team delle operazioni.

Vedo Agile e DevOps come due fasi che ci aiutano a migliorare il modo in cui costruiamo ottimi software. Non sono in competizione tra loro, ma insieme ci aiutano a creare prodotti software straordinari.

Per quanto mi riguarda, l’obiettivo di Agile e DevOps insieme è fare cose che:

• Promuovono la comunicazione e il feedback tra business, sviluppo e team delle operazioni
• Alleviano i punti critici con l’automazione. 

Una storia di DevOps

Ecco un esempio di storia:

• Sei lo sviluppatore principale in un team e devi apportare una correzione rapida. 
• Vai in un repository GitHub.
• Fai rapidamente il checkout del progetto.
• Crei rapidamente il tuo ambiente locale.
• Fai una modifica. Lo testi. Aggiorni le unità e i test di automazione.
• Committi.
• Ricevi una email che conferma il rilascio in QA.
• Vengono eseguiti automaticamente alcuni test di integrazione.
• Il tuo team di QA riceve una email che chiede l’approvazione. Fanno un test manuale e approvano.
• Il tuo codice è in produzione in pochi minuti.
• Potresti pensare che questa sia una situazione ideale. Ma, sai che questo è ciò che accade nelle imprese innovative come Netflix, Amazon e Google giorno dopo giorno?

Questa è la storia di DevOps.

DevOps = Sviluppo + Operazioni

DevOps è una naturale evoluzione dello sviluppo software. DevOps NON È SOLO uno strumento, un framework o solo automazione. È una combinazione di tutti questi elementi.

DevOps si concentra sulle persone, sui processi e sui prodotti. La parte delle persone di DevOps riguarda la cultura e la creazione di una mentalità positiva – una cultura che promuove la comunicazione aperta e valorizza un feedback rapido, una cultura che apprezza il software di alta qualità.

Agile ha contribuito a colmare il divario tra le aziende e i team di sviluppo. I team di sviluppo hanno compreso le priorità dell’azienda e hanno collaborato con l’azienda per consegnare le storie che forniscono il maggior valore per primi; tuttavia, i team di sviluppo e operazioni non erano allineati.

Avevano obiettivi diversi.

• L’obiettivo del team di sviluppo è portare in produzione il maggior numero possibile di nuove funzionalità.
• L’obiettivo del team ops era mantenere l’ambiente di produzione il più stabile possibile.

Come puoi vedere, se portare le cose in produzione è difficile, lo sviluppo e le operazioni non sono allineati.

DevOps mira ad allineare i team di sviluppo e operazioni con obiettivi condivisi.

Il team di sviluppo collabora con il team di operazioni per capire e risolvere le sfide operative. Il team di operazioni fa parte del team scrum e comprende le funzionalità in fase di sviluppo.

Come possiamo rendere questo possibile? Abbattere il muro tra sviluppo e operazioni!

Unire Dev e Ops

Opzione 1

Nelle aziende DevOps mature, lo sviluppo e le operazioni lavorano come parte dello stesso team scrum e condividono le responsabilità reciproche.

Opzione 2

Tuttavia, se ti trovi nelle fasi iniziali dell’evoluzione DevOps, come puoi fare in modo che sviluppo e operazioni abbiano obiettivi comuni e lavorino insieme?

Ecco alcune cose che puoi fare:

• Fai in modo che il team di sviluppo condivida alcune responsabilità del team di operazioni. Ad esempio, il team di sviluppo può assumersi la responsabilità dei nuovi rilasci per la prima settimana dopo il rilascio in produzione. Questo aiuta il team di sviluppo a comprendere le sfide affrontate dalle operazioni nel portare i nuovi rilasci online e li aiuta a unirsi e trovare soluzioni migliori.
• Un’altra cosa che puoi fare è coinvolgere un rappresentante del team di operazioni nelle attività scrum. Coinvolgerli nelle standup e nelle retrospettive.
• La prossima cosa che puoi fare è rendere più visibili le sfide affrontate dal team delle Operazioni al team di Sviluppo. Quando affronti delle sfide nelle operazioni, fai in modo che i team di sviluppo facciano parte dei gruppi che lavorano sulle soluzioni.

Qualunque sia la strada che scegli, trova modi per abbattere il muro e mettere insieme i team di sviluppo e operazioni.

Un’altra opzione interessante emerge grazie all’automazione. Utilizzando l’Infrastructure as Code e abilitando l’auto-provisioning per gli sviluppatori, puoi creare un linguaggio comune che i team di operazioni e sviluppo comprendono: il codice.

Un caso d’uso DevOps

Considera l’immagine qui sotto:

Questa immagine mostra due semplici flussi di lavoro

1. Infrastructure as Code utilizzando Terraform e Azure DevOps per fornire cluster Kubernetes.
2. Distribuzione continua di microservizi utilizzando Azure DevOps per costruire e distribuire immagini Docker per microservizi nei cluster Kubernetes.

Ti sembra complesso?

Spezzettiamolo e cerchiamo di capirlo.

Iniziamo con #2 — Distribuzione Continua prima.

#2: Distribuzione Continua DevOps con Azure DevOps e Jenkins

Qual è l’uso di avere ottimi test e controlli di qualità del codice se non li esegui spesso?

Qual è l’uso dell’automazione della distribuzione se non distribuisci software abbastanza spesso?

Non appena uno sviluppatore impegna il codice nel sistema di controllo versione, vengono eseguiti i seguenti passaggi:

• Test di Unità
• Controlli di Qualità del Codice
• Test di Integrazione
• Confezionamento dell’applicazione — Creazione di una versione deployabile dell’applicazione. Strumenti — Maven, Gradle, Docker
• Deployment dell’applicazione — Mettere in produzione nuove applicazioni o nuove versioni dell’applicazione
• Un’email al team di testing per testare l’applicazione

Appena c’è l’approvazione del team di testing, l’applicazione viene immediatamente deployata nell’ambiente successivo

Questo è chiamato deployment continuo. Se si effettua il deployment continuo fino alla produzione, si chiama delivery continua

Gli strumenti CI/CD più popolari sono Azure DevOps e Jenkins

#1: Infrastruttura DevOps come Codice con Terraform

Un tempo, creavamo ambienti e deployavamo applicazioni manualmente

Ogni volta che crei un server, questo deve essere fatto manualmente

• La versione del software deve essere aggiornata
• Le patch di sicurezza devono essere installate manualmente

Lo fai manualmente e i seguenti sono i risultati

• Alta probabilità di errori
• Gli ambienti di replica sono difficili

Infrastruttura come Codice

Infrastruttura come Codice — tratta l’infrastruttura allo stesso modo del codice dell’applicazione

Ecco alcune delle cose importanti da capire con l’Infrastruttura come Codice

• Il team di infrastruttura si concentra sul lavoro a valore aggiunto (anziché sul lavoro di routine)
• Meno errori e rapido recupero dai fallimenti
• I server sono consistenti (evita la deriva della configurazione)

Gli strumenti IaC più popolari sono Ansible e Terraform.

Tipicamente questi sono i passaggi nell’IaC:

• Provisione dei server (abilitata dal cloud) da un modello
• Installazione del software
• Configurazione del software

Provisioning del server

Di solito vengono utilizzati strumenti di provisioning per provvedere ai server e preparare il nuovo server con le capacità di rete. Gli strumenti di provisioning più popolari sono Cloud Formation e Terraform.

Utilizzando Terraform, puoi provvedere ai server e al resto della tua infrastruttura, come bilanciatori di carico, database, configurazioni di rete, ecc. Puoi creare server utilizzando immagini pre-create create con strumenti come Packer e AMI (Amazon Machine Image).

Gestione della configurazione

Gli strumenti di gestione della configurazione sono utilizzati per:

• Installare software
• Configurare software

Gli strumenti di gestione della configurazione più popolari sono Chef, Puppet, Ansible e SaltStack. Sono progettati per installare e gestire software su server esistenti.

Ruolo di Docker e Kubernetes in DevOps

Nel mondo dei microservizi, alcuni microservizi potrebbero essere sviluppati in Java, alcuni in Python e alcuni in JavaScript.

Diversi microservizi avranno modi diversi di sviluppare applicazioni e distribuirle sui server. Questo rende difficile il lavoro del team delle operazioni. Come possiamo avere un modo simile di distribuire vari tipi di applicazioni? Entrano in gioco i container e Docker.

Utilizzando Docker, puoi creare immagini di microservizi – indipendentemente dal linguaggio. Puoi eseguire queste immagini allo stesso modo su qualsiasi infrastruttura. Questo semplifica le operazioni.

Kubernetes si aggiunge a questo aiutando a orchestrare diversi tipi di container e distribuirli in cluster.

Kubernetes fornisce anche:

• Discovery del servizio
• Bilanciamento del carico
• Configurazione centralizzata

Docker e Kubernetes rendono facile il DevOps.

Metriche importanti del DevOps

Le seguenti sono alcune delle metriche importanti del DevOps che puoi monitorare e migliorare nel tempo.

• Frequenza di distribuzione — Con quale frequenza vengono distribuite le applicazioni in produzione?
• Tempo di commercializzazione — Di quanto tempo hai bisogno per portare una funzionalità dalla codifica alla produzione?
• Tasso di fallimento delle nuove versioni — Quante delle tue versioni falliscono?
• Tempo di risoluzione — Di quanto tempo hai bisogno per apportare una correzione in produzione e rilasciarla in produzione?
• Tempo medio di ripristino — Di quanto tempo hai bisogno per ripristinare il tuo ambiente di produzione da un problema importante?

Pratiche migliori del DevOps

Gestione del progetto Agile

La gestione del progetto Agile è un approccio iterativo allo sviluppo di applicazioni software. Attraverso questa pratica, i team possono migliorare la velocità di sviluppo e rispondere bene alle diverse esigenze dei clienti. La metodologia Agile è diversa dal tradizionale metodo Waterfall in cui c’erano lunghi cicli di rilascio. Agile utilizza i framework Scrum e Kanban per consegnare il software secondo le esigenze del cliente.

Utilizzare il giusto set di strumenti

I developer di software e gli amministratori di sistema devono scegliere e utilizzare il giusto set di strumenti DevOps in ciascuna fase del ciclo di vita DevOps per costruire applicazioni di alto valore.

Ecco alcuni esempi di strumenti che ingegneri DevOps, amministratori di sistema e altre parti interessate possono utilizzare:

1. Strumenti come Jira possono aiutare il team a suddividere i compiti in pezzi più piccoli e gestibili, aumentando così la produttività del team.
2. Strumenti come Jenkins e Bitbucket possono aiutarti ad automatizzare i flussi di codice dall fase di testing a quella di distribuzione.
3. Strumenti come Slack, GetFeedback, ecc. possono aiutare i team DevOps ad integrare strumenti di chat con piattaforme di sondaggi per raccogliere e valutare feedback in tempo reale.

Integrazione Continua/Consegna Continua

l’Integrazione Continua (CI) e la Consegna Continua (CD) sono pratiche moderne di sviluppo software che aiutano le organizzazioni a consegnare rapidamente ed efficacemente software. Con CI, i developer commettono continuamente il codice dell’applicazione in un repository condiviso diverse volte. Con la CD, il codice viene consegnato in produzione in modo rapido e senza intoppi. La CD garantisce inoltre che l’integrazione avvenga senza ritardi o problemi.

Integrazione della Sicurezza

La sicurezza è una parte importante del processo di sviluppo software. Nel mondo attuale, dove i crimini informatici e gli incidenti di violazione dei dati sono in aumento, le organizzazioni stanno comprendendo l’importanza di integrare la sicurezza nei loro sistemi. In passato, la sicurezza veniva generalmente considerata nelle ultime fasi del ciclo di vita dello sviluppo del software, ma con l’avvento del DevSecOps, la sicurezza viene considerata e integrata fin dal primo giorno dello sviluppo dell’applicazione.

L’osservabilità è importante nello sviluppo di applicazioni complesse che utilizzano architetture a microservizi e cloud. L’osservabilità aiuta i team DevOps a comprendere la struttura complessa delle diverse applicazioni (microservizi, app cloud, ecc.) e ad affrontare le future esigenze dell’ambiente. Kubernetes e Splunk sono alcune delle migliori piattaforme di osservabilità.

Come si misura la maturità delle implementazioni DevOps?

• Il tempo impiegato dal processo di sviluppo al rilascio dovrebbe essere complessivamente soddisfacente
• La determinazione della frequenza di rilascio del nuovo codice
• Il Tempo Medio per il Recupero (MTTR) da un incidente o evento imprevisto dovrebbe essere il più basso possibile
• I rilasci di successo dovrebbero superare i rilasci falliti
• Rilasci più rapidi e affidabili dovrebbero generare un alto ritorno sugli investimenti (ROI).

Pratiche migliori per la trasformazione DevOps

• Il coinvolgimento della leadership è fondamentale
• Comporta costi iniziali
• Imposta i COE per aiutare i team
• Scegli l’applicazione e il team giusti
• Inizia in piccolo
• Condivisione delle esperienze (newsletter, comunicazione, COE)
• Incoraggia le persone con una mentalità di esplorazione e automazione
• Riconosci i team DevOps