Home Nieuws De verborgen kosten van cloudcentralisatie

De verborgen kosten van cloudcentralisatie

13
0
De verborgen kosten van cloudcentralisatie

Toen de Amerikaanse Oost-1-regio van AWS het werd donker eind oktober, slechts een week later gevolgd door een Microsoft Azure-storinghet was opnieuw een duidelijke herinnering dat zelfs de grootste cloudproviders ter wereld niet immuun zijn voor mislukkingen. Een simpele DNS-fout in AWS Route 53 rimpelde naar buiten, waardoor applicaties werden geëlimineerd, databaseservices werden verstoord en ons eraan werd herinnerd hoe afhankelijk onze technologie-infrastructuur is geworden van een handvol cloudregio’s. Met “een onbedoelde wijziging in de tenantconfiguratie”, benadrukte de Azure-storing de instabiliteit van sommige van deze systemen verder, wat eens te meer aantoont hoe kleine veranderingen een behoorlijk grote impact kunnen hebben.

Met CyberCube Als we schatten dat de kosten van de AWS-storing tussen de $38 miljoen en $581 miljoen kunnen liggen, kunnen de economische en operationele kosten van een dergelijke storing niet worden overschat. Dit geldt vooral voor kleine tot middelgrote organisaties die niet over de middelen beschikken om downtime van meerdere uren of meerdere dagen op te vangen. Voor veel bedrijven heeft deze recente verstoring de verborgen kosten van cloudcentralisatie blootgelegd: als één regio hapert, kan alles tot stilstand komen.

Verstoringen zijn onvermijdelijk. Zelfs de CTO van AWS deed het zei hetzelfde: Systemen zullen falen, dus moeten ze worden ontworpen om falen te voorspellen en te weerstaan. Toch ontwerpen te veel organisaties nog steeds alsof de cloud zelf onfeilbaar is. Ze gaan ervan uit dat redundantie, backups en herstel automatisch zijn ingebouwd en ontdekken te laat dat dit niet het geval is.

Het goede nieuws is dat veerkracht kan worden opgebouwd voordat de volgende mislukking zich voordoet.

DIVERSIFICATIE VOOR DE DISTERRUPTIE: WACHT NIET OP DE VOLGENDE VERSTORING

De eerste verdedigingslinie is eenvoudig van opzet, maar moeilijk uit te voeren. Je moet diversifiëren voordat het noodlot toeslaat. Zie het als een beleggingsportefeuille. Je zou niet al je geld op één rekening zetten; is onderverdeeld in verschillende opties om uw belegging de beste kans op succes te geven. Dit betekent ontwerp voor mislukking in meerdere beschikbaarheidszones of regio’s. AWS raadt zelfs aan dit te doen in zijn “Goed ontworpen AWS“gids.

Een goed ontworpen systeem zou verkeer binnen enkele seconden van de ene regio naar de andere moeten kunnen verplaatsen (bijvoorbeeld van US-Oost-1 naar US-West-1). Uitvallen zorgen er zelden voor dat meerdere regio’s tegelijk plat liggen, dus een architectuur met meerdere regio’s blijft een van de meest effectieve verdedigingen tegen downtime.

OVERSCHAKELEN NAAR MULTICLOUD EN ELIMINEER AFVALKOSTEN

Sommige organisaties gaan nog een stap verder door de werklast over meerdere cloudproviders te spreiden. Multicloud-projecten bieden extra veerkracht, maar vereisen aanzienlijke complexiteit en technische expertise, evenals potentieel hogere kosten. De sleutel hier is om klein te beginnen en alleen de meest kritieke werklasten of besturingsvlakken naar redundantie te verplaatsen. Zodra u de complexiteit en de daarmee gepaard gaande kosten hebt geëvalueerd, kunt u vervolgens uitbreiden.

De meeste bedrijven zullen multiregionale diversificatie binnen één cloud praktischer vinden, maar welk pad je ook kiest, de mentaliteit moet hetzelfde zijn: ga ervan uit dat er iets kapot gaat en plan dienovereenkomstig.

Even fundamenteel is het identificeren en elimineren van technologisch afval. Niet alle workloads hoeven in de duurste, maximaal beschikbare configuratie te worden uitgevoerd. Door een goede analyse van de bedrijfsimpact kunnen organisaties investeringen afstemmen op risico’s, uitgaven doen waar een mislukking het bedrijf daadwerkelijk zou schaden en bezuinigen waar dat mogelijk is. Voor kleinere bedrijven is dit inzicht in wat bedrijfskritisch is en wat kan wachten om weer online te gaan, van cruciaal belang voor kosteneffectieve veerkracht.

BCDR OM DE VEERKRACHT VAN HET DATACENTER EN HET NETWERK TE BEHEREN

Als uw organisatie zich al heeft gediversifieerd over verschillende geografische regio’s of zelfs over verschillende cloudproviders, is het van cruciaal belang om te erkennen dat veerkracht niet ophoudt bij deze infrastructuurkeuzes. Dit is waar plannen voor bedrijfscontinuïteit en rampenherstel (BCDR) een rol gaan spelen. Diversificatie helpt de blootstelling te verminderen. Maar zonder een beproefd plan om te reageren als er iets misgaat, kan zelfs de best ontworpen omgeving wankelen. Als je overal klaar voor bent, kan niets je in de problemen brengen.

Wat de BCDR-plannen van uw organisatie ook zijn, een eenvoudige manier om uw veerkracht op te bouwen is door ze regelmatig te testen. Netflix maakt gebruik van een tool genaamd Chaos Monkey die willekeurig productie-instanties uitschakelt om ervoor te zorgen dat systemen onverwachte storingen kunnen weerstaan. Het is niet te zeggen hoe of wanneer de Chaos Monkey zal toeslaan. Door opzettelijk chaos in te voeren, moeten teams fouttolerante architecturen bouwen die snel kunnen herstellen en onder stress kunnen blijven functioneren. Dit is een extreem voorbeeld.

Kleinere organisaties kunnen een of twee keer per jaar beginnen met testen en de plannen verfijnen naarmate ze groeien. Grotere organisaties willen dit soort tests mogelijk vaker uitvoeren, bijvoorbeeld elk kwartaal, voordat ze in de voetsporen van Netflix treden. Hoe dan ook, stof uw map af en werk uw plan bij om rekening te houden met elke situatie.

EEN MENTALITEIT VAN VEERKRACHT, KIJKEN NAAR DE TOEKOMST

Net zoals we geen steden op individuele bruggen bouwen, mogen we de digitale economie ook niet verankeren in een handjevol hyperscalerregio’s. De recente storingen bij AWS en Microsoft waren niet de eerste in hun soort, en zullen zeker ook niet de laatste zijn. Het verschil tussen deze en de volgende zal zijn hoe voorbereid de organisaties zijn.

De verborgen kosten van centralisatie zijn niet alleen maar downtime; het is de kwetsbaarheid die inherent is aan moderne digitale systemen. Als u vooraf geen geld uitgeeft aan het ontwerpen van storingen en storingen, zult u op de lange termijn nog meer verliezen. Maar met slimme architectuur en gedisciplineerde investeringen kunnen we de kwetsbaarheid uit het verleden omzetten in toekomstige veerkracht en kosten op de lange termijn besparen.

De volgende verstoring is niet de vraag óf, maar wanneer. De vraag is: ben je er klaar voor of laat je je overrompelen?

Juan Orlandini is hoofd technologie bij Insight Enterprises.

Nieuwsbron

LAAT EEN REACTIE ACHTER

Vul alstublieft uw commentaar in!
Vul hier uw naam in