Zoeken
Jonge zakenvrouw aan het werk op een tablet in een vliegtuig

Cloudbeschikbaarheid opnieuw vormgeven

Hoe moderne cloudarchitecturen steeds veiliger worden dankzij slimme failover-maatregelen en snelle herstelprocessen

27. februari 2026Richard Simon

Risico's omzetten in veerkracht

Storingen zijn onvermijdelijk in de moderne, sterk verbonden wereld met verstrekkende digitale afhankelijkheden. Betrouwbare beschikbaarheid wordt niet gekenmerkt door de afwezigheid van verstoringen, maar door het vermogen van een bedrijf om de impact van een incident op te vangen, een snel herstel uit te voeren en waardetoevoegende processen binnen de kortst mogelijke tijd weer op gang te brengen. Dit artikel laat zien hoe je onzekerheid kunt omzetten in bedrijfscontinuïteit door een goede voorbereiding, een toekomstgericht architectuurontwerp en het bewust omgaan met mogelijke storingen.

 

De zwakke punten van de cloud

Ik wilde dit artikel eigenlijk de titel "De verborgen zwakheden van de cloud" geven, maar ik ben van gedachten veranderd omdat de gevolgen van een grote storing in de cloud allesbehalve verborgen zijn.  Volgens mijn vriend Paul Bevan, voormalig hoofd infrastructuuronderzoek bij Bloor Research en nu gepensioneerd, verplaatsen organisaties op bepaalde gebieden hun werklasten naar de cloud en gaan ze ervan uit dat het proces voltooid is. Ze behandelen cloudtransformatie alsof de verantwoordelijkheid nu buiten hun eigen domein ligt en geen verdere aandacht vereist.

Maar migreren naar de cloud, met name de public cloud, is uiteraard veel complexer. Het model van gedeelde verantwoordelijkheid is een tegenhanger van deze enigszins naïeve benadering.

Storing in de cloud is niet ongewoon in de huidige hyperverbonden wereld en bij complexe diensten. Ondanks het geavanceerde ontwerp van hyperscaler-platforms kunnen storingen optreden, met oorzaken die variëren van software-updates, configuratiefouten en netwerkproblemen tot stroomuitval, menselijke fouten of kettingreacties bij afhankelijke diensten.

Nu organisaties steeds meer bedrijfskritische workloads verplaatsen naar cloudomgevingen, kan zelfs een korte downtime langdurige gevolgen hebben voor de beschikbaarheid, het vertrouwen van de klant, de publieke perceptie en de stabiliteit van de inkomsten. Incidenten leggen een ongemakkelijke waarheid bloot: een veerkrachtige dienstverlening kan niet worden uitbesteed - de juiste mechanismen moeten worden ingebed in de architectuur.

Wanneer een storing optreedt

Als er een grote storing in de cloud optreedt, zijn de gevolgen vrijwel onmiddellijk voelbaar in alle sectoren. Toepassingen worden trager, API's (Application Programming Interfaces) reageren niet meer, gegevensverwerking komt tot stilstand en klantgerelateerde diensten zijn niet meer beschikbaar (websites genereren foutmeldingen).

