Waarom multi-cloud waarschijnlijk niet het antwoord is voor veerkracht

Multi-cloud - Het is het hot topic dat hier, daar en overal is. Na enkele spraakmakende storingen zijn bedrijven angstiger dan ooit om al hun eieren in één cloudmandje te hebben en proberen ze ervoor te zorgen dat ze niet het slachtoffer worden van de volgende. Deze chagrijnige cloudarchitect denkt echter dat multi-cloud misschien niet het antwoord is op elk probleem, zoals sommige blogs beweren, en we moeten de basisprincipes opnieuw bekijken met een ouderwetse veerkrachtige architectuur.

Opmerking: hier bespreek ik multi-cloud niet in de hybride cloud on-premise zin, maar eerder in een public cloud context, d.w.z. multi-cloud ⊂ {gcp, aws, azure, ...}, |multi-cloud| > 1

Laten we dat in evenwicht brengen door ons eerst te herinneren dat er enkele scenario's zijn waarin multi-cloud de oplossing is waarnaar u op zoek bent. De beste producten in hun klasse moeten altijd worden gebruikt, ongeacht de specifieke hyperscaler die ze aanbiedt; wie wil er bijvoorbeeld geen BigQuery gebruiken voor analyses, ongeacht waar de rest van je infrastructuur zich bevindt (zoals aangetoond door Monzo)? Bovendien zorgt flexibiliteit in je infrastructuurkeuzes ervoor dat je cloudaccountmanager scherp blijft als het gaat om prijzen en onderhandelingen, zodat je budgethouder en CFO tevreden zijn. Diezelfde flexibiliteit zou je Risk Officer ook moeten helpen om 's nachts beter te slapen.

De veerkracht- en beschikbaarheidsvraag

Nu de beleefdheden uit de weg zijn, kunnen we echt beginnen met de tirade. Ik geloof niet dat het in tweeën splitsen van een oplossing en de ene helft in GCP en de andere helft in A.N. Other plaatsen, de juiste manier is om je veerkracht en uptime te verbeteren voor de overgrote meerderheid van cloudgebruikers.

De huidige tijdgeest van multi-cloud wordt voornamelijk gedreven door de wens om niet offline te gaan wanneer je cloudprovider dat doet, en dit staat nu op de radar van de hoogste regionen van organisaties. Downtime is eng en slecht voor bedrijven, en de hyperscalers zijn niet onfeilbaar; technologie faalt, zompige organische materie drukt op de verkeerde knop - als het kan gebeuren, gebeurt het meestal.

Vluchten naar een andere cloud is echter het aanpakken van het symptoom en niet het probleem. Als je je infrastructuur verliest wanneer een hele regio of zone offline gaat, waarom zou je dan niet dezelfde infrastructuur repliceren in een tweede regio, er zijn er nog veel meer om uit te kiezen - dit bereikt precies dezelfde veerkracht als het gebruik van een tweede cloud, en is waarschijnlijk een stuk eenvoudiger op te zetten en te onderhouden. Je gekozen cloudprovider heeft tal van tools om dit zo eenvoudig mogelijk te maken, van wereldwijde load balancing in GCP tot wereldwijde SQL-databases in AWS en opslag die zich uitstrekt over continenten in Azure. (Of alle drie in GCP).

Offline gaan met je cloudprovider is een fout in redundant ontwerp, die niet automatisch wordt opgelost door een cheque naar een tweede te schrijven.

"Wat als mijn cloudprovider al zijn regio's in de VS verliest?" hoor ik je roepen. "Fail dan naar Europa", roept de afgrond terug. Dit brengt ons bij de kanttekening van dit debat - gereguleerde industrieën. Als je te maken hebt met strikte nalevingsvereisten rond soevereiniteit en je bevindt je in een kleiner land zonder veel keuze voor regio's (bijvoorbeeld het VK of Zwitserland), dan accepteer ik dat multi-cloud misschien de enige optie is om je aantal negens te verhogen.

Een Hot / Hot Cloud

Optie A - voer altijd twee clouds tegelijk uit.

Als we dit ontrafelen, beginnen er problemen te ontstaan, met de laagste gemene deler-infrastructuur bovenaan de lijst. Heeft Pub/Sub dezelfde leveringssemantiek als SQS? Werkt deze operator op zowel GKE als AKS? Kan deze authenticatiemethode werken met zowel API Gateway als Cloud Functions? Implementeert mijn Vertex AI-model naar Cognitive Services? Cloudproviders bieden een reeks tools om je leven zo gemakkelijk mogelijk te maken - probleemloze levering en time-to-deployment zijn een van de grootste toegevoegde waarden en proberen alles te zijn voor alle clouds neutraliseert dit voordeel. Naarmate je op de schaal afglijdt van volledig beheerde services naar cloud-agnostische oplossingen, nemen je infrastructuurbeheerlast en toolingvereisten alleen maar toe, wat op zijn beurt de kosten opdrijft.

Het beheren van de gelijktijdige implementatie in clouds is geen sinecure en vereist extra abstractielagen in je infrastructuur als code, en het toevoegen van cognitieve overhead voor je ontwikkelaars. Tools zoals Anthos en Crossplane zullen je zeker ondersteunen, maar gecontaineriseerde services zijn waarschijnlijk slechts een subset van je totale infrastructuur. Vergeet niet - hoewel het toevoegen van multi-cloudinfrastructuur wiskundig gezien je veerkracht verbetert, is het moeilijker om het goed te doen, en als je het verkeerd doet, zal dit alleen maar de nettowinst ondermijnen en kan het zelfs je veerkracht aantasten.

