Even afrekenen bij retransitie! Exit en transitie in het cloudtijdperk

 
14 juni 2019

Interview Bart Veldhuis, Weolcan 

In dit cloudtijdperk stellen serviceproviders zich op als partners die, al dan niet vanuit agnostische ecosystemen van oplossingen, de klant helpen bij een zachte landing. We worden verleid met schaalbare en flexibele infrastructuren. Bij een eerste migratie naar de cloud weten we niet veel beter. Maar bij een migratie van de ene naar de andere cloud, bij een wisseling van serviceprovider of bij de combinatie van beide moeten uitbesteders extra goed op hun tellen letten. De relatie tussen kostenvoordeel en lock-in is omgekeerd evenredig, aldus Bart Veldhuis, cloudarchitect bij Weolcan.

In 2014 publiceerde Giarte in Outsourcing Performance een veelgelezen artikel over exits en retransities. Aanleiding: de overstap van de ene naar de andere serviceprovider verliep niet altijd naar wens. De meest pijnlijke problemen van toen zijn nu nog steeds actueel: tegen de tijd dat duidelijk wordt dat er een nieuwe serviceprovider in aantocht is, worden bij de latende provider de meest ervaren medewerkers overgeplaatst naar andere klantteams. Documentatie blijkt niet voorhanden of upto- date. Er ontstaan discussies over het intellectueel eigendom van IT-voorzieningen. De communicatie verzakelijkt en verloopt niet meer tussen professionals, maar tussen managers. Enzovoorts. “Je zou verwachten dat dit soort problemen grotendeels tot het verleden behoren. Maar het lijkt erop dat alles wat Giarte destijds aan lessons learned heeft opgeschreven, door serviceproviders wordt gebruikt om retransities naar hun hand te zetten of alsnog rendabel te maken”, aldus Bart Veldhuis. Hij waarschuwt: nu bedrijven hun IT naar de publieke cloud verplaatsen, nemen de kansen op een tijdrovende en kostbare exit alleen maar toe.

Bart Veldhuis

 

Wendbaarheid

De cloud heeft voor uitbesteders meerdere dimensies, aldus Veldhuis. “Op de eerste plaats is het een oplossing voor het vergroten van de wendbaarheid zoals het verlagen van de kosten. Maar de cloud wordt ook gezien als een generieke, gestandaardiseerde omgeving, die organisaties minder afhankelijk maakt van retransities. Het idee is dan dat de uitbesteder van serviceprovider kan verwisselen, terwijl daarbij de volledige stack in Amazon Web Services (AWS) of Azure kan blijven staan.” Hoewel sommige uitbesteders in eerste Instantie een deal met een generieke cloudaanbieder – AWS, Azure – sluiten en daar in tweede instantie een gespecialiseerde serviceprovider bij zoeken, migreren de meeste bedrijven met de hulp van een serviceprovider naar de cloud. Ongeacht die route – eerst cloudplatform of eerst provider kiezen – is van belang dat de serviceprovider vrijwel altijd specifieke zaken toevoegt aan de cloudomgeving: denk aan methodes, scripts en portals. Dat zijn elementen met een voor de uitbesteder hoge toegevoegde waarde, omdat het vaak om skills gaat die je zelf nog niet in huis hebt. Wanneer je aan het einde van een contractperiode wilt veranderen van dienstverlener, kan die cloudgerelateerde lock-in grote gevolgen hebben.

De ene cloud is andere niet

Naarmate je meer gebruik maakt van die provider-specifieke cloudvoorzieningen, zal deze meer diensten geautomatiseerd kunnen leveren en zal het (kosten)voordeel dat de provider biedt verder oplopen. Maar de keerzijde is dat je kans op een lock-in ook toeneemt, zo legt Veldhuis uit.
“Naarmate je hoger in de stack komt, worden deze effecten sterker. Elastic search werkt anders bij AWS dan search bij Azure. Een verandering van cloud vraagt op dit vlak dus om aanpassingen. Wanneer je de cloud alleen als IaaS-oplossing gebruikt, is het risico op lock-in gering. Toch moet je ook bij IaaS niet verwachten dat de cloud ‘universeel’ is. Bij IaaS- diensten kun je alleen relatief gemakkelijk van provider wisselen als je je documenten en je assets volledig in kaart hebt.”

