Our expert opinion on cloud.

Hoe geef je invulling aan een Cloud Exit Strategie?

Geschreven door Bart M. Veldhuis op 3-jun-2015 13:30:00
Volg mij op:

Zoals in een eerder artikel over de Cloud Exit Strategie al geschreven verschillen de mogelijkheden per type cloud dienst (IaaS, PaaS en SaaS), maar vooral ook per leverancier. Om die verschillen duidelijk te maken zal ik ze allemaal behandelen, te beginnen met IaaS. Ik ga uit van de situatie dat er nog geen  overeenkomst is gesloten met de CSP. Deze adviezen gaan niet op als je NU een probleem hebt en weg moet, dan zit er maar één ding op: je moet NU handelen.

Cloud Exit Strategie voor Infrastructure-as-a-Service (IaaS)

migratie_strategieHet niveau van dienstverlening bij IaaS beperkt zich tot de virtuele machine. Het Operating System is de verantwoordelijkheid van de gebruiker (anders is er sprake van Managed Hosting). De meeste providers bieden de mogelijkheid om complete virtuele machine images te downloaden. Deze kunnen na enig conversiewerk naar een andere provider of naar een private cloud worden gemigreerd. Op dit moment bestaat er nog geen mogelijkheid om virtuele machines direct tussen de grote providers te wisselen. Zowel VMware als Microsoft zijn hard bezig om live migraties tussen private cloud en public cloud mogelijk te maken, maar zover is het vandaag nog niet. Het is dus onmogelijk om zonder tussenstap van Amazon naar Azure of Google te gaan. Van VMware naar VMware vCloud Air provider lukt wel, maar nog steeds met downtime. Daarnaast moet je rekening houden met het feit dat publieke IP adressen gebonden zijn aan de CSP. In alle gevallen zal dus een DNS wijziging nodig zijn.

Om in korte tijd een exit uit te kunnen voeren moeten dus voorbereidende maatregelen getroffen worden. Afhankelijk van de gewenste Recovery Point Objective (RPO)/Recovery Time Objective (RTO)kan dit volstaan met reguliere backups of zullen er Continuous Data Protection maatregelen genomen moeten worden. Al deze maatregelen hebben een flinke downtime tot gevolg bij het overschakelen.


Een active/active cloud ontwerp moet mogelijk zijn voor 1,5 keer de  kosten van een enkelvoudige omgeving


tabel_type_exit_strategie_IaaSIk wil het daarom ook expliciet hebben over een scenario waarbij zonder impact op de gebruiker geschakeld kan worden. Dit vereist een active/active ontwerp van de omgeving waarbij bij Provider-A 50% van de applicatie actief is en bij Provider-B de andere 50%. Afhankelijk van de behoefte van de applicatie kan er geschaald worden in één of beide clouds tegelijk. Dit concept is vergelijkbaar met de multi-regio oplossingen die je binnen één provider bouwt, maar nu over meerdere providers heen. Je kunt zo geen gebruik maken van de Global Load Balancing diensten van één van deze providers, maar zult dit met eigen middelen moet inrichten. Ook stelt dit eisen aan de applicatie zelf, deze optie is alleen inzetbaar voor cloud native applicaties. Voor enterprise applicaties en generieke bedrijfsapplicaties is dit niet mogelijk (zie dit artikel over verschillende applicatie types). Het klinkt aannemelijk om te veronderstellen dat de kosten van een dergelijke oplossing meer dan twee keer zo hoog zijn als normaal, maar dit is in praktijk  niet het geval. De genoemde maatregelen moeten vaak sowieso al getroffen worden om aan de infrastructuur eisen van de CSP te voldoen (in verband met de SLA) en nu worden de kosten gedeeld over twee providers. Een factor 1,5 is in praktijk niet ongebruikelijk.


Kies voor infrastructuur onafhankelijke (Enterprise) PaaS platformen voor een eenvoudige recovery


Cloud Exit Strategie voor Platform-as-a-Service

Er zijn verschillende typen PaaS diensten, de  infrastructuur onafhankelijke platformen zoals CloudFoundy, Outsystems, Mendix of Servoy, waarvoor de klant zelf kan bepalen van welke onderliggende infrastructuur gebruik gemaakt gaat worden in een Private of Public Cloud,  en de  infrastructuur afhankelijke platformen zoals Force.com en EngineYard, waarbij platform en infrastructuur onlosmakelijk met elkaar verbonden zijn. Om met deze laatste te beginnen: met deze platformen wordt de applicatie ontwikkeld op het platform en met de specifieke 4GL omgeving van de PaaS provider. Van provider wisselen betekent dat de complete applicatie opnieuw gebouwd (van programmeren is vaak geen sprake) moet worden bij de nieuwe provider. De lock-in op een dergelijke dienst is enorm, een migratie is nagenoeg onmogelijk.

