De belofte van rekenkracht als een utility is mooi, maar met de komst van cloud computing nog lang niet ingewilligd. De functionaliteiten die verschillende cloudplatformen aanbieden, zijn in feite uitwisselbaar. De belofte is dat je net als bij andere utilities, zoals belminuten, internet en stroom, moeiteloos van aanbieder kunt wisselen, maar dat het product en de prijs in wezen niet veel van elkaar verschillen.
Het eenvoudig kunnen switchen tussen cloudproviders is helaas nog toekomstmuziek. Cloud-orchestratie-tools hebben in theorie de potentie om dat mogelijk te maken. Zij bieden namelijk een ‘single pane of glass‘ om eenvoudig prestaties van clouds te meten, prijzen te vergelijken en workloads te verplaatsen op basis van de requirements van de workloads. Dat kan ons een stap dichter bij een vloeibare infrastructuur brengen, maar dat blijkt in de praktijk een moeizaam verhaal.
Migratieproblematiek
Alhoewel grote cloudproviders in de basis allemaal hetzelfde product leveren, verschillen ze in de details nog wel van elkaar. Denk aan een andere interface, dus een andere manier van communiceren met het product. De panelen zijn ook anders, maar vooral de api’s verschillen van elkaar. En dát zorgt voor de grote migratieproblematiek.
Van stroomleverancier wisselen, is met name een administratieve handeling. Je moet een aantal formulieren invullen, maar de daadwerkelijke switch merk je in de praktijk niet. Sterker nog, het daadwerkelijke moment van ‘overgaan’ op de andere leverancier kun je niet eens aanwijzen. Het is namelijk niet zo dat je even zonder stroom zit.
Orchestratie kan er in theorie voor zorgen dat het switchen van cloudprovider net zo makkelijk wordt als het wisselen van stroomleverancier of telecomprovider. Het cloud orchestration-platform (of co-platform) is een abstractielaag en fungeert in wezen als een tolk tussen de infrastructuur en de desbetreffende cloud. De infrastructuur ‘praat’ met de abstractielaag en de tool zorgt ervoor dat de communicatie wordt vertaald naar de taal die de cloudprovider spreekt.
Abstracte droomwereld
In het geval dat alle clouds op elkaar zouden lijken en op dezelfde manier met hetzelfde dialect dezelfde dienst aanbieden, voor een andere prijs bij een andere partij, zou het eenvoudig zijn om goed werkende abstractielaag te ontwikkelen. In deze droomwereld zijn dergelijke co-platformen bezig zijn met de relevante verschillen tussen de cloudplatformen: namelijk de kosten en wat je ervoor krijgt.
De praktijk is echter dat cloudproviders, en dan met name de hyperscalers, snel bewegen. Sommigen lanceren wel tientallen nieuwe diensten per jaar. En al zijn er tegenwoordig zijn genoeg startups te vinden die co-platformen aanbieden, het bouwen is immers relatief eenvoudig. Het onderhoud en beheer hiervan zijn echter bijzonder complex wegens alle wijzigingen bij de cloudplatformen.
Organisaties kunnen er overigens ook voor kiezen hun eigen co-platform ontwikkelen. Zij lopen echter tegen dezelfde problemen als de startups aan: het is haast onmogelijk om alle veranderingen bij te kunnen benen.
Gevirtualiseerde kunstgreep
Een ander signaal dat bedrijven migratieproblematiek ondervinden is het feit dat hyperscalers virtualisatieplatformen binnen hun cloud aanbieden. Het is ook een kunstgreep. De afgelopen maanden werd het draaien van VMware in de Amazon-cloud behoorlijk gepromoot. We hebben het hier over het draaien van een virtualisatieplatform op het platform van een cloud-aanbieder. Een gek verhaal als je het mij vraagt. De behoefte van bedrijven is specifieke applicaties in de cloud kunnen draaien, niet het hele virtualisatieplatform. Dit vereenvoudigt weliswaar de migratie, maar maken zo geen gebruik van de voordelen die een public cloud kan bieden – ze gebruiken immers alleen ‘metal’. Bedrijven betalen echter wel de prijzen die passen bij het gebruik van de public cloud. Daarnaast werken ze in een ecosysteem dat eigenlijk ontwikkeld is voor AWS ‘native’ virtualisatie. Bovendien houdt het de vendor lock-in in stand en is het een stuk duurder dan de alternatieven.
Dit betekent dat migraties voor veel organisaties – van on-premise naar cloud en vice versa of van cloud naar cloud – een uiterst moeizaam traject blijft. Wel geldt daarbij: hoe meer georchestreerd de it van een organisatie, des te soepeler de migraties verlopen.
Stop het in een container
Er zijn naast co-platformen ook andere mogelijkheden om de mobiliteit van workloads tussen clouds te vergroten. Containers kunnen hier bijvoorbeeld een rol in vervullen. Omdat alle afhankelijkheden van de software (de code, de ondersteunende tools en de runtime) in de container zitten, kunnen verschillen op het niveau van de infrastructuur niet meer voor problemen zorgen. Doordat containers onafhankelijk zijn, maakt het een stuk minder uit op welke platform ze draaien. Het is echter wel van belang om als it-afdeling goed samen te werken en te weten waar je aan begint met containerisatie.
Gaia-x is een goed praktijkvoorbeeld van de aanhoudende zoektocht naar uniformiteit tussen cloud-aanbieders. Een samenwerkingsverband van Europese industriepartijen die een tegenwicht te bieden aan de Amerikaanse aanbieders van cloud-oplossingen via een open, federatieve cloud-opzet om datamobiliteit op een veilige manier te realiseren. Het verwezenlijken van niet alleen uniforme api’s, maar ook eenduidige dienstbeschrijvingen en functionaliteit, zou absoluut een bijdrage leveren aan het daadwerkelijk mobiel maken van de infrastructuur.
We kunnen concluderen dat de cloud nu nog niet zo ‘vloeibaar’ is. Gaia-x biedt een hoopvol toekomstperspectief. Het is er alleen nog niet. Tot die tijd moeten organisaties dus goed nadenken over hoe ze clouddiensten afnemen en hoe ze hun infrastructuur daarop inrichten om vendor lock-in en hoge kosten te voorkomen.
Cloud vergelijken met electriciteit uit een gestandaardiseerd stopcontact en water uit een kraan is appels met pet peren vergelijken.
Er is namelijk geen standaard afgesproken voor de eenheid product en geen standaard bij de toepassing daarvan. Bij electriciteit is de standaard voor eenheid product, Watt en de standaardisatie van de toepassing is op alle electrische apparaten mogelijk, doordat er alleen een voeding in het apparaat moet zitten, die het benodigd voltage aanpast. Er worden voor de rest geen eisen gesteld aan de rest van het apparaat, behalve natuurlijk dat de wetten van de electronica volgt. Maar het is niet zo dat het energiebedrijf verteld wat er verplicht in moet zitten. Bij water is dat niet anders.
De cloud levert helemaal geen CPU cycles of iets van dien aard, maar constructen in de vorm van ontworpen ICT-voorzieningen. Op netwerkgebied bieden ze ook constructs in de vorm van SDN (Software Defined Networking). De opslagwereld is wellicht het verst met het bieden van puur en alleen storage, hoewel het niet gestandaardiseerd is. Het is op zijn zachts gezegd vergelijkbaar tussen cloud providers.
Volgens mij komt dat door het business model van de cloud providers. De energiemaatschappijen (overigens flink gepushed door de overheid, middels wetgeving) hebben sinds de liberalisatie van de energiemarkt begin de eeuw juist door consumenten de mogelijkheid te geven om snel en makkelijk over te kunnen stappen van energiemaatschappij, uiteindelijk eieren voor hun geld gekozen en het onderscheidend vermogen is echt niet de kwaliteit van het product. Dat kan ook nauwelijks, want de producteigenschappen zijn dermate gestandaardiseerd dat er geen sprake kan zijn van kwaliteitsverschillen. Dus moet je het wel in prijs zoeken. Een energieleverancier (in het Nederlandse energiemarktmodel) is niets anders dan een broker die wholesale inkoopt en aan consumenten doorverkoopt. Dat doen ze door heel slim in te kopen en te verkopen. De marge is de winst. Het maken van de stroom is voorbehouden van de energieproducenten. Zij zetten gewoon voldoende stroom gezamenlijk op het net zodat een ieder het er af kan halen.
Zover is het nog lang niet met generieke infrastructurele bronnen als CPU power, storage en networking (eigenlijk connectivity). Microsoft, Amazon en Google hebben een ecosysteem, waarin ze je zo lang mogelijk willen houden. Tussen deze partijen en andere belendende partijen zie je zo nu en dan dat ze elkaar het ligt in de ogen niet gunnen en bepaalde toepassingen of voorzieningen niet uitwisselbaar maken. Zolang dit commerciele geweld een belangrijke factor speelt, verwacht ik niet snel dat we tot standaardisatie over te gaan.
Het leidende doel van GAIA-X is het behoud van een soevereiniteit over data voor Europese lidstaten, dat klinkt mij als een Europese poging om de data portabiliteit te verbeteren en niet als een verbetering van de workload portabiliteit. Als je cloud storage als de ballenbak is en dataportabiliteit als het op kleur bij elkaar zoeken van je ballen dan heb je misschien iets niet helemaal goed gedaan in het ontwerp van je data architectuur voordat je de workload naar de cloud bracht. En standaard voorwaarden in de dataverwerkingsovereenkomsten van Amerikaanse hyperscalers hebben niet tot doel om je een makkelijke uitweg te bieden, je ballen worden dus klem gezet. Want het toegankelijk houden van data levert een fantastisch verdienmodel op als je aan de bovenkant van de stack afrekent middels een pay-per-use constructie voor het lezen en schrijven van de gigabytes terwijl je aan onderkant een lineair kostenmodel hebt voor alleen het schrijven.
Nou breekt mijn klomp. Waar is de liftNshift dmv softwaredefined everything ? Oplossing, utopie, dystopie ?
https://www.youtube.com/watch?v=27GgP6BXR6A terug bij af ?
Mondiale innovatie :
– cloud uit USA
– gas uit Rusland
– ziektes uit China
– vluchtelingen uit Syrie
– en het geld naar Griekenland 😉