Vrijwel elke organisatie heeft inmiddels een cloudstrategie als onderdeel van hun IT-strategie gedefinieerd. Met name enterprises kiezen vaak voor een multi-cloudstrategie, terwijl SaaS-providers, middelgrote ondernemingen en startups veelal kiezen voor single cloud. Maar is een multi-cloudstrategie voor grote ondernemingen altijd de beste keuze? Of gaat de enterprise-CIO wellicht te makkelijk mee met deze trend, vragen Jeroen Jacobs en Edwin van Nuil zich af.

Voor we ingaan op het vraagstuk single cloud versus multi cloud, schetsen we eerst wat trends uit de multi-cloudwereld. De cloudmarkt wordt momenteel gedomineerd door Amazon Web Services (AWS) en Microsoft Azure, met als serieuze derde speler Google Cloud Platform. AWS staat bekend als gericht op developers, op de hoogste mate van innovatie, het grootste ecosysteem. Bovendien is AWS de ‘founder of the cloud’.

Azure kenmerkt zich, zeker op de Nederlandse markt, als min of meer de standaard voor de enterprise-markt. Organisaties met veel Microsoft-workloads, die geen expliciete keuzes maken, groeien vanzelf Azure in. Verder is Azure net als AWS een zeer volwassen cloudplatform en voor veel organisaties ook een passende keuze.

Google Cloud Platform springt in specifieke situaties eruit. Op het gebied van artificial intelligence, machine learing en analytics scoort het goed. Ook drijft Kubernetes veel developers richting Google – alhoewel AWS en Azure eveneens Kubernetes-services aanbieden.

Naast deze dominante top 3 heb je nog IBM, Alibaba en Oracle. IBM Cloud (Softlayer en Bluemix gezamenlijk) worstelt wat met zijn positionering maar zet onder meer in op bare-metal servers. Alibaba-cloud is de equivalent van AWS in China; het is interessant om te volgen hoe dit zich gaat ontwikkelen. Alibaba heeft inmiddels ook een regionale vestiging geopend, in Frankfurt. Oracle zet in op Oracle workloads en lijkt op dit vlak voornamelijk AWS te willen beconcurreren.

Wanneer we de verschillende clouds vergelijken, kunnen we voor de drie grootste stellen dat het echte verschil niet meer zit in de IaaS-diensten. Onderzoek van Gartner toont aan dat alle belangrijke IaaS-gerelateerde features in de grootste platformen vergelijkbaar aanwezig zijn.

Een ‘vendor lock-out’ gaat ten koste van innovatie

Op basis van eigen calculaties kunnen we aanvullend concluderen dat voor de meeste workloads op IaaS de prijsdiversiteit tussen de platformen in een bandbreedte van + of -5 procent zit. Het selecteren van een cloudplatform doe je dus beter op basis van hoger liggende diensten en andere factoren.

In dit kader zien we al jaren de trend ‘FaaS (serverless) boven containers/PaaS boven IaaS’. Bedrijven willen hoger in de services stack komen om meer innovatie, snelheid en efficiency-voordelen te realiseren. Gelijktijdig worstelt menige organisatie nog met de organisatorische kant van de cloud. Opbouw van de kennis, cloud-native gaan beheren via infra-as-code en het onder controle houden van de kosten en compliancy zijn geen sinecures. Binnen deze multi-cloudcontext speelt de vraag single cloud versus multi-cloud.

Figuur 1. Multicloudlandschap – a point of view

Multi cloud-drijfveren

Multi-cloudsituaties kunnen op twee manieren ontstaan. Enerzijds zien we organisaties zonder expliciete strategie. Bijvoorbeeld door het ontbreken van een strategie of vanuit overnames en fusies. Anderzijds zien we organisaties met een bewuste multi-cloudstrategie. Uit een recente inventarisatie onder enterprises met een multi-cloudstrategie worden consequent vijf argumenten voor het hebben van een strategie genoemd. Deze drijfveren zijn:

  • Disaster-recovery
  • Preventie van vendor lock-in
  • Cost efficiency
  • Compliancy
  • Innovatie

