Traditionele ISVs zijn vaak gestructureerd als operations- en developmentteams, ieder met een eigen takenpakket. Operations implementeert en beheert de infrastructuur en development richt zich op het bouwen van een verbeterde versie van de software. Maar wie is verantwoordelijk voor de betrouwbaarheid van de software?
Leestijd 4 minuten. Gepubliceerd: 25 maart 2024
Je zou kunnen stellen dat beide teams (Dev en Ops) verantwoordelijk zijn voor hun eigen domein: de applicatie of de infrastructuur. Dat is vaak hoe teams en organisaties de verantwoordelijkheden invullen als het gaat om betrouwbaarheid. Voor traditionele omgevingen levert dit geen problemen op, maar in de Public Cloud gelden andere regels.
In traditionele softwareontwikkeling leverde operations een Virtual Machine (VM) met de benodigde SDK's en runtimes geïnstalleerd. Maar met de toenemende populariteit van ‘Platform as a Service’ (PaaS) en Cloud Native resources vervagen de verantwoordelijkheden. De gedeelde verantwoordelijkheid reikt tot de cloud provider en alle teams die aan het product werken, ook DevOps.
Onhandige beslissingen over de infrastructuur kunnen leiden tot performance- en beschikbaarheidsproblemen. Als de infrastructuur niet is ontworpen aan de hand van de vereisten, kan het uitrollen van de software negatieve impact hebben op de infrastructuur beschikbaarheid. Omgekeerd geldt hetzelfde. Softwarearchitectuur besluiten kunnen impact hebben op de infrastructuur. En tenslotte de algemene architectuur. Je architectuurontwerp bepaalt welke SLAs van toepassing zijn en welke SLA je aan klanten kunt beloven.
Kijkend naar juist die gezamelijke verantwoordelijkheid, gaan we in dit artikel in op belangrijkste onderwerpen en technologieën met betrekking tot de betrouwbaarheid van jouw software. Let’s go!
Azure Advisor is waardevol qua betrouwbaarheid. Het geeft aanbevelingen over kosten, operational excellence, performance, beveiliging en betrouwbaarheid. Niet alleen voor VMs, maar ook voor vele Azure technologieën als AI, compute, networking en databases.
Testen tijdens de ontwikkelcyclus, met bijvoorbeeld unit testing en smoke testing, is een veelgebruikte methode voor development teams. Maar hoe test je infrastructuur? Hoe zorg je ervoor dat je ontwerp in hoge mate beschikbaar, veerkrachtig en betrouwbaar is?
Chaos Engineering is your answer!!
Dit houdt in: het uitvoeren van gecontroleerde fouten en storingen om de mate van veerkrachtigheid van de infrastructuur te bepalen. B.v. Wat doe je wanneer je VMs problemen ervaart met het geheugen? Wat als de DNS niet beschikbaar is? Dat zijn veelvoorkomende scenario’s die kunnen worden veroorzaakt door Azure problemen, foute code of een menselijke fout bij het infrastructuur onderhoud.
Azure Chaos Studio versimpelt dit proces. Je kunt experimenten uitvoeren op verschillende soorten resources, afzonderlijk of gelijktijdig. Dit helpt de veerkrachtigheid van jouw infrastructuur te begrijpen. Daarnaast leer je veel over monitoring en of je interne processen voor bedrijfscontinuïteit op orde zijn.
Wellicht heb je RPO's en RTO's beloofd aan je klanten en/of interne stakeholders. Maar zijn deze beloftes haalbaar? Kijkend naar voorbeeld van een database recovery: je hebt in een SLA met je klant afgesproken dat een database binnen een uur wordt hersteld indien nodig. Maar de tijd die nodig is voor een database recovery is enkele jaren geleden voor het laatst getest. Ondertussen is de database uitgebreid. Is het nog steeds haalbaar om database recovery in 1 uur uit te voeren?
Gelukkig zien we bij Microsoft Azure steeds meer klanten die Infrastructure as Code gebruiken, zoals ARM Templates, Bicep of third-party oplossingen zoals Terraform. Deze zorgen niet alleen voor consistente implementaties en een GitOps werkmethode; ze bieden ook een sterk noodherstel scenario voor je infrastructuur.
Wat als er een regionale storing is? Zijn er resources beschikbaar in verschillende regio's om operationeel te blijven? Niet veel organisaties maken hier gebruik van, vanwege de relatief grote impact op de operationele kosten voor ongebruikte resources. Echter er moet een back up plan zijn. Je streeft er naar je infrastructuur met één druk op de knop in een andere regio te kunnen uitrollen.
Gebruik je Azure rechtstreeks via Microsoft of via een CSP? Kortom, heb je een deskundig team of een partner die je kan helpen in geval van nood? Goede supportcontracten (met Microsoft) bieden inzicht (en misschien zelfs ETA's) om je te helpen beslissen of een overstap naar een nieuwe regio de juiste oplossing zou kunnen zijn. En ook partners kunnen je aan medewerkers helpen om je weer op de goede weg te helpen.
Al met al kunnen we wel stellen dat betrouwbaarheid van zoveel themas afhangt. Maar het allerbelangrijkste: de betrouwbaarheid in de cloud blijft te allen tijde een gedeelde verantwoordelijkheid, tussen DevOps en je cloud provider. Met een goede samenwerking hierin en daarnaast de juiste techniek, is het mogelijk om betrouwbaarheid te bieden aan je klanten.
Binnen onze Managed Services nemen wij een deel van de verantwoordelijkheid van jou over!
Meer over Managed Services