Nog geen week na de ongekende storing bij AWS – die naar verwachting honderden miljoenen zal kosten – werd ook Microsoft Azure getroffen door een wereldwijde uitval. Diensten als Microsoft 365, luchtvaartmaatschappijen, retailers en talloze ondernemingen lagen ineens plat.
De oorzaak bleek een configuratiefout, maar het had net zo goed een cyberaanval, een mislukte update of een actie van een kwaadwillende partij kunnen zijn. De directe verstoring is inmiddels voorbij, maar voor CIO’s, managers verantwoordelijk voor CloudOps en IT-managers begint daarna vaak pas de echte ellende: post-incident reviews, vragen van de board en reputatieschade.
Het wrange is dat dit alles voorkomen had kunnen worden. Simpelweg door te werken met een multicloud-aanpak die veerkrachtig is en dit soort incidenten goed kan opvangen — dus met backup-routes en een failover-plan dat ook daadwerkelijk goed functioneert.
Wanneer storingen een patroon worden
De Azure-storing was kleiner van schaal dan die van AWS, maar de timing was veelzeggend. Storingen zijn niets nieuws, maar als meerdere hyperscalers binnen enkele weken plat gaan, kun je moeilijk nog doen alsof het om toevallige technische foutjes gaat. De realiteit is dat zelfs de grootste cloudplatforms ter wereld niet immuun zijn voor falen — en dat ook nooit zullen zijn.
Deze opeenvolgende incidenten leggen pijnlijk bloot hoe afhankelijk we zijn geworden van hyperscalers. Hyperscale betekent niet ‘onkwetsbaar’. Integendeel: het staat voor enorme, onderling verweven, complexe en daardoor kwetsbare infrastructuren. Als één laag breekt, breekt het breed.
Misschien is het nu tijd om een ander patroon te doorbreken:
Storing → Paniek → Noodmaatregelen → Evaluatie → Vergetelheid → Herhaling.
Hopelijk verschuift de discussie nu naar waar het echt om draait: strategische keuzevrijheid.
Eén cloud is handig – tot het misgaat
Bedrijven zijn de afgelopen jaren aangemoedigd, en soms zelfs financieel gestimuleerd, om diep in één cloudecosysteem te bouwen. Managed services, proprietary tooling en cloud-native abstracties maken het bouwen eenvoudig — maar het overstappen des te moeilijker.
Dus wanneer een regio uitvalt, zoals recent bij US-East‑1 van AWS, is er geen tweede provider of regio om op terug te vallen. Er is geen zicht op wat er buiten de getroffen cloud gebeurt, en al helemaal geen controle over het herstel. Zelfs als er een tweede provider is, werkt die vaak in een silo. Tegen de tijd dat workloads zijn omgeleid en opnieuw geconfigureerd, is de oorspronkelijke storing alweer verholpen — maar de schade is al aangericht.
Waarom diversiteit geen keuze meer is
Echte veerkracht vraagt om diversiteit. Het gaat allang niet meer alleen om regionale storingen, maar ook om de mogelijkheid om gebruik te maken van de beste diensten en infrastructuren voor innovatie ‘at scale’. Diversiteit creëert keuzevrijheid – en keuzevrijheid creëert veerkracht.
Maar brengt dat niet juist meer complexiteit en kosten met zich mee?
Niet met platforms zoals emma. Multicloud hoeft niet langer synoniem te zijn met complex. Het is selecteren en uitrollen — met ingebouwde netwerkintelligentie, kostenoptimalisatie en portabiliteit.
De cloud-agnostische orkestratie van emma maakt het mogelijk om workloads te routeren, uit te rollen of te verplaatsen tussen clouds en regio’s, zonder alles opnieuw te moeten bouwen. Het – zeg maar – soevereiniteitsklare netwerk zorgt ervoor dat dataverkeer veilig en slim beweegt tussen omgevingen. En dankzij geïntegreerd governance- en monitoringsbeheer worden problemen vroegtijdig gedetecteerd en worden continuïteitsregels direct afgedwongen.
Wanneer je architectuur ‘portable’ is, je governance verenigd, je netwerk veilig en je omgevingen over meerdere providers georkestreerd, krijg je de meest waardevolle operationele kracht van allemaal: keuzevrijheid. Dat betekent:
- Keuze van regio
- Keuze van provider
- Keuze waar data zich bevindt
- Keuze over je risicoprofiel
En precies dát is waar emma voor staat: het mogelijk maken én vereenvoudigen van die keuze.
0 reacties