Wanneer we kritisch naar deze argumenten kijken, zijn dit zeker niet altijd vanzelfsprekend goede redenen om van daaruit voor een multicloudstrategie te opteren. We ontleden deze argumenten om ons punt helder te maken.

1. Disaster recovery

Om uit te leggen waarom hoge beschikbaarheid en disaster-recovery geen vanzelfsprekende drijfveer zijn voor een multi-cloudstrategie, moeten we kijken naar de principes van beschikbaarheid op public cloud-platformen als AWS en Azure. Dergelijke cloudplatformen bieden het concept van regions en daarbinnen een of meerdere availability zones. Een availability zone dient gemakshalve te worden gezien als een datacenter, hoewel ze meerdere datacenters bevatten. Om hoog beschikbare applicaties te realiseren, dienen applicaties over meerdere availability zones te worden gedeployed.

Vergelijk dit concept met een multi-datacenter-setup. Wanneer dit niet voldoende is, kan worden gekozen voor een multiregion deployment. Gezien regions volledig zelfstandig zijn, bereiken we hiermee eigenlijk hetzelfde als met een multi cloud-deployment. Wanneer we daarnaast naar het verleden kijken, kunnen we stellen dat de grote drie cloudplatformen effectief nog nooit een verstoring hadden die meerdere regions gelijktijdig en volledig platgelegd heeft. Disaster-recovery is dus niet een harde noodzaak om voor multicloud te kiezen.

2. Preventie van vendor lock-in

Een nog vaker genoemd argument voor multi cloud is preventie van vendor lock-in. De grote vraag hierbij is in hoeverre de organisatie ook de ‘SaaS over FaaS over PaaS over IaaS’-strategie volgt. Wanneer minimalisatie van vendor lock-in daadwerkelijk een argument is, zal het aantal services dat voor gebruik op het cloudplatform in aanmerking komt worden beperkt tot primair IaaS en wat database- en containerservices. Hiermee ontstaat dus een ‘vendor lock-out’. De voordelen op het vlak van innovatie en TCO worden niet volledig uitgenut.

Naar onze visie is toegang tot de innovatieve cloudservices juist een van de primaire redenen om naar de public cloud te gaan. Daarbij is het uiteraard nooit verkeerd per applicatie-workload vooraf na te denken over exit en portabiliteit. Voor het wegmigreren van IaaS-servers en databases zijn tal van migratietools beschikbaar. Het wordt spannender bij cloudplatformspecifieke diensten als Queing, serverless, machine-learning en artificial intellinge. We adviseren een exit per cloudservice te beoordelen en te benaderen vanuit applicatiebouwstenen die je zou moeten kunnen herplotten.

3. Prijsefficiency

Sommige organisaties stellen kostenvoordeel te halen bij een multi-cloudstrategie doordat ze een betere onderhandelingspositie hebben tegenover de cloudproviders. Voor de meeste cloudplatformen is dat niet het geval. Het tegendeel is vaak zelfs waar. Er wordt juist meer volumediscount gegeven bij een hogere workload op één platform. Een andere uitleg voor deze drijfveer is dat per workload het meest kosteneffectieve platform kan worden geselecteerd. Dat klopt in de basis, maar zoals we eerder zagen zit het prijsverschil vooral in de inzet van hoger liggende services.

Vergeet daarbij ook niet dat veel diensten in de details lastig vergelijkbaar zijn tussen de providers. Ook is er een keerzijde bij multicloud die juist de kosten opdrijft. Hoe meer platformen, hoe meer complexiteit. Kennis opbouwen en onderhouden over meerdere cloudplatformen heen kost veel tijd en effort. Ook brengen meerdere clouds hogere connectiviteits- en beheerkosten met zich mee. Een kostenvoordeel door de inzet van multi cloud is daarmee een discutabel argument.

