1. Het zakelijke perspectief
Veel bedrijven hebben hun eigen motivatie om een multi cloud strategie te overwegen. De aanleiding hiervoor kan van diverse aard zijn. Dit kan zijn omwille van bepaalde klantvereisten, vanwege risicospreiding of investeringen in een nieuwe markt. Of soms willen klanten dat hun oplossing op een specifieke cloud draait (vanwege bijvoorbeeld compliance overwegingen).
Wanneer bij dit soort verzoeken de financiële middelen voorhanden zijn kan een bedrijf kiezen voor een multi cloud strategie. Het meest gangbare multi cloud scenario is de SaaS-provider die zijn oplossing in verschillende clouds wil hosten of de Enterprise die simpelweg zijn eigen resources over meerdere clouds wil verspreiden. Uiteindelijk komen de ‘use cases’ grotendeels overeen. Dit betekent dat je voor beide cloudplatforms je kostbeheer moet managen, dient te monitoren, moet beveiligen en daarnaast voor beide op de hoogte moet blijven van de nieuwe features, wijzigingen en afschrijvingen. Iets om goed in de gaten te houden.
Of dit betekent dat je IT-afdeling dan maar direct zal moeten uitbreiden bij multi cloud? Niet perse, maar het zal wel meer inspanning en beheeruitdagingen vergen, omdat je de risico's immers beperkt wilt houden. Beseffen dat het dus tijd en focus zal kosten is hier wel van belang. Helaas worden de technische implicaties vaak over het hoofd gezien. Zo kan kiezen voor multi cloud beperkingen met zich meebrengen voor het aantal verschillende technologieën die je kunt inzetten.
2. Het technologisch perspectief
Wanneer we kijken naar de grotere clouds (Azure, AWS en GCP) dan zien we al snel dat multi cloud niet enkel een invloed heeft op de hostingpartij, maar ook op verschillende technologie stacks.
Want hoewel elke cloud zijn virtuele machines mag hebben, houden de overeenkomsten daar dan ook gelijk op. Immers, wanneer je een publieke cloud gebruikt wil je het liefst de functies ervan overnemen omdat daarmee de beste efficiëntie, schaalbaarheid en veiligheid kan worden geleverd. De tijden waarin het "optillen en verplaatsen" van de ‘current workloads’ van een lokale hostingprovider naar een publieke cloud nog aan de orde was zijn immers echt voorbij. Howel deze migraties nog steeds voorkomen, gebeurt dit niet meer in zo’n mate dat iedereen zich haast om zijn workloads in de cloud te hosten.
We optimaliseren om die reden onze software-architecture voor de bepaalde cloud waarin we hosten. Bijvoorbeeld: investeren in aanpassingen van de oplossing (zodat we Azure Key Vault kunnen gebruiken) of aanpassingen in de code (om de Blob Storage SDK's te gebruiken) om te integreren met Azure Storage Accounts.
Als onze oplossing momenteel draait in Microsoft Azure en we communiceren met opslagaccounts, zal dat een probleem opleveren wanneer onze oplossing op AWS host. S3 buckets en Azure Storage accounts zijn immers verschillende technologieën.
Dit betekent vanuit een softwareperspectief dat we in onze oplossing verschillende opslagtypes moeten laten ondersteunen. Je kunt dit zeker regelen met code en door ervoor te zorgen dat de oplossing zich identificeert de cloud waarin hij draait. Op die manier wordt de juiste opslagconnector gebruikt. Als alternatief kan je meerdere codebases onderhouden, maar laten we eerlijk zijn: niemand wil dat echt.
Dit is de uitdaging bekeken vanuit een technisch perspectief over multicloud. Voor Platform as a Service-oplossingen kan multicloud zeker een grote uitdaging zijn. Je bent beperkt in wat je aan technologie kunt inzetten specifiek bedoeld voor de multi cloud en daarnaast vergt het veel development tijd en aandacht.
3. Het helicopter view perspectief: 'het hangt ervan af'
Tenslotte het overview perspectief. Want hoewel we de elementen noemden om op te letten en die mis kunnen gaan, als we het hebben over wat als 'je jouw oplossing in containers zou draaien en platforms als Kubernetes inzet?'
Dan lijkt het multi cloud idee ineens een stuk minder vergezocht is het niet?
Kubernetes en elke grote publieke cloud heeft zijn eigen implementatie, meestal verkocht als een "managed offering". Vaak betekent dit dat de Public Cloud er zelf voor zorgt dat je control plane draait terwijl jij je richt op de andere Ops en Development taken. Met oplossingen als Azure Kubernetes Service is het daarnaast zelfs mogelijk om native Azure oplossingen als Azure Key Vault of bijvoorbeeld Azure Active Directory te integreren. Dit betekent dat je zelfs met Kubernetes al een cloud specifieke configuratie hebt.
De uitdaging zit hem dan ook in het beperken van de configuratiedrift tussen clouds. Vanuit een Ops perspectief wil je je immers het liefst focussen op GitOps oplossingen als Flux (Flux (fluxcd.io)) of ArgoCD (Argo CD | Argo (argoproj.github.io)).
Vanuit een development perspectief kan je oplossingen als Dapr (Dapr - Distributed Application Runtime), inzetten, waarbij een middenlaag wordt geboden om je cloud zo agnostisch mogelijk te latenkzijn. Het bovenstaande zijn slechts voorbeelden. Multicloud is vanuit technologisch oogpunt zeker mogelijk, maar het vergt wel wat denkwerk en nog belangrijker: een zeer nauwe en goede samenwerking tussen het Development- en Operations-teams.
Samenvattend
Multi Cloud is niet langer een buzz word, steeds meer bedrijven kiezen voor deze strategie.
Wat we geleerd hebben is dat een multi cloud strategie heel goed realiseerbaar is maar dat er op alle niveaus wel over nagedacht moet worden. Er moet goede overeenstemming zijn tussen de business en de techniek. Op die manier worden de risico's beperkt en is zowel het applicatie / software als business model er klaar voor om op meerdere clouds te draaien :)