Site Reliability Engineering: een introductie met het wat, hoe en waarom

Site Reliability Engineering is een begrip dat de laatste jaren vanuit Google naar de rest van de wereld is overgewaaid. In dit artikel een overzicht in vogelvlucht met antwoord op vragen als: hoe is SRE ontstaan? Wat is het? Waarom wordt het zo vaak genoemd samen met DevOps? En is een Site Reliability engineer relevant voor mijn bedrijf?

De aanleiding voor SRE

Binnen Google waren er in 2000 veel conflicten ontstaan tussen systeembeheerders en programmeurs. DevOps is ontwikkeld als antwoord op dergelijke conflicten. Daarna kwam ook de SRE-functie die ongeveer in 2003 bij Google ontstaan is. Toentertijd was er vraag naar mensen die hun tijd volledig konden inzetten om de Google-systemen schaalbaar, betrouwbaar en stabiel te maken. Oorspronkelijk ging het over de stabiliteit van de “site” daarom heet het nu nog “Site” Reliability Engineering.

Nadat SRE bij Google ontstond, verspreidde de methode zich razendsnel naar de rest van de high tech-industrie: steeds meer bedrijven begonnen Site Reliability Engineers in dienst te nemen. Deze rol komt meer voor bij enterprise-omgevingen, omdat start-ups of bedrijven in de mkb-sector vaak niet in een omgeving opereren waarbij gespecialiseerde SRE’ers nodig zijn. De werkzaamheden van SRE’ers worden dan als bijzaak vervuld door de DevOps-engineers, systeembeheerders of programmeurs.

Wat is SRE?

Site Reliability Engineering is het idee waarbij je de mindset van een programmeur pakt en deze toepast in de werkzaamheden van een systeembeheerder. Een voorbeeld hiervan is dat handmatige systeembeheerders taken geautomatiseerd worden door software, vaak via Infrastructure as Code. 

De primaire doelstelling van SRE is het waarborgen en verbeteren van de gebruikerservaring. Dit wordt gedaan door de stabiliteit van kritieke systemen te bewaken en aan de hand daarvan ook verbeteringen te adviseren. Voor het bewaken van de stabiliteit wordt er gebruik gemaakt van technische oplossingen zoals: monitoring (metrics), logging en tracing. Tegenwoordig noemen ze dit ook wel “Observability” waarmee er wordt bedoeld dat het gedrag van het systeem “geobserveerd” moet worden. Hierdoor gaat het proces van de traditionele “black box” monitoring aanpak naar een “white box” observability aanpak.

SRE versus DevOps

Binnen het development proces zijn er tegenwoordig twee belangrijke rollen met, zo op het eerste gezicht, conflicterende doelen:

• Programmeurs willen graag features releasen die in hun backlog staan. Het doel is om verandering te brengen in software.
• Systeembeheerders willen stabiele software deployen en beheren. Omdat verandering vaak tot instabiliteit leidt, zal een beheerder juist verandering tegen willen gaan.

De doelen van een programmeur en systeembeheerder kunnen best tegenstrijdig zijn. Daardoor is de kans aanwezig dat er vertraging oploopt binnen het development proces.

Het kleiner maken van deze tegenstrijdigheid is een van de kernwaarden achter de DevOps beweging. In het begin was de rol van beheerder nog iets wat vaak binnen het development team landde, maar door specialisatie ziet men steeds meer dat dit toegewijd is. Doordat bedrijven steeds meer betrouwbaarheid, schaalbaarheid en stabiliteit als key begrippen in hun systemen stellen is de rol van SRE tot stand gekomen.

DevOps en SRE hebben allebei het doel om het grote gat tussen systeembeheerders en programmeurs dichter bij elkaar te brengen. Daardoor kunnen ze op elkaar lijken, echter is er toch wel een duidelijk verschil namelijk: 

• DevOps is meer gefocust op de versnelling van het development proces.
• SRE richt zich meer op het stabiel, betrouwbaar en schaalbaar krijgen van het product afkomstig uit het development proces.

Is SRE relevant voor mijn bedrijf?

Na het lezen van deze blog vraag je je wellicht af of SRE relevant voor je bedrijf? Om daar antwoord op te geven moet je kijken naar de uitgangspunten van Site Reliability Engineering. Deze zijn voornamelijk toepasbaar bij bedrijven waarin er gewerkt wordt met gedistribueerde systemen. In deze systemen staan non functionals als schaalbaarheid, betrouwbaarheid en stabiliteit centraal. 

Is het nu op dit moment niet toepasselijk voor je huidige bedrijf? Dan lijkt het me toch wel handig om een beeld van SRE in je achterhoofd te hebben. SRE wordt steeds populairder en ik denk dat dit een blijvertje wordt. In Nederland speelt SRE al een belangrijke bij de volgende bedrijven: NS, Rijksoverheid, Mollie, Albert Heijn en ook natuurlijk ook bij Cloud Legends. 

Over de auteur: David Weng is Teamlead Complex E-Commerce & Software Developer/Consultant bij Kabisa.

Op de hoogte blijven van het laatste nieuws binnen je vakgebied? Volg Emerce dan ook op social: LinkedIn, Twitter en Facebook