4. Innovatie

Meer cloudplatformen bieden gezamenlijk meer variantie in diensten en features, wat innovatie mogelijk maakt. In de basis is dit waar, maar alleen wanneer er volledig wordt ingezet op higher-level services. Er moet dus geen lock-inminimalisatie gelden want dan gaat dit argument niet op. Bovendien moet je als organisatie inhoudelijk van al die diensten technische kennis in huis hebben. Daarnaast is het over het algemeen niet altijd aan te bevelen om applicaties die sterk met elkaar interacteren over meerdere cloudplatformen te verspreiden.

5. Compliancy

Datalocatie en compliancy aanvoeren als argument voor multicloud klopt in specifieke gevallen. Wanneer een organisatie workloads moet kunnen hosten in landen als China, Rusland of Brazilië, dan kom je soms niet onder een lokale cloudprovider uit. In China is bijvoorbeeld de Alibaba-cloud of AWS China (wat losstaat van de rest van AWS) een optie. Generiek kunnen we stellen dat de grote cloudproviders reeds indrukwekkende compliancy-statements dan wel certificeringen afgeven, waarmee datalocatie en databeveiliging over het cloudplatform zelf wordt gegarandeerd. Compliancy op zichzelf is dus ook niet een argument, tenzij je met specifieke landen te maken hebt.

Figuur 2. Concept van availability zones

Voordelen van single cloud

De vijf dominantste argumenten voor multi cloud zijn hiermee in perspectief gezet en gaan als gezien niet altijd op. Daarnaast willen we ook nog even kijken naar de voordelen van single cloud. De crux zit hem daarbij in volledige adoptie. Zoals we eerder stelden is het echte voordeel zowel op financieel vlak als vanuit de innovatie te halen wanneer hogerliggende services worden ingezet. Hiervoor is in-depth kennis nodig van het cloudplatform. Die leercurve succesvol doormaken is realistischer wanneer dat gebeurt op één cloud. Ook het bijhouden van nieuwe ontwikkelingen gaat beter. Met een single cloud wordt tevens meer succes behaald om compliancy en security beheerst te houden.

Multi cloud of single cloud

Zoals we stelden geloven wij in een single-cloudstrategie voor het beste resultaat. We zijn overigens niet tegen multi cloud; maar dan moet het wel gebaseerd zijn op de juiste afwegingen en niet omdat veel bedrijven roepen het te doen. Ga je toch voor multi cloud, zorg dan voor voldoende body in je operations per platform, bijvoorbeeld in de vorm van afzonderlijke AWS- en Azure-Ops-teams.

TCO laat prijsstelling niet het leidende argument zijn

Forceer beide platformen ook niet om technisch gelijk te blijven. Werk met generieke architectuurstatements en requirements, maar probeer niet alles technisch gelijk te trekken.

Probeer ook de workload logisch te verdelen. Bijvoorbeeld: businessunit A gaat voor AWS en businessunit B voor Azure. Wat we vaker zien bij multi cloud is een dominant platform en een tweede cloud, uitsluitend voor specifiek gedefinieerde workloads. Laat prijsstelling niet het leidende argument zijn voor de afwegingen.

Tot slot, wees ook kritisch op cloudmanagementoplossingen. Bekijk het probleem op zichzelf en los dat bij voorkeur op met de platformnative oplossing. Aangezien we adviseren met aparte Ops-teams te werken is er vaak geen noodzaak voor cloudmanagementoplossingen; abstractie verlaagt soms alleen maar de waarde. Blijf dus focussen op hoe het cloudplatform optimale waarde voor de organisatie kan realiseren.

Door Jeroen Jacobs, cloudconsultant, en Edwin van Nuil, managing director bij Oblivion Cloud Control

REAGEREN

Plaats je reactie
Je naam