Wat is een cloud exit strategie precies en hoe voer je het uit?

Als we praten over Cloud, praten we meestal over de weg er naartoe. Maar in sommige gevallen wil je er vooral úit. Niet omdat die digitale transformatie niets voor jou is, maar bijvoorbeeld omdat er structurele problemen zijn met je provider of wanneer je grote beveiligingsrisico’s vermoedt. In dit soort situaties is het belangrijk dat je een plan klaar hebt liggen. Dit noemen we een cloud exit strategie. In dit artikel lees je hoe zo’n plan is opgebouwd, wat veel voorkomende redenen zijn om ‘m te gebruiken én hoe je je voorbereidt op de daadwerkelijke exit. Maar ook: wat er voor jou als cloudklant is geregeld en door welke partijen.

Wat is een cloud exit strategie (en wat niet)?

Een cloud exit strategie (ook wel retransitieplan) heb je nodig voor het uitvoeren van een beheerste en gecontroleerde beweging uit een cloud- of outsourcingomgeving. Het plan bestaat uit afspraken over werkwijzen en communicatie- en governancestructuren die samen een geordend vertrek mogelijk maken. Hoewel een cloud exit strategie grote gelijkenissen kent met het calamiteitenplan (disaster recovery plan) is er toch een opmerkelijk verschil in de uitvoering:

• Een calamiteitenplan treedt in werking na een onherstelbaar verlies van dienstverlening en kent een zeer korte doorlooptijd. Bij een calamiteit wijk je doorgaans uit naar een ander datacenter of zelfs andere regio, maar wel van dezelfde provider. Of in cloud-termen: bij een calamiteit in de regio Noord-Europa wijk je uit naar West-Europa, maar blijf je binnen hetzelfde dienstenportfolio en dezelfde technologiestack.
• In het geval van een cloud exit strategy spreken we over scenario’s die zich doorgaans wat langer van tevoren aankondigen en waar na een poging tot migitatie uiteindelijk wordt besloten om te vertrekken bij de provider. Een exit is gecompliceerd in die zin dat een wisseling van technologiestack consequenties heeft voor People, Processes & Technology.

Waarom zou je de Cloud weer uít gaan?

Er zijn veel scenario’s denkbaar die een exit in werking doen treden. Niet alle redenen zijn vooraf te voorzien en je moet er ook rekening mee houden dat scenario’s zich slechts deels of zelfs gecombineerd voordoen.

Let op: deze lijst is aangescherpt en minder relevante risico’s zijn weggehaald. Opgenomen in de lijst is het concentratierisico: stel je de situatie voor waarbij meerdere grote ziekenhuizen hun patiëntinformatie bij dezelfde CSP onderbrengen, of denk aan grote banken die hun software draaien vanuit dezelfde cloud.

Hoe realistisch zijn deze aanleidingen?

Zijn de punten in bovenstaande top 10 realistische scenario’s? Jazeker! Neem bijvoorbeeld item #1, de juridische context. Grote providers zoals Amazon, Azure en Google hebben in hun contracten voorwaarden opgenomen waarmee ze eenzijdig de overeenkomsten en service levels kunnen wijzigen. Neem bijvoorbeeld onderstaand fragment uit de overeenkomst van Amazon:

Hier staat duidelijk dat Amazon de dienst, na een melding aan de gebruikers, compleet mag wijzigen, inclusief het stopzetten van een deeldienst. En als dat commercieel onhandig uitkomt, hoeven ze dat niet eens 12 maanden van tevoren te melden.

En wat dacht je van dit fragment over de Service Level Agreements:

Het Service Level Agreement mag dus eenzijdig door de Cloud Service Provider (CSP) worden gewijzigd zonder opgaaf van reden.

Hier moet wel bij gezegd worden dat sinds de eerste publicatie van dit artikel (2015) de contract-documenten van de grote hyperscale cloudproviders significant beter zijn geworden. De door de CSP’s opgetrokken vaagheid en ondoorzichtigheid blijven echter evengoed in stand.          

Heb je altijd een cloud exit strategie nodig?

