Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het gedachtegoed van de redactie.

Webapplicaties migreren zonder downtime

 

Expert

Jeannot Bos
Sales Director Europe, EnterpriseDB. Expert van voor het topic .

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.

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/5426902). © Jaarbeurs IT Media.

?


Lees meer over


 

Reacties

Een beetje projectmanager met kennis en ervaring met infrastructurele projecten weet goed hoe hij dit soort trajecten moet aanpakken, wat hierboven staat vind ik zeer optimistisch naar dit soort trajecten gekeken.
Er zijn verschillende migratie scenario`s en er zijn ook per klant verschillende uitdagingen.
Ik heb tijd geleden bij een klant te maken gehad met migratie van haar DWH naar externe leverancier. Ze hadden eerder van hun DWH een spaghetti gemaakt door in de loop van de tijd door applicatie- en DB-beheerders verschillende "views" en andere point-to-point connecties, diep in de DB`s zelf te laten maken!
Ga dan maar eerst de DB-afhankelijkheden en landschaap overzichtelijk maken voordat je aan de migratie begint...........dat was een uitdaging!

Verder wat betreft de prestaties.....hoe ga je dat meten in een Cloud-model? Vanaf je back-end systemen tot aan de muur van je DC?
In een Cloud architectuur zijn er verschillende schakels in de keten. Slechte werking van een schakel kan de rest verpesten. Bijvoorbeeld je internetlijn! Hoe ga je alle schakels nalopen om de oorzaak te vinden als de oplossing niet voldoende performance heeft?

Ook Mysql/Mariadb kan replicatie met failover doen in de cloud.
Wie een webapplikatie naar "de cloud" brengt moet dus even kijken wat zijn database zo kan, in die zin vindt ik het artikel een beetje een open deur.
Overigens bied Google momenteel juist voor Mysql zo het een en ander aan in de cloud.

Dit is nou precies waar de Cloud in essentie geen oplossing biedt. We praten bij een migratie altijd over legacy.

Er is geen enkele "applicatie" (hoe standaard ook, al neem je een email server) die 1-1 zo maar over kan. Dat is een illusie. Zowel op OS, DBBMS, als applicatie niveau worden altijd heel specifieke configuratie wijzigingen toegepast. Waarom? Omdat geen enkele applicatie los van de rest staat.

Waar het probleem zit, is dat geen enkele organisatie in de wereld (wat ze je ook wijs maken, omwille dat ze zo goed en slim zijn) van enige significante omvang alle afhankelijkheden op OS, DBMS en applicatie gebied volledig op het netvlies hebben. Er bestaan ook geen tools daarvoor. Er hoeft maar 1 medewerker te zijn die buiten de gangbare procedures om 1 vinkje verkeerd gezet te hebben en je hebt de poppen aan het dansen.

Buiten deze keiharde les, zal een applicatie X op systeemomgeving A altijd anders draaien op systeemomgeving B. Het idee dat gelijksoortige systeemomgevingen hetzelfde gedrag (functionaliteit, performance, security,etc....) is ook lariekoek.

En ja er zijn tools die tegenwoordig een redelijke hoeveelheid instellingen kan inventariseren (want dat zal je echt moeten gaan doen, voordat je überhaupt het besluit neemt om te migreren), maar ze missen zeker 10%. En een vinkje kan al funest zijn.

En nee, ik ken geen oplossingen vandaag de dag, die dat voor elke migratie wel eventjes oplost. Er zullen wel horden commercianten het hier niet mee eens zijn. Eindklant: klant laat deze commercianten zwart-op-wit in het contract opnemen, dat elke minuut uitval uit zijn persoonlijke salaris wordt gefinancierd.

@Reza: van achter naar voren:

Meten in een cloud model is een deel van mijn werk. Dus als die vragen inderdaad leven wil ik daar met alle plezier eens met je over brainstormen.

Voor de rest:
Programma- en project managers zijn er in verschillende vormen en smaken waaronder technisch en niet-technisch. Het is prima als zo iemand kritische vragen stelt over de oplossing danwel de oplossingsrichting richting. Maar om het werk van een architect annex consultant nog eens dunnetjes over te gaan doen lijkt me te ver gaan.

:-)

@Will: van achter naar voren:
Denk je dat ik dacht dat een PL/PM alles weet over netwerk, DB, beveiliging, storage, OS (Windows/Unix/Linux etc), virtualisatie etc etc :-)
Een projectmanager werkt in een team. De oplossing en de aanvliegroute en nog andere dingen worden bedacht in een "teamwerk" Het is onmogelijk als alles door PM/PL bedacht moet worden.
Misschien was ik kort door de bocht maar teamwerk is voor me duidelijk en vanzelfsprekend waardoor ik het niet benoemd heb.