tabel_type_exit_strategie_PaaSBij  infrastructuur onafhankelijke platformen  is het juist weer mogelijk om een vergelijkbare active/active setup te ontwerpen als bij IaaS. De applicatie wordt over twee CSP’s ‘uitgesmeerd’, beiden zijn verantwoordelijk voor 50% van de load. Zo kun je zonder impact voor de gebruiker de capaciteit herverdelen tussen de providers. Ook hiervoor geldt dat de kosten een factor 1,5 hoger zijn dan bij één provider. Let wel: u bent hiermee alleen onhafhankelijk geworden ten aanzien van de onderliggende infrastructuur en u blijft gewoon uw licenties of support contracten aan de desbetreffende PaaS provider betalen. Als u echter onenigheid krijgt met uw PaaS provider over de functionaliteit of de mogelijkheden van het software development platform zelf dan zit er ook dan niks anders op dan volledig opnieuw te beginnen op een ander development platform.


Gebruikers van SaaS diensten accepteren een enorme vendor lock-in


 

Cloud Exit Strategie voor Software-as-a-Service

Voor deze categorie van cloud diensten is de exit strategie zeer gecompliceerd. Een eenvoudige backup van de data volstaat vaak niet omdat er gewerkt wordt met relationele databases. Zodra er gebruik gemaakt wordt van leverancier-specifieke functies (denk aan workflows e.d) is de lock-in zo groot dat een exit nagenoeg onmogelijk is. Gebruik je echter alleen de basis functionaliteit dan is er hoop.

SaaS_example_recovery_planDoor een vergelijkbare SaaS dienst standby te houden en de data te synchroniseren is het mogelijk om voorbereid te zijn op een recovery. Het uitgangspunt van deze opbouw is dat er een vergelijkbare cloud applicatie standby wordt gehouden met een laag aantal gecontracteerde users. In het geval van een exit moeten deze gebruikers uiteraard snel op te schalen zijn. Via een geavanceerde API integratiedienst zoals Zapier is het mogelijk om twee systemen synchroon te houden. In dit voorbeeld neem ik een CRM dienst als SalesForce als uitgangspunt. De gebruikers werken primair in SalesForce met alle uitgebreide features. Het bestand met de leads, prospects en accounts wordt real-time gesynchroniseerd naar een ander CRM pakket, in dit geval het veel eenvoudigere (en goedkopere) Pipedrive. tabel_type_exit_strategie_SaaSDe data in Pipedrive wordt continu synchroon gehouden via de Zapier koppeling. Een bi-directionele synchronisatie behoort ook tot de mogelijkheden. Zodra er zich een situatie voordoet waarbij er gewisseld moet worden tussen SalesForce en Pipedrive hoeft het aantal actieve accounts in Pipedrive alleen maar uitgebreid te worden. Dit kan bijna real-time, het is tenslotte een SaaS dienst. Deze truc werkt helaas alleen maar voor de basisgegevens uit SalesForce. Een geavanceerde koppeling  tussen twee verschillende  SaaS providers vereist uitgebreid programmeerwerk en is extreem kostenverhogend.

Gebruikers van geavanceerde SaaS diensten als SalesForce accepteren in de regel een enorme vendor lock-in.

 Samenvatting:

Een Cloud Exit Strategie bevat pragmatische risico’s en mitigerende handelingen. Deze handelingen kunnen grotendeels geautomatiseerd worden, maar zijn zeer afhankelijk van het type dienst en de gebruikte functies. Over het algemeen kan worden aangenomen dat hoe breder het dienstenportfolio hoe complexer een eventuele exit is. Voor sommige diensten, zoals infrastructuur afhankelijke platformen en complexe SaaS diensten, is een exit nagenoeg onmogelijk. Als afnemer van deze diensten zal je de vendor lock-in moeten accepteren of genoegen moeten nemen met beperkte functionaliteit na de migratie. Weolcan kan je helpen met het opstellen van een Cloud Strategie die niet alleen maar de innovatie van je organisatie versnelt, maar ook een bruikbare Exit Strategie biedt. Daarnaast leveren we ook praktische hulp bij het ontwerpen of inrichten van de gekozen oplossing.

De presentatie die ik op Heliview SHIFT15 gaf nog eens bekijken? Download deze hier

Een stappenplan voor implementatie van hybride clouds

Onderwerpen: Cloud Exit Strategie, Cloud Strategie