Routering tussen de clouds is het netelige probleem; per definitie wil je dit niet exclusief in een van beide cloudproviders, wat waarschijnlijk leidt tot het gebruik van een edge-provider zoals Cloudflare of Akamai, maar dan ben je overgeleverd aan de SLA van een enkele edge-provider (die ook niet onfeilbaar is), waardoor we weer terug zijn bij af.

Een Hot / Cold Cloud

Optie B - voer één cloud uit, met een tweede stand-by. Dit is wat in je opkomt als mensen 'multi-cloud' zeggen en er wordt aangenomen dat dit de eenvoudigste setup is.

De abstractie- en laagste gemene deler-infrastructuurpunten van optie A blijven echter bestaan. Bovendien heb je nog een paar nadelen, met de toegevoegde vraag "Hoe koud is koud?". Heb je al je secundaire infrastructuur offline, in welk geval er een doorlooptijd zal zijn om deze online te brengen wanneer de dag aanbreekt, of laat je deze beschikbaar, maar verkleind? Dit brengt 24/7 kosten met zich mee en verhoogt je TCO.

Waar je je ook op dit spectrum bevindt, de secundaire cloud loopt altijd het risico een waakvlam infrastructuur te zijn. Tenzij het elke dag TLC krijgt om gelijke tred te houden met de ontwikkelingen in de primaire setup en aantoont dat het even regelmatig kan worden opgestart, is het zeer waarschijnlijk dat het omvalt wanneer de tijd daar is.

Het gesynchroniseerd houden van de gegevens is een nog moeilijkere taak. Stel je voor dat je een handvol wachtrijen in de lucht hebt, een database of twee, en misschien een sessiecache. Zonder zorgvuldige (en waarschijnlijk kostbare) gegevensreplicatie en synchronisatie, wanneer Azure UK South in een zwart gat verdwijnt, zelfs als je tweede cloud klaar is om te gaan, zal het moeilijk zijn om de stukjes bij elkaar te rapen waar je was. En vergeet niet - je moet de tussentijdse gegevens ook in de andere richting terugkrijgen om vervolgens terug te keren naar de primaire cloud.

De crux van deze optie voor mij is "Je bent goed, maar ben je beter dan Google goed?". Als de compute van een zone om 2 uur 's nachts offline gaat, wat zal er dan waarschijnlijk sneller gebeuren?

• Je kunt je koude cloud online brengen die 3 weken geleden voor het laatst is getest, ervoor zorgen dat de gegevens allemaal coherent zijn en ernaar beginnen te routeren
• Google mobiliseert een SRE-functie van wereldklasse om de computerbronnen terug te brengen

Misschien ben ik een pessimist, of drink ik de Kool-Aid al te lang (waarschijnlijk beide), maar ik zou liever falen naar een mooie, schone statische "We zijn er zo weer" pagina in een bucket dan proberen een complete tweede infrastructuur sneller op te zetten dan een hyperscaler.

Slotopmerkingen

Multi-cloud is een geweldige tool die de consument in staat stelt en mag niet worden afgeschreven in de ruimte van één therapiesessie die dun gesluierd is als een blogpost. Zoals mijn collega, de uitstekende Will Parsons, het beschreef, komt het echter neer op waar je je bevindt op je cloudreis:

• Kan je applicatie überhaupt load-balanced worden? Zo niet, werk dan aan het scheiden van je state- en applicatielaag.
• Bevindt je infrastructuur zich allemaal in één beschikbaarheidszone? Misschien moet je zonegrenzen gaan overschrijden.
• Bevindt je infrastructuur zich allemaal in één regio? Volgende stap, rol het uit naar een tweede.
• Veel regio's die vrolijk wegkwakken? Voeg regio's toe voor zover je nalevingsvereisten dit toelaten - bonuspunten nu je verre klanten verbeterde latenties zullen zien.
• Volledig geografisch verspreid? Als je nog steeds meer negens in je uptime wilt, begin dan nu na te denken over multi-cloud.

En vergeet niet - dit is niet alleen een academische oefening. Voordat je probeert verder te gaan, bewijs jezelf dat je naadloos en automatisch van de ene zone naar de andere kunt falen door middel van DR-oefeningen. Bewijs het dan nog een keer. En nog een keer voor de zekerheid. Hier vind je echte veerkracht, niet alleen door een VM in een tweede cloud te kopen.

Multi-cloud heeft een plaats, maar er is eerst ander fundamenteel werk te doen, dat sneller voordelen zal opleveren en met aanzienlijk minder moeite. Wanneer je de sprong naar multi-cloud waagt, wees dan bereid om te werken op abstractielagen met leveranciersonafhankelijke tooling, waarbij je zorgvuldig moet nadenken over wat er daadwerkelijk draagbaar, reproduceerbaar en beheersbaar zal zijn in verschillende omgevingen. Als je je echter bij stap vier bevindt, voorbij de onvermijdelijke hittedood van het universum, is de kans astronomisch klein dat je cloudprovider de VS, de EU en Azië tegelijkertijd zal verliezen. Zelfs tijdens een van de ergste wereldwijde 'storingen' die in totaal 47 minuten duurde, werd slechts een totaal van ~5% van de Kubernetes-clusters getroffen.

Sinds AWS Tinder en Disney+ platlegde, zijn bedrijven meer dan ooit erop gebrand om niet om dezelfde reden in de schijnwerpers te staan, en multi-cloud wordt vanuit veel hoeken naar voren geschoven als het antwoord. Vaak hebben deze bedrijven echter nog een lange weg te gaan in hun single cloud-reis.

Willem van Ockham vat het perfect samen: "Entiteiten mogen niet zonder noodzaak worden vermenigvuldigd."