Meten in een cloudmodel! Gaaf....., leuk als je daar wat over wilt schrijven. Zeer nuttig en voorkomt onzinnige artikelen zoals "Een Westmalle Tripel … of twee" in deze komkommertijd.

Ik kijk er naar uit Will

@Reza: ik ga mijn best doen.

Atilla Vigh ik kan me niet goed vinden in je reactie en zal schrijven waarom.

"Dit is nou precies waar de Cloud in essentie geen oplossing biedt"

En dan kom je met een verhaal over vinkjes en configuraties. Iets wat je hebt bij iedere migratie -cloud of niet cloud- en zo niet dan hoeft dat in de cloud ook niet zo te zijn.

Daarna kom je met een hoop FUD om mensen bang te maken überhaupt iets te veranderen.

Begrijp me niet verkeerd, ik denk dat als je on-premises legacy wilt verplaatsen de cloud zeker geen geschikte plek hoeft te zijn. Beter kies je voor een andere oplossing die cloud native is. Maar je kunt bij enkele providers prima doen wat je in een ander data center ook kunt doen.

Wat betreft downtime. Ach, het zou kunnen zijn dat je er soms niet omheen kunt. Dan zul je het moeten plannen. Ik zie het probleem niet.

@Henri
inderdaad, geplande downtime mag geen probleem zijn zolang de duur binnen de perken blijft. Beter downtime als een korrupte database zou ik zo zeggen.
Overigens komt de angst voor de boze cloud vanwege het vele onweer de laatste tijd . . .

Een verkoper zal altijd roepen dat er geen problemen zijn maar de ervaringen leren dat je beter goed kunt meten dan gokken, het ligt niet in mijn bedoeling om FUD te verspreiden maar migreren van een database gaat meestal niet alleen om de data. Veelal zit pijn in de business logic welke er middels allerlei stored procedures ingebakken is. Laten we zeggen dat er gewoon nog een verschil zit tussen edge en enterprise.

@ Henri, mijn intentie is helemaal niet om FUD te creeren, maar om eindklanten te waarschuwen dat welke migratie dan ook vol met valkuilen zit, waar de gehele ICT industrie nog geen echt goede oplossing voor heeft.
Wat ik vaak lees (ook in dit artikel) is dat de Cloud weer voor alles een oplossing is. Ik word daar moe van. Jou neem ik dat niet kwalijk, je bent inhoudsdeskundige, maar vele verkopers lopen indianenverhalen te verkopen.
In dit specifieke artikel wordt weer alleen naar 1 enkel aspect gekeken, dat is de DBMS, terwijl er in een gemiddeld applicatie en infrastructuur landschap nog veel aanwezig is.

Het idee van de migratieloze ICT zonder een enkele hick-up is nog mijlen ver verwijderd. Ga voor de lol maar eens willekeurige patch installeren.

Atilla, in deze reactie kan ik me veel beter vinden :-)

Laten we voorop stellen dat iedere migratie of verandering geld kost. Dit is de reden waarom er vaak aangevuld en gepatched wordt ondanks dat er al betere alternatieven zijn. Dit is de *primaire* drijfveer voor het ontstaan van legacy; een werkend systeem welk verouderd is.

Doordat steeds migreren en de beste keuze maken op korte termijn duurder is wordt er voor de kortere termijn een oplossing en aanvulling gekozen. Dit is wat men noemt: Een technische schuld. Door elke verwevenheid te laten ontstaan -men kan steeds minder makkelijk afscheid nemen van wat er is- wordt de technische schuld hoger. Daar komt later nog eens "rente" op waardoor men blijft uitstellen.

If it's your job to eat a frog, it's best to do it first thing in the morning. And If it's your job to eat two frogs, it's best to eat the biggest one first.
- Mark Twain

@Ewout:
[...] migreren van een database gaat meestal niet alleen om de data. Veelal zit pijn in de business logic welke er middels allerlei stored procedures ingebakken is [...]

Mee eens! Dat is exact wat ik hierboven zei:
[...] Ze hadden eerder van hun DWH een spaghetti gemaakt door in de loop van de tijd door applicatie- en DB-beheerders verschillende "views" en andere point-to-point connecties, diep in de DB`s zelf te laten maken! [...]

De stored procedures (ik zei point-to-point connecties) waren de ellende van dat traject.

Ik denk dat de hierboven beschreven scenario's heel goed zijn toe te passen en ik kan nog wel enkele zaken bedenken waarmee je downtime op je systemen kan creëren zonder daarvoor aan service naar de klant in te boeten.
Veel reageerders denken in technische problemen (op basis van persoonlijke ervaringen) in plaats van oplossingen out of the box.

Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×