Ontmantelen en weer opbouwen

Anders wordt het wanneer je gebruik gaat maken van geautomatiseerde bouwblokken van de cloudprovider – denk aan PaaS-diensten zoals een managed database, waarmee je je beheerkosten kunt terugdringen. Veldhuis: “Bij de transitie van een database van AWS naar Azure zal je de nodige maatregelen moeten treffen. Je zult bij verandering van serviceprovider alles moeten ontmantelen bij de latende, en opnieuw moeten opbouwen bij de winnende provider. Het datalake dat je hebt opgebouwd in de cloud, kan dus niet zomaar over. Hiervoor zal de latende serviceprovider aan het werk moeten. Dat kost veel tijd en geld. Nog hoger in de stack – denk aan cloud native applicaties (op basis van microservices) die je zelf hebt ontwikkeld en geïntegreerd – betaal je per transactievolume een gering bedrag, dus bij aanzienlijke schaalgrootte zijn je voordelen op het vlak van beheer omvangrijk. Maar meer maatwerk zorgt hier voor een veel grotere lockin. Je retransitie kost meer tijd en zal duurder uitpakken. Met andere woorden: het financiële voordeel dat je verwacht, zal je moeten afzetten tegen hogere retransitiekosten.”

“Tegenover het profijt dat je hebt van het inkoopvoordeel en de toevoegde waarde van een serviceprovider staat dat de Azureomgeving van de ene serviceprovider niet hetzelfde is als de Azure-omgeving van een andere serviceprovider. Vaak is de publieke cloud niet de enige omgeving waarmee je te maken hebt. Die toegevoegde waarde, al dan niet in de vorm van providerspecifieke tooling, komt vaak ook terecht in de cloud-omgevingen van bijvoorbeeld SAP, Oracle of Salesforce.”

Verschillen gaan niet alleen over techniek

De verschillen in techniek zitten met name in de functionaliteit van cloudportals. Veldhuis legt uit: “Een voorbeeld is het toekennen van budgetten aan teams. In het generieke portal van Azure is dat goed te regelen. In het portal dat de serviceprovider beschikbaar stelt, kan zo’n functie afwezig zijn. Er zijn serviceproviders die cloudagnostische provisioning tools leveren. Daarmee kun je gemakkelijk zelf kiezen tussen Azure of AWS en heb je een uniform proces om software naar de productieomgeving in de cloud te brengen. Maar daar staat tegenover dat je met zo’n providerspecifiek doch cloudagnostisch portal niet zomaar naar een andere provider kunt.”

“Het ideaal is natuurlijk dat een verandering van serviceprovider geen impact heeft op de clouddiensten die je afneemt. Ofwel: dat je tegen je cloudprovider kunt zeggen: ‘We gaan van serviceprovider A naar serviceprovider B, zorgen jullie ervoor dat de boel (administratief) wordt omgezet?’ In de praktijk zal je vooraf – dus ook bij de eerste cloudmigratie – al een plan moeten ontwikkelen voor de exit. Dat begint bij een goede afweging: hoe diep ga je de cloudstack in? Sommige uitbesteders besluiten daarom bijvoorbeeld om niet méér af te nemen dan PaaS-diensten. Of ze ontwikkelen een eigen platform in de cloud. Als organisatie kun je trouwens ook zelf rechtstreeks zaken doen met een cloudprovider.”

Toekomst

