Het leveren en stabiel houden van moderne webapplicaties is steeds vaker een samenspel tussen ontwikkelaars en systeemspecialisten. Om efficiëntie in dit proces te behalen worden continu nieuwe invalshoeken bedacht, want wie efficiënt is heeft een streepje voor op de concurrent. Grote techbedrijven als Google, Facebook en Amazon nemen het voortouw en bedenken zelfs compleet nieuwe IT-disciplines, zoals ‘Site Reliability Engineering’. Wat houdt zo’n functie precies in?
Site Reliability Engineering (SRE)
Het zal je vast niet verbazen hoe complex de IT-omgeving van Google is. De miljoenen mensen die dagelijks de zoekmachine gebruiken of de productiviteitsapps van Google doen nogal een beroep op de cloudinfrastructuur van de techgigant uit Silicon Valley.
Begin 2000 liep Google tegen wat problemen aan. Om de infrastructuur stabiel te houden waren systeembeheerders druk in de weer, vooral wanneer ontwikkelaars nieuwe wijzigingen toevoegde aan een van de Google producten. Dat ging ook wel eens mis, want ontwikkelaars en systeembeheerders zijn twee verschillende bloedgroepen die elkaar niet altijd begrijpen. Ontwikkelaars willen snelheid en vaak nieuwe functies leveren. Systeembeheerders willen stabiliteit en veiligheid van de software.
Google bracht daarom een nieuwe rol tot leven: de Site Reliability Engineer (SRE). Deze persoon werd gezien als brug tussen ontwikkelaar en systeembeheerder. Een SRE-specialist heeft verstand van software-engineering en weet dit toe te passen binnen infrastructuur en dagelijkse operaties. Site Reliability Engineering werd al snel een ‘geheim’ middel waarmee Google hoogschaalbare systemen in een snel tempo stabiel kon leveren.
DevOps en Site Reliability Engineering
Misschien vind je Site Reliability Engineering zoals hierboven omschreven een beetje lijken op de term DevOps, een term waar letterlijk de twee IT-disciplines zijn samengesmolten (developers en operators). Heel gek is die associatie niet. Google zelf ziet namelijk veel parallellen tussen Site Reliability Engineering en DevOps, maar dan is SRE een stuk pragmatischer. Toch zijn er belangrijke verschillen.
Om in het programmeerhoekje te blijven: Google ziet Site Reliability Engineering als een ‘class’ die DevOps implementeert. DevOps op zichzelf bestaat uit een flink aantal abstracte begrippen die bovendien voor elk bedrijf weer anders te interpreteren zijn. Je kunt de twee begrippen dus eigenlijk niet met elkaar vergelijken. SRE gaat over het praktische, DevOps is meer een soort managementfilosofie die de hele organisatie raakt.
Kernconcepten DevOps en Site Reliability Engineering
In een talk op Configuration Management Camp legt Seth Vargo, engineer bij Google Cloud Platform, uit wat de overeenkomsten zijn tussen de twee begrippen. Zowel DevOps als SRE gaan (in ieder geval bij Google) uit van dezelfde kernconcepten:
Reduceren van silo’s: door ontwikkelaars en systeembeheerders fysiek bij elkaar te brengen ontstaat er meer begrip voor elkaars werk en een betere samenwerking.
Falen accepteren als normaal: je kunt ervan uitgaan dat er iets stuk gaat, accepteer dit en implementeer methoden en systemen om hierop te reageren.
Stap voor stap veranderingen doorvoeren: software lever je niet meer via de watervalmethode, maar stap voor stap. Dit maakt het leveren van software een stuk kleiner, sneller en daarmee overzichtelijker.
Tools en automatisering gebruiken: automatiseer wat je kunt automatiseren en integreer technologiestacks die door zowel voor development als systeembeheer te gebruiken zijn.
Alles meten wat je kunt meten: meten is weten. Gedeelde metrics (bijvoorbeeld op het vlak van application performance monitoring) geven inzicht aan metingen die zowel voor ontwikkelaars als operators belangrijk zijn.
Wat maakt Site Reliability Engineering anders?
In de kern gebruikt een Site Reliability Engineer software als gereedschap om infrastructuur in te richten en te beheren, dit noem je ook wel infrastructure as code. In plaats van wijzigingen doorvoeren op de hardware doet een SRE-specialist via allerlei slimme software.
Software defined
Tools als Terraform, maar ook configuratiemanagementtools als Chef en Ansible behoren tot het standaard arsenaal van de Site Reliability Engineer. Met dit soort tools kan de SRE’er veelvoorkomende taken automatiseren, denk aan standaardinstellingen in een database of automatische installaties van complete (virtuele) servers waarbij veel herhaalbaarheid voorkomt.
Veel van dit soort infrastructure as code tools integreren bovendien naadloos met Kubernetes, de populairste open-source orkestrator voor containers op het moment.
Lees ook: 'Wat is Kubernetes?'
Standaard receptuur
Menig SRE’er bedenkt van tevoren ‘recepten’ voor alle software (denk aan besturingssysteem, maar ook databasesoftware, firewalls enzovoorts) die nodig zijn om een website of complexe webapplicatie te runnen.
Door dit in een keer goed uit te denken is het niet alleen mogelijk om sneller nieuwe software op te leveren, maar ook sneller te zien waar de mogelijke gevaren zitten. Standaardisatie zorgt ook voor snelheid en veiligheid. Maar ook; stabiliteit. Want in de standaard receptuur worden ook tests geprogrammeerd die de impact van een wijziging op de stabiliteit van de omgeving controleren.
Deze tests worden geïntegreerd in een CI/CD pipeline zodat vooraf gesignaleerd kan worden of er iets stuk gaat wanneer de applicatie wordt geleverd.
Toil laag houden
Google zelf zegt dat 30% van de ‘outages’ (uitval van systemen) in het verleden werd veroorzaakt door configuratiewijzigingen. Door hier vooraf goed over na te denken kun je dus mogelijk uitval van systemen voorkomen.
Voor een SRE-specialist is het belangrijk om inzicht te hebben in het aantal wijzigingen zodat er ook zicht ontstaat waar geautomatiseerd kan worden. De Site Reliability Engineer is erop gedreven op zijn ‘toil’ zo laag mogelijk te houden, dat zijn alle handmatige aanpassen waar de specialist mee te maken heeft. Het schrijven van scripts voor het (geautomatiseerde) leveringsproces van de applicatie is een van de manieren om dit te doen.
Geavanceerde monitoring
Ander belangrijk gereedschap voor Site Reliability Engineers is monitoring. Letterlijk alles binnen een IT-omgeving is te monitoren. Met geavanceerde applicatiemetricstool worden bijvoorbeeld gegevens getoond die voor developers als operators interessant zijn.
Denk aan beschikbaarheid van het winkelwagentje in een e-commerce-omgeving. Dat is zowel voor ontwikkelaars als beheerders relevant om in de gaten te houden, omdat hier dé belangrijkste transactie voor een webshop plaatsvindt. Ontwikkelaars willen weten of er bugs in dit proces plaatsvinden, beheerders willen weten of dit gedeelte van de website veel verkeer aankan (zeker in een campagneperiode!). Een SRE-specialist houdt ze dus beiden in de gaten.
Lees ook: De voordelen van Application Performance Monitoring
Een belangrijke metric die de SRE-specialist ook in de gaten houdt is de toil, oftewel het percentage handmatige handelingen dat nog verricht wordt. Hiermee meet de Site Reliability Engineer hoeveel tijd hij/zij kwijt is aan een handeling. Overigens is een toil van 0% ook niet altijd wenselijk. Want je kunt ook veel tijd spenderen aan automatisering in systemen of processen die op korte termijn uitgefaseerd worden.
SLO’s, SLI’s
Maar hoe weet je nou als Site Reliability Engineer wat er dan geautomatiseerd moet worden? En wat je moet monitoren?
Dat zaken worden vastgelegd in Service Level Objectives (SLO) en Service Level Indicators (SLI). Wellicht ken je al de Service Level Agreement (SLA), afspraken die je met een IT-dienstverlener afsluit waarbij afspraken worden gemaakt over bijvoorbeeld de beschikbaarheid van systemen.
SLO’s en SLI’s zijn meer interne kwesties. In een SLO wordt vastgelegd wat de doelstellingen van de samenwerking zijn, bijvoorbeeld tussen de afdeling development en systeembeheer. In een SLI bepaal je vervolgens waarop je gaat meten, de indicatoren. En hier kan dan geen discussie over ontstaan op de werkvloer, want dit als bedrijf met elkaar afgesproken.
Een Site Reliability Engineer gebruikt deze afspraken als kompas voor de dagelijkse werkzaamheden, en bijvoorbeeld om te bepalen wat belangrijk is om wel of niet te automatiseren. Deze afspraken zijn natuurlijk per bedrijf verschillend, maar extreem waardevol volgens Google omdat ze gesteggel over prioriteiten uit de weg gaan. En dan kun je gewoon aan het werk.
Site Reliability Engineering: niet voor iedereen
Is het dan noodzakelijk om direct Site Reliability Engineers in te huren voor je bedrijf? Dat is nog maar af te vragen. Vooralsnog lijken de principes van Site Reliability Engineering met name toepasbaar voor bedrijven die zeer complexe webapplicaties hebben waarbij veel wijzigingen worden gedaan in verschillende gedistribueerde systemen. Zoals de Google’s, Facebook’s en Amazon’s van deze wereld.
Maakt je bedrijf nog gebruik van een monolithische applicatie-infrastructuur in plaats van een microservices applicatie-infrastructuur, dan heeft het waarschijnlijk weinig zin om hele concrete stappen te zetten met SRE.
De eerste stap die je dan als bedrijf moet zetten is het verwerken van je applicatie naar een moderne applicatie-infrastructuur die bijvoorbeeld is opgebouwd via de Twelve Factor disciplines. Met die methodiek ga je ervan uit dat webapplicaties bestaan uit allerlei losse softwarestukjes (ook wel: microservices) die slim met elkaar verbonden zijn.
Desondanks valt er genoeg te leren van bepaalde principes uit Site Reliability Engineering en om die te implementeren in de huidige business. Denk alleen al aan het opstellen van SLO’s en SLI’s, of het implementeren van tools die zowel applicatiemetrics als operationele metrics voor je kunnen meten.
Video: verschillen DevOps en SRE
Nog even in een kleine vijf minuten de verschillen tussen Site Reliability Engineering en DevOps zien? Deze video legt het uit.
“SRE class implements DevOps”
Duidelijk is dat Site Reliability Engineering en DevOps elkaar complimenteren, als je uitgaat van de voorbeelden van Google tenminste. Ook duidelijk is dat de twee termen niet met elkaar kunt vergelijken. Site Reliability Engineering lijkt met name een begrip te zijn dat DevOps uit het abstracte haalt en concretiseert. SRE is niet voor iedereen interessant, tenzij je te maken hebt met gedistribueerde systemen waar vele wijzigingen plaatsvinden.
Wil je hier meer over leren, dan kun je ontzettend veel gegevens vinden op de speciale website van Google hierover, waar je precies kunt leren hoe Google hun productie-omgevingen hanteert en wat de rol van Site Reliability Engineers hierbij is. Er zijn zelfs gratis complete boeken over te downloaden. Doe er je voordeel mee!