De directe business impact omvat het verlies van transactiegegevens, productiviteitsverlies en reputatieschade. Bij de overheid, in de gezondheidszorg, in e-commerce en met name in de financiële sector kan een korte downtime van minuten of milliseconden leiden tot inkomstenverlies, overtreding van compliance-regels, het niet naleven van service level agreements (SLA's) en problemen met de integriteit van gegevens.

De grootste kostenfactoren zijn de hersteltijd, het verlies van klanten en de grotere operationele inspanning die nodig is om het systeem weer normaal te laten functioneren.

Waarom traditionele beschermingsmechanismen niet volstaan

Om deze risico's tegen te gaan, maken bedrijven traditioneel gebruik van verschillende risicobeperkende strategieën, waaronder het aanbieden van multi-beschikbaarheidszones (multi-AZ), datareplicatie, DR-configuraties (disaster recovery) of zelfs multi-cloudstrategieën.

Hoewel deze maatregelen in zekere mate helpen, bieden ze geen absolute zekerheid. Een multi-cloudaanpak kan bijvoorbeeld gepaard gaan met latentie, complexe governance-vereisten, trainingsbehoeften en extra bedrijfskosten. Op dezelfde manier kan een back-up- of noodherstelplan alleen gegevens beschermen, maar niet noodzakelijkerwijs beschikbaarheid of naadloze failover- en failbackprocessen garanderen. Met andere woorden: traditionele herstelplannen kunnen te traag en omslachtig zijn voor sommige van de hedendaagse krachtige, data-gedreven en event-gebaseerde architecturen.

Of anders gezegd: redundantie alleen garandeert nog geen beschikbaarheid. De doorslaggevende factor is hoe goed deze systemen zijn ontworpen, geautomatiseerd en regelmatig getest onder storingsomstandigheden.

Vertrouwen winnen door chaos

Hoge beschikbaarheid (High availability, HA) is een belangrijke hoeksteen van een veerkrachtige cloudarchitectuur. Het doel is om downtime tot een minimum te beperken. Dit wordt bereikt door systemen te ontwerpen die blijven functioneren, zelfs wanneer één, twee of alle diensten uitvallen.
Om de theorie in praktijk te brengen, moeten bedrijven actie ondernemen en technieken zoals chaos engineering toepassen. Hierbij worden storingen in productieomgevingen gesimuleerd om te observeren hoe systemen zich in kritieke situaties gedragen. Het identificeren van kwetsbaarheden voordat zich daadwerkelijke incidenten voordoen, geeft bedrijven de kans om hun architectuur en responsmechanismen te optimaliseren.

Netflix wordt beschouwd als een van de pioniers van chaos engineering. Het bedrijf heeft deze aanpak gebruikt om de beschikbaarheid van zijn streamingplatform te waarborgen, ondanks frequente wijzigingen in de infrastructuur. Vergelijkbare benaderingen kunnen bedrijven helpen vertrouwen te krijgen in hun cloudconcepten, ongeacht de provider.

Beschikbaarheid, kosten en complexiteit in overeenstemming brengen

Het bouwen van een HA-geschikte cloudarchitectuur (met beproefde failover- en failbackmechanismen) heeft een prijs: extra financiële kosten en operationele complexiteit. Redundante resources, implementaties in meerdere regio's en geautomatiseerde failovermechanismen vereisen extra investeringen.

Ik heb onlangs gereageerd op een online artikel waarin werd gesteld dat clouddiensten in hun ontwerp ‘veerkracht’ moeten garanderen.  Ten eerste is veerkracht niet hetzelfde als HA. Controleer gerust zelf de definities. De twee termen mogen niet met elkaar worden verward of als synoniem worden gebruikt. Ik beschreef ook het volgende scenario in mijn reactie:

  • de CEO vraagt de CIO en CTO naar een recente storing.
  • De CIO en CTO leggen aan de CEO uit hoeveel het kost om HA op te zetten.
  • De CEO gaat hiermee naar de CFO, maar die wijst het voorstel direct af: "Vergeet het maar!"

Ik heb soortgelijke gesprekken in veel bedrijven gehoord. Het resultaat was in de meeste gevallen hetzelfde, en slechts over één punt bestond altijd consensus: de kosten zijn de doorslaggevende factor.

Veel bedrijven staan onder druk om hun cloudkosten laag te houden. Dit leidt er vaak toe dat veerkracht wordt uitgesteld of helemaal niet wordt geïmplementeerd vanwege budgetbeperkingen. Daarnaast worden cloud-native architecturen geassocieerd met afhankelijkheden op meerdere niveaus (microservices, containers, API's), die gecoördineerde beschikbaarheidsstrategieën vereisen.

De grootste uitdaging hier is om een balans te vinden tussen kostenefficiëntie en betrouwbaarheid. Zakelijke prioriteiten moeten daarom op de een of andere manier in lijn worden gebracht met het technische ontwerp. Niet alle workloads vereisen 99,999 procent beschikbaarheid, wat wel essentieel is voor bedrijfskritische systemen. Het is daarom zinvol om elders in de cloud een minimumniveau van hoge beschikbaarheid in te stellen, zodat een bedrijf in een failoversituatie in elk geval de belangrijkste diensten kan blijven aanbieden.

Ontwerp van een HA-architectuur

  1. Houd rekening met storingen: ga ervan uit dat storingen kunnen optreden, zowel in je eigen datacenter als in de public cloud. Ze vormen een realiteit bij het gebruik van elke technologie in het bedrijfsleven. Houd rekening met het uitvallen van individuele componenten bij het ontwerpen van de architectuur. Kies voor ontkoppelde ontwerpen, celgebaseerde architecturen, asynchrone replicatie, bewezen failover-/failbackfuncties en geautomatiseerde herstelmechanismen.
  2. Workloads prioriteren: niet alle toepassingenhoeven dezelfde mate van veerkracht te hebben. Classificeer workloads op basis van bedrijfsbelang en investeer dienovereenkomstig.
  3. Waarneembaarheid implementeren: systeemoverschrijdende real-time transparantie en patroonherkenning (met AIOps) is van cruciaal belang. Monitor prestatie-indicatoren, afhankelijkheden en gebruikerservaring voortdurend om vroegtijdige tekenen van verslechtering te detecteren.
  4. Regelmatig testen: voer gecontroleerde storingssimulaties of testdagen uit om je herstelprocessen te controleren. Documenteer belangrijke bevindingen en werk de architectuur dienovereenkomstig bij.
  5. Herstel automatiseren: handmatige interventie vertraagt het herstel. Gebruik Infrastructure as Code (IaC) en zelfherstellende mechanismen om sneller herstel te garanderen.
  6. Evenwichtig gebruik van de multi-cloud: gebruik de multi-cloud selectief. Voor sommige workloads kan het gebruik van meerdere providers de beschikbaarheid verbeteren, maar voor andere kan het leiden tot onnodige complexiteit en kosten.
  7. Controleer SLA's en gedeelde verantwoordelijkheden: maak jezelf vertrouwd met het model van gedeelde verantwoordelijkheid van je cloudprovider. Maak duidelijk welke aspecten van beschikbaarheid en beveiliging door de provider worden gedekt en wat onder jouw eigen verantwoordelijkheid valt.
  8. Denk je dat hiermee alles is geregeld? Verre van dat! Controleer wat er boven je staat in de cloudhiërarchie. Zelfs als je goede lokale noodplannen hebt, kan een storing buiten je controle je plannen verstoren.

Storing omzetten in kansen

Een veerkrachtige cloud is geen item op een checklist, maar vereist een cultuur van voorbereiding op noodsituaties. Naarmate digitale ecosystemen zich ontwikkelen, moeten bedrijven verder denken dan alleen back-ups en redundanties. Beschikbaarheid opbouwen betekent een solide architectuur combineren met strikte testen, transparantie en governance.

Ongeacht het platform is elke storing een kans om bestaande aannames te heroverwegen en het ontwerp te verbeteren. De vraag is niet of er een storing zal optreden, maar hoe goed je bedrijf erop is voorbereid als het ergste gebeurt.

Je partner voor beveiliging in de cloud

Bij T-Systems werken we samen met bedrijven uit verschillende branches om hoog beschikbare, veilige, soevereine en toekomstbestendige cloudarchitecturen te ontwerpen en te implementeren. Onze aanpak combineert diepgaande kennis van cloud-engineering met bewezen HA-raamwerken, observeerbaarheid en geautomatiseerd herstel.

Als betrouwbare partner van toonaangevende hyperscalers zoals Amazon Web Services (AWS), Microsoft Azure en Google Cloud Platform (GCP) helpen we bedrijven het beste uit elk ecosysteem te halen, complexiteit te beheren, kosten te optimaliseren en betrouwbaarheid te vergroten.

Van strategische ontwerp- en architectuurbeoordelingen tot migratie, optimalisatie en doorlopende governance, T-Systems stelt bedrijven in staat om een fundament te leggen voor ononderbroken digitale activiteiten en duurzame transformatie.

Bij het optimaliseren van de beschikbaarheid gaat het niet om het volledig voorkomen van storingen, maar om erop voorbereid te zijn als deze optreden.

Informatie over de auteur
Portret Richard Simon CTO, Cloud Transformation

Richard Simon

CTO, Professionele clouddiensten , T-Systems

Alle artikelen en het profiel van de auteur

Dit vind je vast ook interessant

We kijken uit naar je mening

Heb je ideeën, suggesties of vragen over dit onderwerp? We nodigen je van harte uit om ideeën met ons uit te wisselen. Neem contact met ons op!
Do you visit t-systems.com outside of Netherlands? Visit the local website for more information and offers for your country.