Migreren naar de cloud: het keuzedilemma

Meestal hoor je onze consultants niet tijdens migraties: ze zijn dan hard aan het werk om zo snel mogelijk het gestelde doel te bereiken. Ze doen dat door zoveel mogelijk “best practices” toe te passen. Soms staan ze ook voor een dilemma: wat is beter, een snelle migratie of een migratie die iets langer duurt en iets meer kost, maar waarbij je in de toekomst minder problemen hebt?

 Het is dit dilemma waar Frederique haar blog over schreef. Frederique raadt aan om dit aan de stakeholders voor te leggen. En wat ik me tijdens het lezen afvroeg is: “hoe zou zo’n gesprek met de stakeholders lopen?” Ik stelde de vraag aan Frederique, ze antwoordde het volgende:

 “In mijn blog beschrijf ik een on-premise omgeving. Het is een Windows Failover Cluster, dat gemigreerd wordt naar AWS (Amazon Web Services). Dit soort clusters wordt meestal gebruikt in omgevingen waar je een belangrijk programma op hebt draaien dat niet meerdere keren tegelijkertijd gestart mag zijn. In mijn blog noem ik het verkopen van kaartjes voor een concert als voorbeeld. Je wilt er zeker van zijn dat je een kaartje voor een stoel maar één keer verkoopt, om te voorkomen dat twee concertbezoekers beide een kaartje voor dezelfde stoel bij hetzelfde concert hebben. Je kunt je ook andere situaties voorstellen, bijvoorbeeld dat je in een logistieke omgeving een dock reserveert voor een vrachtauto voor een bepaald tijdsframe."

"Je wilt er zeker van zijn dat je een kaartje voor een stoel maar één keer verkoopt, om te voorkomen dat twee concertbezoekers beide een kaartje voor dezelfde stoel bij hetzelfde concert hebben"

De huidige situatie

Als je een AWS migratie uitvoert, dan zul je eerst moeten kijken naar hoe de situatie on-premise is. Als je weet hoe lang het duurt om een cluster te verplaatsen van de ene naar de andere node, dan kun je ook inschattingen maken hoe lang dit binnen AWS gaat duren.

Ik heb een voorbeeldprogramma geschreven dat simpelweg de tijd op de server als webpagina weergeeft. Door vanaf een andere node elke seconde de website aan te roepen en daarna de node waar de website draait te stoppen kun je bij elke oplossing precies zien hoeveel tijd het kost dat het programma omschakelt van de eerste virtual machine naar de tweede. Deze resultaten zijn vaak schokkend voor techneuten die gewend zijn aan een cluster move die enkele tientallen seconden duurt. In de AWS cloud duurt dit namelijk altijd langer: van iets minder dan een minuut bij een 1:1 migratie tot zelfs wel 9 minuten wanneer AWS technologie met standaardinstellingen van een load balancer gebruikt maakt. Aan de andere kant verschillen ook de kosten enorm: de 1:1 migratie kost ongeveer 4x meer aan operationele kosten dan de standaard AWS oplossing.

Als je een nieuw systeem in AWS ontwerpt, dan gebruik je natuurlijk geen Windows Failover Clusters meer. Je zult dan eerder denken aan een serverless (Lambda) functie die je zo configureert dat die niet meerdere keren tegelijkertijd kan draaien. Of aan een container die je bij voorkeur op de serverless (Fargate-)omgeving draait. Of je zorgt er in je database voor dat je met locking voorkomt dat je bepaalde records gelijktijdig update.

 Bij een migratie heb je die mogelijkheid vaak niet: bij migraties moet de huidige omgeving zo snel mogelijk gemigreerd worden naar de cloud. Optimalisaties gebeuren meestal pas nadat alles in de cloud draait. In dit soort projecten heb je de keuze: welke kosten ben je bereid te betalen en welke risico’s ben je bereid te lopen? Projectorganisaties hebben daarbij een ander belang dan de opdrachtgever: waar de projectorganisatie vooral snel klaar wil zijn en lage operationele kosten een pré zijn omdat dit de klant overtuigt van de juiste beslissing om te migreren, daar kan de opdrachtgever beter inschatten of de risico’s die genomen zijn ook passen bij het bedrijf waarvoor gemigreerd wordt.

"Bij migraties moet de huidige omgeving zo snel mogelijk gemigreerd worden naar de cloud. Optimalisaties gebeuren meestal pas nadat alles in de cloud draait"

Drie serieuze alternatieven:

1. De 1:1 migratie van het Windows Failover Cluster.

