Webapplicaties migreren zonder downtime

Een veel voorkomend probleem van innovatieve online ondernemingen is schaalbaarheid. Een bedrijf heeft bijvoorbeeld een succesvolle web-applicatie die wordt gehost op een systeem dat de groei niet meer kan bijbenen. De cloud biedt de flexibiliteit en schaalbaarheid voor dit probleem. Maar welke risico's zijn er verbonden aan het verplaatsen van de applicatie naar de cloud? En zal de service waar klanten op rekenen niet onderbroken worden?

Het migreren van webapplicaties naar een schaalbare cloud-infrastructuur is een uitdaging waar talloze succesvolle online ondernemingen mee te maken krijgen. Gelukkig zijn er migratie-strategieën beschikbaar die kunnen helpen om dit proces succesvol te doorlopen. Ik ga er hier enkele bespreken.

Redding uit de cloud

Wij werken veel samen met bedrijven van alle groottes en in allerlei industrieën. Veel van deze bedrijven willen hun systemen van on-premise naar de cloud verplaatsen. De acceptatie van de cloud is de afgelopen jaren sterk verbeterd voor een breed scala van toepassingen, waaronder applicaties voor de primaire bedrijfsprocessen. Een belangrijke aanjager daarvoor is de aanzienlijke verbetering van cloud-security. Daarnaast bieden cloud-platformen steeds meer diensten aan, die nodig zijn om applicaties te kunnen draaien.

De cloud is daardoor niet langer alleen geschikt voor het aanbieden van informatieve websites en crm-tools. Zelfs internationale organisaties voelen zich nu op hun gemak om bedrijfskritische applicaties naar de cloud te brengen. Dit in navolging van Dev/Test en andere experimentele applicaties, die zich al hebben bewezen in de cloud. Deze beweging was onvermijdelijk, omdat klanten tegenwoordig steeds meer verwachten dat de systemen die ze nodig hebben altijd te benaderen zijn via een browser.

Systeemverschillen

Het verplaatsen van een bestaand productiesysteem naar de cloud zorgt vanzelfsprekend voor grotere uitdagingen, dan het opzetten van een nieuw systeem. De bron- en doelomgevingen moeten zoveel mogelijk gelijk zijn, omdat het migratieproces vooral gaat over het verplaatsen van data, zonder rekening te hoeven houden met systeemverschillen. Verder moet de periode van downtime goed overwogen worden. Die kan namelijk variëren van een milde ergernis voor de klant tot een ware business-killer.

Daarnaast moet een cloud-systeem dezelfde of betere prestaties bieden dan het oorspronkelijke systeem, zeker als je de gebruikers tevreden wilt houden. Maar misschien wel de grootste uitdaging: een migratie voltooien met weinig of geen onderbreking en er bovendien voor zorgen dat er geen data verloren gaat tijdens de transitie.

Data verplaatsen

Welke opties zijn er als je gegevens van een bronsysteem naar een nieuw systeem wilt verplaatsen? Er zijn grofweg twee keuzes. Je kunt de database op het bronsysteem dumpen, verplaatsen naar het doelsysteem, en die vervolgens daar inladen.

Om er zeker van te zijn dat het uiteindelijke doelsysteem consistent is met het origineel, is een korte downtime van de applicatie noodzakelijk tijdens de migratie. In veel gevallen is dat is echter geen optie.

Streaming replicatie

Een andere benadering bij het migreren van een applicatie naar de cloud is streaming replicatie. Bij deze methode blijft het bronsysteem online en kunnen klanten de service blijven gebruiken, terwijl de content naar het doelsysteem wordt gestreamd. Als het doelsysteem klaar is met het overzetten van de content, kan het bronsysteem uitgeschakeld worden en het doelsysteem geactiveerd. Deze omschakeling zal aanzienlijk korter zijn dan de eerdergenoemde dump-and-load aanpak. Helaas ondersteunen niet alle databasesystemen streaming replicatie. Postgres Plus Cloud Database, een product van EnterpriseDB, ondersteunt dit wel, maar hiervoor moeten beide kanten van van de migratie streaming replicatie ondersteunen.

Is dit niet het geval, dan is de eerste methode de enige mogelijkheid. Er zijn wel technieken beschikbaar die helpen om de dump-load methode te optimaliseren, zodat die theoretisch dichter in de buurt komt van streaming. Onder de streep echter zal de dienstverlening aan klanten nog steeds langer onderbroken wordt dan met streaming replicatie.

Verloren tweets

Er zijn gevallen waarin de bron- en doel-databases niet per se met elkaar in overeenstemming hoeven te zijn. Een dienst als Twitter loopt waarschijnlijk niet vast als er voor een korte periode een paar duizend tweets niet beschikbaar zijn. Maar werken met inconsistente gegevens voor loonadministratiedeposito’s van een paar duizend klanten, is natuurlijk wel een ernstig probleem.

De realiteit is echter dat veel moderne applicaties geen transacties hoeven te verliezen. Het kan soms wel iets langer duren voordat er consistentie is tussen de databases, terwijl de laatste transacties worden verwerkt na de eerste grote migratie. Om de impact van een relatief langere downtime te verzachten, zijn er wel strategieën, zoals het plannen van de migratie buiten kantoortijden (als die er zijn).

Tuning en Setup

Als een applicatie eenmaal naar de cloud is gemigreerd, dan moet er vervolgens nog gekeken worden of de prestaties en beschikbaarheid gewaarborgd zijn. Het goede nieuws is dat je deze issues voor database-beheer uitstekend kunt aanpakken met het juiste raamwerk, de cloud en een product als Postgres Plus Cloud Database. Opschalen of downsizen en automatische failover in de cloud zijn allemaal standaard features, die een waardevolle aanvulling zijn op deze veelzijdige open source database.

Zelfs als men ooit is begonnen met een nieuw systeem met bescheiden specificaties, dan nog is het gemakkelijk om snel op te schalen, zodat klanten een grote verbetering van de systeemprestaties zullen merken. Dit uitgangspunt moet veel technologie-startups als muziek in de oren klinken.