Uitdagingen bij het overstappen op een multicloud-strategie

Hybride of multi-cloudstrategieën worden door bedrijven om verschillende redenen gebruikt, van juridische tot kostenbesparingen en applicatieflexibiliteit. Bedrijven willen vaak de flexibiliteit om te profiteren van de beste prijzen of mogelijkheden van verschillende leveranciers van openbare cloud. Het vermijden van vendor lock-in is een andere reden waarom een ​​bedrijf een multi-cloudstrategie wenst.

Hoewel een bedrijf misschien niet voor onbepaalde tijd aan één cloudprovider gebonden wil zijn, is de overstap naar een multicloudstrategie niet voor iedereen geschikt. In feite is het risico om gebonden te zijn aan één cloudprovider niet noodzakelijkerwijs het risico dat het vaak wordt gezien.

Dit artikel werpt licht op waarom de overstap naar een multi-cloudstrategie niet voor iedereen weggelegd is, en de barrières en uitdagingen die moeten worden overwonnen als dit een optie is.

Niet alle wolken zijn hetzelfde

In theorie kan een applicatie worden verspreid over meerdere cloudprovidersomgevingen, maar "True Application Portability" houdt barrières in die moeten worden overwonnen voordat de app draagbaar wordt of echt multi-cloud-enabled wordt.