Voordeel is dat je een heel korte omschakeltijd hebt tussen twee nodes als een node uitvalt. Een ander voordeel is dat de migratie van de programmatuur heel snel kan gaan: misschien gebeurt de uitrol van programmatuur nu nog handmatig en moet je de uitrol van programmatuur automatiseren, maar de omgeving zelf lijkt ontzettend op wat er on-premise draait. Nadelen zijn er ook: deze oplossing is operationeel 4x zo duur dan de standaard AWS oplossing. En als er een netwerkprobleem binnen je Availability Zone is waarbij je geen enkele node binnen die Availability Zone kunt bereiken, dan duurt het zo’n drie kwartier om je CloudFormation template in een andere regio uit te rollen.

2. De migratie van een Windows Failover Cluster naar een AWS Auto Scaling Group.

Deze oplossing heeft als voordeel dat het lage operationele kosten heeft. De oplossing is ook (veel) minder complex dan een 1:1 migratie: als je kijkt naar het aantal “trucs” en de hoeveelheid code die gebruikt is, dan kun je nieuwe medewerkers veel eenvoudiger leren hoe deze Auto Scaling Group oplossing werkt dan dat je mensen moet uitleggen wat er zowel binnen AWS als binnen het Windows Failover Cluster gebeurt om e.e.a. werkend te krijgen. Het nadeel is de lange omschakeltijd bij problemen: als een node uitvalt, dan duurt het gemiddeld 7,5 minuten om een nieuwe node uit te rollen. Er is daarbij geen verschil in omschakeltijd tussen de situatie dat er problemen op de node zelf zijn of dat er problemen in de Availability Zone zijn.

3. De migratie van een Windows Failover Cluster naar een AWS Auto Scaling Group met een Custom Image.

Deze oplossing lijkt op de vorige oplossing, maar nu wordt eerst een eigen image gemaakt. Doordat de installatie van IIS en je eigen software niet meer bij elke failover gebeurt maar slechts eenmalig bij het aanmaken van een nieuw image is de failover tijd meer dan een minuut korter. De kosten zijn iets duurder dan de vorige variant. De belangrijkste extra kosten zitten niet zozeer in de infrastructuur, maar in de complexiteit van de oplossing: de kosten dus voor extra documentatie en de kosten van kennisoverdracht naar de techneuten die e.e.a. in de toekomst moeten beheren.

Wat zijn de voordelen?

Misschien vraag je je nu af waarom je überhaupt nog systemen zou migreren naar de cloud als de failover tijd altijd langer is. Het antwoord zit in de andere voordelen van de cloud: bijvoorbeeld dat de AWS datacenters in zijn algemeen beter fysiek beveiligd zijn dan de datacenters on-premise. In mijn oplossing is alles gescript, wat er voor zorgt dat een Windows Update niet meer behelst dan het stoppen van de CloudFormation stack en het daarna opnieuw uitrollen. Het voordeel is dan ook dat er direct “nieuwe virtual machines” uitgerold worden, waardoor het fenomeen dat je na drie jaar gebruik van een Windows Failover Cluster allerlei oude 'troep' tegenkomt (van zowel Windows zelf als tijdelijke bestanden die beheerders daar achtergelaten hebben) niet meer voorkomt. Als een Windows Server minder goed begint te werken dan is dit on-premise vaak een probleem: doordat het opnieuw inrichten van zo’n server heel veel tijd kost, gebeurt dit meestal niet. Dat levert vroeg of laat productieverstoringen op.

Een ander voordeel is schaalbaarheid: stel, dat een programma aangepast wordt en ineens meer CPU of geheugen nodig heeft. In AWS kun je dan vrij gemakkelijk een zwaarder type virtual machine gebruiken. Als je alles gescript hebt, kun je je oplossing snel opnieuw uitrollen.

Kosten vs. risico's

Bij het selecteren van een migratie alternatief waarbij de focus zal liggen op het behalen van kostenvoordelen op korte termijn, zullen de belangen anders zijn dan alternatieven waarbij op lange termijn de operationele risico’s zo klein mogelijk worden gehouden. De blogreeks van Frederique geeft een duidelijk verschil tussen alle alternatieven weer en houdt rekening met de kosten en de ‘failover tijd’ van elke oplossing. "Ik ben van mening dat onze specialisten de mogelijke scenario’s met de opdrachtgever moeten bespreken, omdat die ook op langere termijn niet alleen de financiële gevolgen, maar ook de gevolgen van onze risico inschattingen gaat ondervinden."

"Uiteindelijk kunnen de kosten fors dalen als je gebruik maakt van de cloud zoals deze bedoeld is: dus meer gebruik maken van serverless oplossingen. Maar dat vraagt een re-design die in de hectiek van een migratie vaak net even te complex is. Onze specialisten helpen je graag om het hoogste rendement uit jouw investering te halen”