5 differenze di base tra DevOps e SRE che dovresti conoscere
Pubblicato: 2021-02-22Il mondo dell'Information Technology e dello sviluppo software spesso confonde DevOps con SRE per significare la stessa cosa. Tuttavia, ci sono grandi differenze tra i due. Mentre Site Reliability Engineering (SRE) ha guadagnato terreno negli ultimi anni, DevOps esiste da molto più tempo (anche prima che esistesse il termine DevOps).
Per dirla semplicemente, DevOps e SRE sono entrambe pratiche messe in atto per fornire software più velocemente. L'unica differenza tra i due è nei loro approcci; DevOps si concentra sulla riduzione del ciclo di vita dello sviluppo del software e SRE si concentra sull'eliminazione dei punti deboli del sistema per raggiungere lo stesso scopo.
In questo articolo, esamineremo i modi fondamentali in cui DevOps e SRE differiscono l'uno dall'altro. Prima di farlo, iniziamo con la comprensione di cosa sono DevOps e SRE.
Sommario
Cos'è DevOps?
Nelle parole di Gene Kim, autore di The DevOps Handbook e The Phoenix Project,
“DevOps è [l'insieme] di norme culturali e pratiche tecnologiche che [consente] il rapido flusso del lavoro pianificato, tra l'altro, dallo sviluppo, attraverso i test nelle operazioni, preservando al contempo affidabilità, funzionamento e sicurezza di livello mondiale. DevOps non riguarda ciò che fai, ma quali sono i tuoi risultati".
Quindi, DevOps si concentra principalmente sulla trasformazione delle pratiche culturali all'interno di un'organizzazione per accelerare il ciclo di vita dello sviluppo del software (SDLC). Non è mirato a una persona, un gruppo o una posizione. DevOps mira a rafforzare la collaborazione tra le operazioni di Information Technology e i team di sviluppo software.
Cosa fa e come lo fa non è importante; solo l'esito del processo è riconosciuto.
DevOps utilizza una serie di principi per intensificare l'esposizione dei team di ingegneria del software ai sistemi di produzione e consente al team delle operazioni IT di inoltrare le discrepanze al team di sviluppo in modo più efficiente. In effetti, SRE svolge un ruolo cruciale in un'organizzazione DevOps facilitando test proattivi, velocità, consentendo l'osservabilità e migliorando l'affidabilità del servizio. DevOps incoraggia ogni organizzazione incentrata su DevOps a operare secondo i principi culturali delineati nel suo modello CALMS.
Cos'è l'SRE?
SRE, abbreviazione di Site Reliability Engineering, è un termine coniato dal vicepresidente senior di Google Ben Treynor incaricato della supervisione delle operazioni tecniche.
Drew Farnsworth (di Green Lane Design) spiega: “In genere mi piace pensare all'SRE come a un sistema in cui lo sviluppo controlla le operazioni. Si tratta di un sistema in cui l'ambiente è suddiviso nei componenti più basilari dello stack IT e implementato con le migliori pratiche integrate nell'hardware".
In sostanza, il team di SRE con esperienza nello sviluppo di software ha il compito di risolvere i problemi nella produzione del sistema mantenendo un equilibrio tra velocità di consegna e affidabilità del sistema. In questo modo, l'approccio SRE riunisce il personale di sviluppo software con ruoli operativi per applicare pratiche ingegneristiche strutturate per sostenere le politiche di un'organizzazione.
Garantiscono che i sistemi siano disponibili e funzionino in modo efficiente in ogni momento affinché i team software sviluppino servizi tecnici per aumentare l'affidabilità del sistema. È responsabilità di SRE identificare qualsiasi potenziale debolezza prima che si trasformi in un problema importante.
DevOps vs SRE: le principali differenze tra DevOps e SRE
In pratica, DevOps e SRE dovrebbero essere visti come discipline complementari in cui gli SRE come parte di una struttura incentrata su DevOps sono focalizzati sul miglioramento dell'affidabilità dei loro servizi tecnici. Quindi, essenzialmente non esiste un DevOps contro SRE.
Pertanto, ciò che stiamo facendo in questa sezione è valutare le differenze fondamentali tra DevOps e SRE.
Implementazione del cambiamento
Affinché gli aggiornamenti avvengano frequentemente e gli utenti abbiano accesso a tecnologie più recenti e pertinenti, sia DevOps che SRE intendono procedere rapidamente. Tuttavia, DevOps procede gradualmente, con cautela, mentre SRE tiene conto del costo della mancata accelerazione.
Entrambi implementano l'automazione e utilizzano strumenti per raggiungere questo scopo.
Considerare i fallimenti come normali
DevOps è enorme nell'accettare i fallimenti e considerarli come un'oppressione dell'apprendimento. Per questo motivo, incoraggia una cultura irreprensibile accettando che i guasti siano una parte del processo e non si concentra sul rendere i sistemi tolleranti ai guasti al 100%. Un esempio di questo è Netflix con il suo Simian Army.
SRE, d'altra parte, sostiene l'autopsia irreprensibile. Lo scopo alla base di ciò è identificare la causa del fallimento, assegnare responsabilità e lavorare per evitare fallimenti simili in futuro. Quanti guasti può subire un sistema è incluso nel budget degli errori. Le metriche SLI, SLO e SLA determinano questo per ridurre i costi di produzione. Fondamentalmente, SRE adotta pratiche di monitoraggio e avviso proattivo per evitare un potenziale guasto.
Impara i corsi di sviluppo software online dalle migliori università del mondo. Guadagna programmi Executive PG, programmi di certificazione avanzati o programmi di master per accelerare la tua carriera.
Automazione vs innovazione
DevOps attribuisce la massima importanza all'automazione. In un ambiente incentrato su DevOps, questo si traduce in sistemi il più possibile automatizzati, con conseguenti versioni noiose. Dopo che uno sviluppatore ha eseguito il commit del codice, la maggior parte delle attività seguenti, se non tutte, devono essere automatizzate.
Pertanto, la ragione di DevOps per perseguire CI/CD è sviluppare sistemi di alta qualità a una velocità maggiore.
Le ragioni di SRE per perseguire CI/CD sono diverse, mirano a ridurre il costo del fallimento. Qualsiasi attività comune, generica o ripetitiva in operazioni come distribuzione e backup è considerata meno degna di attenzione. Pertanto, gli SRE riservano un periodo di tempo specifico per evitare il lavoro operativo. Questo viene fatto in modo che possano svolgere compiti più interessanti come l'esecuzione o l'innovazione di nuove tecnologie o attività legate all'architettura.
Checkout: Progetti DevOps per principianti
Abbattere i silos organizzativi
Sviluppatori e operatori entrano in conflitto quando si tratta del processo di distribuzione. Mentre gli sviluppatori trarrebbero vantaggio dall'implementazione delle funzionalità non appena vengono codificate, gli addetti alle operazioni si concentrano sulla messa a disposizione dei sistemi che ostacolano il processo di distribuzione.
Sia DevOps che SRE differiscono nel modo in cui rimuovono i silos in un'organizzazione.
DevOps, come spiegato in The DevOps Handbook, affronta questo problema includendo pratiche come operare in batch più piccoli e gestire meglio le configurazioni.
Gli SRE non mirano solo a ottimizzare il flusso tra i team, ma aiutano anche i sistemi in produzione. Lo fanno integrandosi nei team come consulenti e supportando gli sviluppatori condividendo la responsabilità dei sistemi in esecuzione. Questo è il modo in cui gli SRE rompono i silos in un'organizzazione.
Misurare un'implementazione di successo
Le metriche DevOps riguardano la velocità delle operazioni; ciò include la frequenza con cui vengono eseguite le distribuzioni, il tempo impiegato per farlo e la frequenza con cui si verificano problemi.
Secondo il rapporto 2017 di Puppet e DORA, la misurazione di un'implementazione di successo in DevOps dipende da quanto segue:
- la frequenza con cui si verificano le distribuzioni
- la durata tra un commit del codice e la sua distribuzione
- la frequenza con cui le distribuzioni falliscono
- il tempo necessario per il ripristino da un errore di distribuzione
Questi circuiti di feedback vengono messi in atto per aiutare DevOps a migliorare la qualità del sistema facilitando al contempo un cambiamento durante la sperimentazione.
SRE, d'altra parte, lavora per migliorare i sistemi tenendo presente la loro affidabilità. Considera le seguenti metriche chiave per determinare un'implementazione di successo:
- obiettivo del livello di servizio (SLO)
- indicatore del livello di servizio (SLI)
- contratto di servizio (SLA)
Le metriche sopra citate sono indicatori dell'affidabilità di un sistema. Queste metriche determinano in anticipo se una versione per la modifica raggiungerà la produzione.
In SRE, queste metriche di velocità e qualità sono utili quando si costruisce un budget di errore e si migliora l'affidabilità dei sistemi piuttosto che lavorare su nuove funzionalità.
Leggi: Stipendio dell'ingegnere DevOps in India
Conclusione
Google aveva pubblicato un eBook su come implementano l'ingegneria dell'affidabilità del sito nei loro sistemi di produzione in cui Treynor spiegava SRE come,
"SRE è ciò che accade quando chiedi a un ingegnere del software di progettare un team operativo".
Quando si tratta di quanto siano diversi DevOps e SRE, tutto ciò che devi ricordare è che SRE è guidato dagli sviluppatori piuttosto che da un team operativo. Sia la manutenzione che il monitoraggio sono principalmente sotto il controllo degli sviluppatori. Questo è ciò che distingue principalmente le due discipline.
Se sei interessato a saperne di più sui grandi DevOps, sullo sviluppo completo dello stack, dai un'occhiata al programma Executive PG di upGrad e IIIT-B nello sviluppo di software - Specializzazione nello sviluppo dello stack completo , progettato per i professionisti che lavorano e offre oltre 500 ore di formazione rigorosa, Oltre 9 progetti e incarichi, stato di Alumni IIIT-B, progetti pratici pratici e assistenza sul lavoro con le migliori aziende.