In sommige gevallen moet je als organisatie een exit strategie hebben. Bijvoorbeeld als dat geëist wordt door de toezichthouder of als het onderdeel uitmaakt van je Informatie Security Management Systeem zoals voor de ISO 27001. In andere gevallen is het verstandig om van tevoren na te denken over een eventueel vertrek. Ik maak hierbij graag de vergelijking met witgoed. Bij de aanschaf van bijvoorbeeld een koelkast of wasmachine betaal je gelijk de verwijderingsbijdrage voor het moment waarop je weer afscheid gaat nemen van het product, en precies hetzelfde zou je ook voor clouddiensten moeten doen. Bedenk vooraf welke ‘verwijderingskosten’ er komen kijken bij een eventueel vertrek. Deze retransitiekosten bevatten niet alleen de kosten voor het tijdelijk parallel draaien van je applicaties, maar ook voor eventueel productiviteitsverlies, inhuur van personeel, kosten van dataverkeer en migratiesoftware.

Wat maakt een cloud exit zo ingewikkeld?

Op het eerste gezicht lijkt een retransitie niet zo ingewikkeld. Het kan onmogelijk complexer zijn dan de migratie náár de cloud, toch? Nou, toch wel. De complexiteit van een cloud exit strategie heeft een aantal oorzaken:

• Het data-model van de clouddiensten is niet uniform
• De meta-data (zie kader verderop) is provider-specifiek en niet altijd toegankelijk
• Automatiseringsinterfaces (CSP API’s) zijn provider-specifiek
• De integraties met het platform (zoals integraties met monitoring en compliance tools) zijn provider-specifiek

Ik ben geen fan van de term lock-in omdat je al heel snel een zekere lock-in hebt. Ontwikkel je software in Java of dotNet, dan heb je er al mee te maken. Maar als je het heel graag wilt, kun je ook van programmeertaal wisselen, dus van een échte lock-in is vrijwel nooit sprake. Dat is ook niet het grootste probleem. Waar je wél altijd mee te maken hebt, is de tijd en energie die gemoeid gaat met de wisseling. Zo is het dus ook met clouddiensten. De tijd die nodig is voor een cloud exit strategie loopt behoorlijk snel op, omdat er voor alle bovenstaande onderwerpen een oplossing gevonden moet worden.

Wat wordt er voor jou als cloudklant geregeld?

Voordat je start met jouw cloud exit strategie is het belangrijk om te weten welke zaken voor jou geregeld worden en door wie. Hierbij spelen de overheid, het International Standard Institute (ISO) en de cloudprovider zelf een rol.

1. De overheid

De Nederlandse overheid heeft geen maatregelen genomen om je als afnemer van clouddiensten te ondersteunen of beschermen in voornoemde situaties (afgezien van de reguliere jurisprudentie rondom contracten etc.) De overheid biedt wel handvaten aan. Zo heeft de Nederlandse Referentie Architectuur Overheid (NORA) onder het Thema Clouddiensten van de BIO een artikel gepubliceerd dat inzicht geeft in de verschillende dreigingen, aandachtspunten en beveiligingsprincipes op het gebied van cloud. De NORA heeft overigens een verwijzing naar dit artikel opgenomen als bron voor de dreigingen.   

Op Europees niveau gebeurt er meer. Allereerst is daar uiteraard de “Free Flow of Non-Personal Data” regulering waarin artikel 6 voorschrijft dat providers zich aan een code of conduct hebben te houden als het over dataportabiliteit gaat (de beschikking over gegevens die jou toebehoren). Daarop aansluitend heeft de Europese Commissie een groep van belanghebbenden geformeerd die zich bezighoudt met het vergroten van portabiliteit tussen cloudproviders. Het project heet SWIPO (Switching Cloud Providers and Porting Data) en beoogt door middel van multidisciplinaire samenwerking het uitwisselen van gegevens tussen providers (swipen, net zoals nummerportabiliteit) mogelijk te maken. De status is nu: veelbelovend maar wel een papiertijger.

2. Het International Standard Institute (ISO)