Cloudomgevingen vertonen intrinsieke verschillen en daarnaast gieten serviceproviders er graag hun eigen sausje overheen. Veldhuis verwacht dat er regulering komt die een lock-in moet verhinderen, zodat cloudadoptie wordt vergroot. “We hebben het in feite over cloudportabiliteit. Daarbij gaat het met name om PaaS en Functions as a Service (Faas). De kans is groot dat de EU eerst inzet op kaders waarmee de markt op basis van zelfregulering aan de slag moet. Ik vermoed dat providers daarna relatief snel zullen roepen dat ze ook op dit vlak compliant zijn, maar dat de technische realisatie daarvan achterblijft. Een vergelijkbaar vraagstuk hebben we gezien rondom de regulering van retransitie. Daarvoor is in 2016 ISO 19086 ontwikkeld, een norm die voorschrijft dat een retransitie ‘ordentelijk moet verlopen’. De klant moet bijvoorbeeld zijn data terugkrijgen en de provider moet de data binnen bepaalde tijdsperioden verwijderen. Serviceproviders die aangeven dat ze ISO 19086 compliant zijn, nemen deze richtlijnen echter niet altijd mee in hun SLA’s. Hoeveel tijd heb je dan om je data terug te halen en veilig op een andere plek onder te brengen?”

Tips

1. Het financiële voordeel dat je denkt te krijgen moet je afzetten tegen de kosten van een lock-in. Die afweging heeft onder meer te maken met het volume dat je denkt af te nemen. Wanneer bewegingsvrijheid van strategisch belang is, kan het beperkte inkoopvoordeel van zelf inkopen van cloudcapaciteit ruimschoots opwegen tegen het grotere inkoopvoordeel dat een serviceprovider wellicht met je wil delen.

2. Ga bewust om met de tooling die de provider aanbiedt; denk aan oplossingen zoals cloudportals. Hoe handig ze ook lijken en hoe groot de meerwaarde ook lijkt, ga ze niet klakkeloos gebruiken. Breng eerst in kaart in welke mate ze cloudplatform- en serviceprovider-gebonden zijn, ga vooraf na wat er gebeurt als je van provider verandert en let met name op de documentatie over jouw IT-omgeving die vaak in deze portals opgeslagen zit.

3. Je serviceprovider gebruikt voor het aansturen van de clouddiensten grote hoeveelheden scripts. Die scripts heb je nodig bij een transitie. Als cloudgebruiker moet je bij aanvang afspraken maken over inzage in, toegang tot en kosten van de automatiseringsrepositories die door je serviceproviders worden gemaakt.

4. Je eigen DevOps-teams zullen gebruik willen maken van geautomatiseerde clouddiensten – denk aan het beschikbaar stellen van VM’s. Je wilt bijvoorbeeld op vrijdagmiddag direct én veilig kunnen beginnen met experimenteren met Microsoft Cortana om te ontdekken wat dat kan betekenen voor consumenten die je app gebruiken. Procedures met tickets en servicedesks zorgen dan voor vertraging. Een overweging kan zijn om voor ontwikkelwerk geen providerportal te gebruiken, maar rechtstreeks gebruik te maken van de native portals van Azure of AWS .

5. Houd rekening met conversiekosten. Clouds zijn onderling niet compatible: iets wat draait in Azure, draait niet vanzelfsprekend in AWS . Je zult dan content moeten converteren. Er komen nu cloudproviders die services op dit vlak ontwikkelen, maar op dit moment gaat dat vooral nog om standaarddiensten laag in de stack, dus niet voor platformdiensten zoals databases.

6. Neem in het contract bepalingen op over beloning voor de latende serviceprovider, die gekoppeld is aan een goede retransitie. Denk hierbij aan het beschikbaar houden van sleutelfiguren voor het kernteam totdat de retransitie is afgerond, zodat er geen kennisdrain, maar kennisoverdracht plaatsvindt en communicatie tussen op elkaar ingespeelde professionals de standaard blijft. Neem in het transitieteam ook experts op van de nieuwe dienstverlener.

7. Houd er rekening mee dat een gestructureerde exit niet het enige scenario is. Er kan ook een noodplan nodig zijn. Steeds vaker worden snelle groeiers in IT-land via overnames door private equity overladen met schulden. Wat gebeurt er met je cloudvoorwaarden als jouw serviceprovider niet aan de betalingsverplichtingen kan voldoen? Wat gebeurt er als je cloudprovider te maken krijgt met ernstige datalekken? Dit soort risico’s kan in kaart worden gebracht in een cloud-risicomodel.