SRE vs DevOps – Concorrenti o amici
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à.
- Però il movimento DevOps non stabilisce esplicitamente come avere successo in questi campi.
- 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:
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:
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.
