SRE vs DevOps – Concorrenti o amici - getIT
Codice sullo schermo del laptop
SRE

SRE vs DevOps – Concorrenti o amici

Sempre più team Swisscom applicano il Site Reliability Engineering (SRE) per soddisfare le aspettative di clienti e utenti. Ma attenzione! Non pensavamo che DevOps avrebbe potuto fungere da ponte tra Dev e Ops affinché il nostro software avesse una qualità elevata in produzione? SRE è solo una nuova moda sul mercato usata per attirare i talenti? In questo post, il team Swisscom DevOps chiarisce il senso di SRE rispetto a DevOps e il suo valore per il settore software di Swisscom. Iniziamo con un po’ di teoria su DevOps e SRE:
Michael Ludwig
Michael Ludwig, Tribe Chief
12 agosto 2020

DevOps

  • Il movimento DevOps è iniziato perché gli sviluppatori scrivevano codici senza avere un’idea precisa di come avrebbero funzionato in produzione. Lanciavano per così dire il codice alla cieca al team operativo, il cui compito era far funzionare le applicazioni.
  • DevOps è nata come cultura e insieme di pratiche finalizzate a ridurre le distanze tra lo sviluppo software e la sua operatività.
  • Ecco perché DevOps è come una classe astratta o un’interfaccia di programmazione. Stabilisce il comportamento complessivo del sistema, ma i dettagli dell’implementazione sono a scelta libera

Site Reliability Engineering (SRE)

Site Reliability Engineering (SRE) è un’espressione (cui si associa una job role) coniata da Ben Treynor Sloss, vicepresidente nell’engineering in Google.

SRE è una job role, un insieme di pratiche lavorative individuate da Google e una serie di convinzioni che ispirano queste pratiche. Pensando a DevOps come una filosofia e un approccio al lavoro, si può dire che SRE traduce in pratica una parte della filosofia descritta da DevOps.

«SRE è quello che succede quando si chiede a un ingegnere software di mettere a punto una funzione operativa.»

Ben Treynor, vicepresidente engineering in Google

SRE concretizza DevOps

SRE incarna la filosofia di DevOps, ma ha un modo molto più prescrittivo di misurare e raggiungere l’affidabilità attraverso il lavoro ingegneristico e operativo. In altre parole, SRE prescrive come avere successo nelle diverse aree DevOps. La tabella seguente, ad esempio, illustra i cinque pilastri di DevOps e le corrispondenti pratiche SRE:

Grafico DevOps e SRE

In un certo senso la classe SRE implementa l’interfaccia DevOps.

DevOps <-> SRE: differenze

Tuttavia, ci sono anche differenze significative. Per certi versi, DevOps è una filosofia e una cultura in senso ampio.

 

DevOps è relativamente silenziosa sul modo in cui far girare le funzioni operative a livello dettagliato. Ad esempio, non è prescrittiva in merito all’esatta gestione dei servizi. Sceglie invece di concentrarsi sull’eliminazione di barriere nell’organizzazione in senso ampio, che a sua volta ha molto valore.

 

SRE, al contrario, definisce le responsabilità a un livello piuttosto dettagliato e il suo orientamento è generalmente verso il servizio (e l’utente finale) anziché verso l’intera impresa. Di conseguenza, inserisce il problema del funzionamento efficace dei sistemi in una cornice più ampia e condivisa (compresi concetti come error budget. Per quanto SRE sia, come professione, ben cosciente degli incentivi e dei loro effetti, è anche relativamente silenziosa su questioni come silosizzazione e barriere informative. Supporterebbe CI (Continuous Integration) e CD (Continuous Delivery) non necessariamente per il business case, ma per le migliori pratiche operative che comportano.

 

O, detta in altre parole, SRE crede nelle stesse cose di DevOps, ma per ragioni leggermente diverse.

Risorse

Questo post è basato in gran parte su SRE vs. DevOps: competing standards or close friends?

Un articolo di:

Portrait Image

Michael Ludwig

Tribe Chief

Altri articoli getIT

Pronti per Swisscom

Trova il posto di lavoro o il percorso di carriera che fa per te. Dove dare il tuo contributo e crescere professionalmente.

 

Ciò che tu fai, è ciò che siamo.