Ten eerste moeten virtuele machines (VM's) uit de applicatiearchitectuur worden verwijderd. Niet alle wolken zijn hetzelfde onder de dekens. Elke cloud heeft zijn eigen onderliggende abstractielaag, vaak de Cloud Service Fabric genoemd, hier worden netwerk, rekenkracht en opslag gepresenteerd aan de VM die meestal wordt gebruikt om applicaties te hosten. AWS Networking is bijvoorbeeld aanzienlijk anders dan Microsoft Azure Networking en op hun beurt zowel AWS als Azure Networking verschillen qua opzet aanzienlijk van GCP Networking. Hetzelfde geldt voor virtuele machines, een VM die draait op Azure kan niet automatisch worden verplaatst naar AWS en een AWS VM kan niet rechtstreeks worden verplaatst naar GCP.

Als een VM moet worden verplaatst naar een nieuwe cloudprovider, moet de VM-image worden aangepast om overeen te komen met de cloudfabric van het onderliggende doelplatform. Compute- en opslagaanbiedingen verschillen tussen cloudproviders en bieden vaak hun eigen uitdagingen met betrekking tot applicatieportabiliteit. Deze problemen worden nog verergerd als de toepassing gebruikmaakt van Platform-as-a-Service (PaaS)-aanbiedingen, bijvoorbeeld Database-as-a-service (DBaaS), WebApps of message broker-componenten waarbij de onderliggende gegevensopslagelementen, websiteleveringsmechanismen en applicatielogica zijn eigendom van dat specifieke cloudaanbod.

Als de applicatie Functions-as-a-Service (FaaS) gebruikt (cloudservices die een geautomatiseerd platform bieden waarmee klanten applicatiefunctionaliteiten kunnen ontwikkelen, uitvoeren en beheren zonder de complexiteit van het zelf bouwen en onderhouden van de infrastructuur), dan wordt de taak van overdraagbaarheid nog complexer omdat de FaaS-nuances van elke cloud weer specifiek zijn voor de cloudprovider.

Maar als VM's, PaaS en (serverloze) FaaS-architecturen niet beschikbaar zijn, wat kan een ontwikkelaar dan doen?

De multi-cloud-uitdaging doorbreken

Dit interoperabiliteitsprobleem tussen clouds kan worden gezien als het probleem dat een internationale reiziger heeft wanneer hij zijn laptop in verschillende landen wil opladen. Je hebt ofwel een stekker voor elk stroomsysteem (dus een voor het VK, een voor Europa en een voor de VS) of je hebt een adapter die overal werkt.

Voor applicatiearchitectuur zou die adapter een product zijn als Docker, een containerframework dat hetzelfde is, ongeacht op welke cloud het zich bevindt. Het containeriseren van een bestaande applicatie is echter niet per se eenvoudig of kosteneffectief. Containers zijn een lichtgewicht hostingarchitectuur die is ontworpen om snel op te starten en af ​​te sluiten, en kan worden geschaald om resources direct aan de vraag aan te passen. Met containers betaalt u het minste en haalt u het meeste uit uw cloud. Hoe zwaarder een container, hoe minder draagbaar.

Uitdaging één: een applicatie opsplitsen in microservices

Om containers op schaal in elke cloud te kunnen draaien, moet u eerst de applicatie opsplitsen in kleine componenten, microservices genaamd. Elke microservice heeft zijn eigen container. Microservices zijn discrete mogelijkheden binnen een applicatie die, wanneer ze worden samengevoegd, een grotere, complexere applicatie aan de gebruiker presenteren. Als we bijvoorbeeld kijken naar een eenvoudige e-commercetoepassing met: een website, een database met klantvoorkeuren, een catalogus met te koop aangeboden goederen en een betalingsmogelijkheid, dan zou dat minimaal vier microservices binnen zijn architectuur vereisen. Als u vervolgens betalingsmeldingen en afhandelingsberichten aan een magazijn zou toevoegen om de goederen te leveren, zou u ten minste zes microservices nodig hebben. En zo gaat het maar door. Elke nieuwe applicatiefunctie vereist zijn eigen servicecomponenten.

Het is duur en tijdrovend om een ​​bestaande applicatie over te nemen en deze op te splitsen in een op microservices gebaseerde architectuur. Maar het is een eerste vereiste voor de portabiliteit van applicaties, omdat de container de universele adapter is.

Uitdaging twee: een orchestrator toepassen om gecontaineriseerde applicaties uit te voeren

Helaas stopt het verhaal daar niet. Om een ​​complexe gecontaineriseerde applicatie uit te voeren, hebt u één essentieel onderdeel nodig - een orchestrator - die uw containers bewaakt en beheert. De Orchestrator begrijpt de algemene architectuur van microservices, inclusief welke containers, en hoeveel ervan, een specifieke toepassing vormen. Het kan elke container vertellen waar de andere containers te vinden zijn die worden gebruikt om de applicatie te leveren. De meest gebruikelijke orchestrator voor het leveren van gecontaineriseerde applicaties is Kubernetes, dat vrij complex is om te bedienen.

Het opsplitsen van de applicatie in microservices is de grootste belemmering om multi-cloud-enabled te worden. U vermijdt misschien vendor lock-in van een enkele cloudprovider, maar u zult nog steeds "vastzitten" aan docker en degene die de Kubernetes-mogelijkheden biedt die u gebruikt om uw op microservices gebaseerde applicatie te orkestreren. Vendor lock-in op een bepaald niveau is helaas een feit van het leven, u hoeft alleen maar te beslissen op welk niveau u wilt dat die lock-in plaatsvindt.

Uitdaging drie: het is buitengewoon moeilijk om lock-in van cloudleveranciers te vermijden

Als kosten uw zorg zijn, moet u gebruikmaken van PaaS- of FaaS-mogelijkheden in de cloud. Hoewel beide services goedkoper zijn om te gebruiken, verhogen ze uw mate van afhankelijkheid van de door u gekozen cloudprovider. Als u op FaaS of PaaS vertrouwt en de leverancier besluit deze services buiten gebruik te stellen of te wijzigen, bent u op zijn beurt gedwongen om de services die erop vertrouwen opnieuw te bewerken. U zit vast in de upgradecyclus van de provider en in hun technologie!

Tenzij uw applicatie al op microservices is gebaseerd, zal de herontwikkelingsinspanning ruimschoots opwegen tegen de kostenbesparingen die worden gemaakt door het gebruik van één enkele cloudprovider. Bovendien, als het een commerciële, kant-en-klare softwaretoepassing is, bent u volledig overgeleverd aan de softwareleverancier om te bepalen wanneer en of ze ooit van plan zijn de software om te zetten in een op microservices gebaseerde architectuur die geschikt is voor containerisatie en Kubernetes-levering.

Een cloud gebruiken die het beste is voor elke workload

Bij de meeste multi-cloudstrategieën die tegenwoordig worden gebruikt, wordt geen enkele applicatie over meerdere clouds uitgerekt (zie hierboven). Het is veel beter om u te concentreren op het benutten van de sterke punten en kostenvoordelen van het uitvoeren van de workloads die het best zijn afgestemd op die cloud. Als u bijvoorbeeld uw eigen software bouwt door Open-Source-mogelijkheden samen te voegen met een DevOps-basis, zult u die werklast waarschijnlijk op AWS uitvoeren. Als u enorme hoeveelheden rekenkracht nodig heeft om wetenschappelijke of statistische modellen uit te voeren, doet u dat waarschijnlijk op GCP, of als u zich zorgen maakt over de informatiebeveiliging, kunt u ervoor kiezen om die uit te voeren in Microsoft Azuurblauw. (Disclaimer: elke genoemde cloudprovider zal graag uitleggen waarom hun deel van de cloud supergeweldig is voor elk van de hierboven genoemde workloads - de stereotiepe labels vervagen naarmate de mogelijkheden volwassener worden - hoewel...).

Er zijn drie belangrijke overwegingen die u moet maken voordat u uw cloudservice verplaatst.

1. Het vermijden van downtime is een belangrijke overweging

Veel leverancierspecifieke services worden geleverd vanuit afzonderlijke regio's binnen een cloud, maar worden aan meerdere regio's gepresenteerd alsof ze eigen zijn aan die regio. Sommige recente spraakmakende AWS- en Azure-storingen zijn terug te voeren op specifieke storingen in een of twee datacenters in de VS - wees voorzichtig op welke services en regio's u vertrouwt. Gecentraliseerde DNS en authenticatie zijn de levensader van applicaties, dus misschien wilt u veerkracht inbouwen voor deze kritieke services. Een ding om op te merken is dat Hyperscaler-storingen zeldzaam zijn en als ze zich voordoen, worden ze vaak veel sneller opgelost dan traditionele IT-storingen in een on-premises datacenter. Als een storing meerdere klanten treft, kunt u er zeker van zijn dat de cloudprovider analyseert hoe de storing is begonnen en hoe deze kan worden voorkomen, wat vaak betekent dat u moet investeren om de service veerkrachtiger te maken.

2. Maak architecturen en applicaties geografisch veerkrachtig

Gedistribueerd verbruik van services moet worden geleverd vanuit ten minste twee regionale datacenters, waarbij de gegevens dicht bij de plaats blijven waar ze worden verbruikt, waardoor de latentie voor gebruikers wordt verminderd. Alle hyperscale cloudproviders hebben een goede regionale verdeling van datacenters, dus dit is niet per se een reden voor een multi-vendor cloudstrategie, het is gewoon een eenvoudige best practice om een ​​storing in een enkel datacenter te voorkomen die alle gebruikers in die regio treft .

3. Het beveiligen van meerdere clouds is altijd veel complexer dan het beveiligen van een cloudarchitectuur van één leverancier.

Maak gebruik van CIS-benchmarks (Center for Internet Security) voor cyberweerbaarheid, gebruik multi-factor authenticatie en als u naar de cloud verhuist, gebruik dan één SIEM-systeem dat in één console in de gaten houdt wat er in elke omgeving gebeurt. Als u geen realtime zicht op uw omgeving heeft, zal het moeilijk zijn om verdachte activiteiten op te sporen en zult u nooit een aanval zien terwijl deze plaatsvindt. Dit betekent dat de aangerichte schade altijd aanzienlijk hoger zal zijn dan wanneer u de zaken in realtime zou monitoren. Uiteindelijk groeien openbare en multi-cloudomgevingen verder dan de menselijke schaal om te monitoren en te beheren. Dit is waar cloud-agnostisch applicatieresourcebeheer (ARM), geavanceerde observeerbaarheid en uitgebreide detectie- en responssystemen (XDR), gevoed door kunstmatige intelligentie, de geautomatiseerde optimalisatie, herstel en bescherming mogelijk maken die handmatige menselijke inspanningen nooit zullen bereiken.

Samengevat

Ik raad een organisatie altijd aan om te beginnen met één cloudprovider en vaardig te worden in het gebruik van de native tooling en services van die provider. Naarmate de organisatie het gebruik van de cloud volwassener maakt en alle aspecten van het bedienen en gebruiken van de mogelijkheden van die cloudprovider onder de knie heeft, kan het beginnen te beoordelen welke echte voordelen kunnen worden behaald door over te stappen op een multi-cloudstrategie. Probeer de oceaan niet aan de kook te brengen - het is beter een expert te zijn op elke wolk dan een generalist op meerdere wolken. Toolsets van derden zijn vereist voor multi-cloudstrategieën, maar native toolsets van leveranciers hebben meestal een completere set functies voor de cloudmogelijkheden van die leverancier.