DevOps e l’ascesa del Cloud

Le nuove frontiere di DevOps e l’ascesa del Cloud

Sono trascorsi più di dieci anni da quando Patrick Debois ha coniato il termine DevOps, nel 2009. Nel mondo IT, nulla è definitivo: tutte le tecnologie e le tecniche continuano ad evolversi seguendo una tendenza di innovazione che non possiamo fermare.

Non possiamo semplicemente dire: “Sono stanco di cambiare; per favore fammi riposare.”

L’unica opzione è essere sempre pronti al cambiamento.

In DevOps c’è un cambiamento significativo a causa dell’ascesa del cloud e di un mercato sempre più impegnativo.

La filosofia DevOps è stata adottata dalla maggior parte delle aziende e apporta miglioramenti essenziali alla qualità e al risparmio sui costi. Ad ogni modo, lo scenario DevOps è in continua evoluzione e adattamento alle nuove esigenze del mercato.

In questo articolo, analizzeremo le nuove frontiere di DevOps, andando ad evidenziare le cose da sapere per stare al passo con i tempi.

Vediamo in questo articolo quali sono le ultime tendenze da seguire.

La crescita di DevOps

DevOps, in poche parole, è l’integrazione di Sviluppo (Dev) e Operazione (Ops), creando un processo cooperativo.

Secondo IDC, il mercato DevOps raggiungerà $ 8 miliardi entro il 2022 e un altro rapporto di Grand View Research parla di circa $ 13 miliardi entro il 2025.

Ciò indica un interesse molto crescente in questo argomento da parte delle aziende.

Un altro driver che contribuisce a questo cambiamento è la crescita del cloud.

Secondo le previsioni di Oracle, entro il 2025 l’80% delle soluzioni IT passerà al cloud.

Da quando è stato coniato il concetto DevOps, le pratiche DevOps non hanno mai smesso di evolversi, supportate da strumenti sempre più potenti.

Ciò dovrebbe rappresentare un motivo in più per leggere i prossimi capitoli e far parte di questa evoluzione.

Integrare la sicurezza nel processo DevOps

La sicurezza è sempre stata importante, ma con il crescente utilizzo del servizio digitale e la memorizzazione di dati sensibili (biometrici, foto, ecc.), è diventata fondamentale.

Gli utenti hanno iniziato a chiedere dove vengono tenuti i loro dati e come sono gestiti.

Il nostro cliente si aspetta che proteggiamo le sue informazioni: non possiamo fallire.

A proposito, l’utente è sempre più esigente e dobbiamo supportare processi agili per rispondere al cambiamento.

Non possiamo permettere che arrivi la situazione in cui finiamo un progetto o una caratteristica significativa, che poi deve essere inviata a SecOps.

Il nostro progetto potrebbe essere interrotto da SecOps per una settimana o, peggio ancora, respinto. Non possiamo semplicemente rifare tutto il lavoro perché alcuni “piccoli” dettagli di sicurezza sono stati ignorati dagli sviluppatori.

Non è solo una questione di costi, si tratta più di tempo: il marketing non aspetta i tuoi problemi interni e i clienti acquisteranno tale funzione da un altro fornitore.

Ecco perché, per i progetti critici, dobbiamo integrare DevOps con SecOps, coinvolgendo gli addetti alla sicurezza sin dall’inizio.

Iniziare a tenere conto dei requisiti di sicurezza sin dall’inizio e coinvolgere i team di sicurezza aiuta a prevenire situazioni difficili e attriti durante il rilascio.

Questo problema è più cruciale nel caso in cui si abbia un processo NoOps.

NoOps porta più automazione e potresti trovarti in una situazione in cui il codice non attendibile raggiunge la produzione senza la giusta supervisione.

Questa situazione può essere risolta includendo e automatizzando i test di sicurezza durante la pipeline (o la catena di montaggio, come leggeremo nei paragrafi seguenti).

Non vogliamo finire sul giornale per una violazione della sicurezza, giusto?

Bene, abbiamo bisogno di un modo per integrare l’agilità con la sicurezza; questo è supportato dalla filosofia DevSecOps.

NoOPS

NoOps significa nessuna operazione.

La diffusione della soluzione serverless e le nuove frontiere dell’automazione rendono possibile il sogno di NoOps.

La sua filosofia è quella di rimuovere tutte le parti di gestione della piattaforma e ridurre l’attrito tra sviluppatori e infrastruttura.

Come spiego nell’articolo “DevOps is Dead, Long Live NoOps” pubblicato su Better Programming, il passo avanti rispetto a DevOps è:

“DevOps […] significa che hai sempre bisogno di un po ‘di sforzo manuale. Hai ancora una persona dietro la maggior parte delle parti del processo. Questo significa lavorare alla vecchia maniera.”

Lo scopo di NoOps è definire un nuovo tipo di processo, in cui non è necessario combinare Dev e Ops perché la maggior parte delle attività sono automatizzate.

I vantaggi sono:

• velocità sul mercato,
• migliore qualità,
• meno sforzi per la manutenzione.

Questo è molto interessante. Possiamo essere d’accordo con i principi alla base di tutto ciò, ma dobbiamo essere consapevoli dell’altro lato della storia: monitoraggio e sicurezza.

Con un sistema completamente automatizzato in cui tutto è guidato dal codice, chi si occuperà di questi passaggi?

La soluzione al problema è di nuovo l’automazione.

È necessario implementare l’automazione su ogni parte non più coperta da protezione umana, monitoraggio e sicurezza inclusa.

Questo converge nella direzione DevSecOps.

Passare dalle pipelines alle linee di assemblaggio

Quando DevOps è stato coniato nel 2009, probabilmente, lo scenario tipico era un’applicazione web monolitica.

Era il momento in cui il modello MVC era rivoluzionario, e mi sembra di parlare di secoli fa.

Oggi la situazione è leggermente diversa: nel caso più semplice, abbiamo due applicazioni (frontend SPA e API backend).

Spesso si evolvono in modo diverso e sono gestiti da team diversi.

Probabilmente, sceglieremo un’architettura a microservizi per il nostro prossimo progetto. Ciò significa che molte applicazioni dovranno essere distribuite.

Il nostro approccio alla pipeline sembra piuttosto limitante. Il modello di pipeline è perfetto per i seguenti modelli lineari (commit> compile> test> deploy) in cui il progetto è facile da rappresentare con un semplice flusso. Vediamo un esempio.

L’approccio tradizionale pipeline

Nel diagramma, vediamo il codice approvato da una richiesta pull che arriva allo strumento CI \ CD, compilato e testato. In caso di errore durante la fase di build to test, il problema segue l’escalation corretta da risolvere prima della distribuzione.

Questo approccio può ancora essere adatto per la maggior parte dei progetti, ma in molte situazioni può essere limitante. Il nuovo approccio è un’analogia con l’industria e si chiama “pipeline di assemblaggio“.

Come nella pipeline di assemblaggio fisico, ogni reparto fornisce il proprio contributo, aggiungendo “un pezzo” al prodotto.

Usando questo approccio, tutte le persone che prendono parte a questo processo sono coinvolte fin dall’inizio, e c’è un flusso chiaro fin dall’inizio. In questo modo, molti team possono cooperare e gestire scenari complessi con dipendenze multiple (da applicazioni, sicurezza, ecc.).

Un esempio di cooperazione in una catena di montaggio

Le linee di assemblaggio sono una risposta alla frammentazione di DevOps in scenari complessi e hanno bisogno di una collaborazione culturale come colla per tenere insieme tutti i pezzi. Inoltre, abbiamo anche bisogno di un “super strumento” che gestisca tutte queste interazioni.

Basandoci sull’analogia dell’industria, la chiamiamo Assembly Island. Purtroppo però, i più comuni strumenti CI \ CD non supportano questo approccio e dovrai quindi abbinarli a una serie di strumenti.

Tutto come un codice

Niente è meglio del codice sorgente: è versionabile, può essere copiato e incollato, può essere inviato via e-mail e, se eseguito due volte, si ottiene lo stesso risultato, o quasi, questo è ciò che ci aspettiamo da un buon codice.

Le cose di sysadmin non sono le stesse. Non è possibile tagliare e incollare un data center e inviarlo via e-mail, giusto?

La buona notizia è che la tua infrastruttura può essere come il codice sorgente.

Abbiamo già introdotto soluzioni come Ansible, Terraform o altri framework di automazione. Siamo in grado di eseguire la versione dei nostri script e automatizzare la gestione dell’infrastruttura.

Inoltre, la descrizione dichiarativa dell’infrastruttura come in Kubernetes è un eccellente aiuto per capire come funzionano le cose senza leggere tonnellate di documenti o comprendere la configurazione del server grazie alla ingegnerizzazione dei file di configurazione.

L’automazione dall’inizio del processo aiuta ad avviarsi nel modo giusto e ci fornisce un’infrastruttura replicabile, che è di grande aiuto per migliaia o motivi (basta pensare al ripristino di emergenza o semplicemente creare un nuovo ambiente per testare una singola funzionalità).

L’asporto

DevOps è un argomento in continua crescita. Molte cose sono già state scritte; dobbiamo evolvere le nostre competenze per allinearle alle tendenze. Le parole chiave più importanti in questa modifica sono:

• Cloud
• Automazione
• Pipeline di assemblaggio
• NoOps

La maggior parte di queste hanno lo stesso obiettivo: utilizzare le tecnologie per migliorare il processo di qualità.

Il cambiamento può essere realizzato automatizzando le attività umane, integrando la sicurezza e il monitoraggio all’interno del processo e utilizzando il cloud per accelerare il tutto.

Com’è possibile?

Abbiamo bisogno di uno strumento o di una serie di strumenti che supportino tutte le operazioni e che gestiscano la cooperazione delle persone ma, come sempre, cambiare mentalità è il primo passo.