In het licht van service level afspraken en afspraken over dataportabiliteit voorziet het ISO instituut in de 19086 standaard. Hierin beoogt ISO zowel de afnemers als leveranciers te helpen met het afsluiten van Service Level Agreements. In deze ISO standaard tref je uiteraard geen template-contract aan, maar wel alle relevante bouwblokken – de SLO’s (Service Level Objectives). Denk aan afspraken over de termijn waarbinnen de afnemer zijn data dient op te halen, in welk formaat dit zal zijn en wat er vervolgens door de provider met deze data wordt gedaan. Stel jezelf daarbij de volgende controlevraag: wordt na afloop van het contract mijn data door de provider gewist en is het dan ook echt weg?

3. De provider zelf

De grote hyperscale cloudproviders bieden zeer volwassen diensten voor het importeren en exporteren van je data. Zo kun je van bijna alle IaaS- en PaaS-diensten back-ups maken en deze downloaden. Daarnaast bieden deze partijen ook mogelijkheden om grote hoeveelheden data door middel van mobiele opslagsystemen te ontvangen. Zo maakt bijvoorbeeld de AWS Snowball de exit weer een stukje makkelijker.

Deze diensten gaan er wel vanuit dat je nog klant bent, wat betekent dat je een werkend account nodig hebt en die bedient via het reguliere portaal. Wacht dus met het opzeggen van het contract totdat al je data binnen is. Vanuit de overeenkomst krijg je maar weinig garanties over het dataformaat en de transporteerbaarheid daarvan. De vraag is dus of het lukt om al je data vanuit verschillende deeldiensten binnen 30 dagen te downloaden, de doorvoersnelheid wordt immers niet gegarandeerd. Sinds 2020 is wel in de contract-documenten de term ‘Your Content’ opgenomen. Zie bijgaand snippet met de definitie:

Kijk uit! Meta-data (zoals informatie over wie bestanden heeft geraadpleegd, hoe privileges stonden ingesteld en welke gebruiker toegang heeft verschaft) wordt niet door gebruikers geüpload maar door het platform gegenereerd. Deze meta-data is essentieel vanuit governance & compliance perspectief maar maakt dus mogelijk geen onderdeel uit van ‘jouw data’.

Wat kun je zelf doen ter voorbereiding op een exit?

Bij het voorbereiden op een eventuele cloud exit ga je door een aantal fases (zie ook de infographic hieronder):

1. Voorbereiding
2. Voorkoming
3. Uitvoering
4. Herstel terug naar normaal

Bij de voorbereiding bepaal je welke data en applicaties je nodig hebt voor het draaien van je concern. Bij een van onze klanten heb ik hier de term ‘Minimum Viable Company’ opgepikt. Oftewel: dat wat je minimaal nodig hebt om te overleven. Vervolgens denk je na over welke scenario’s mogelijk tot een exit kunnen leiden en hoe je uiteindelijk tot besluitvorming over gaat. Je hebt draaiboeken nodig en moet teams formeren.

Onder voorkoming versta ik alle mitigerende maatregelen die nodig zijn om te voorkomen dat je ooit een exit moet uitvoeren. Zo bewaak je de verschillende scenario’s (zoals het monitoren van het contract, het bijhouden van internationale wet- en regelgeving) en stuur je actief bij op het moment dat het dreigt mis te gaan. Voorkomen is uiteindelijk beter dan genezen.

Mocht het zover komen, dan is het bij de uitvoering van het exitplan een kwestie van uitvoeren wat je bedacht hebt. Dus alle besluitvormingsprocessen, exitplannen, scripts en communicatieprocessen worden in werking gesteld. Maar zoals mijn collega Michiel altijd zegt: een plan is een plan, totdat de vijand begint met schieten. Hou er dus rekening mee dat de helft van je plan de prullenbak in kan omdat het scenario zich toch anders voordoet dan je vooraf had bedacht.

Uiteindelijk moet je weer terug naar normaal, wat betekent dat alle processen voor bijvoorbeeld software development, leveranciermanagement en regievoering weer ingericht moeten worden. En als het dan zover is, wil ik graag wel even meeluisteren met de evaluatie van het geheel😊.

Meer weten?

In deel twee van dit artikel geef ik concrete adviezen over hoe je invulling kunt geven aan de cloud exit strategie voor IaaS-, PaaS- en SaaS-diensten. Een specifieke vraag? Laat het weten!