De zeven R-en bieden een goede leidraad voor een verantwoorde cloudmigratie. In deze blog bespreken we de volgende twee R-en: replatform en refactor.
In het tweede blog bespraken we de migratiemethoden: rehost (lift-en-shift) en relocate. Beide activiteiten/begrippen veranderen de applicatie in de basis niet. In feite kies je voor andere infrastructuur (IaaS). Het grote voordeel hieraan is dat het relatief snel kan. Het nadeel is dat je niet of nauwelijks van de echte voordelen van cloud kunt profiteren. In deze blog ga ik dieper in op replatforming en refactoring. Bij deze migratiemethoden neem je de tijd om applicaties aan te passen voordat je ze verplaatst.
Met replatforming verplaats je niet alleen de applicatie naar de cloud, maar wijzig of werk je specifieke delen bij om te profiteren van kant-en-klare services die de cloudprovider aanbiedt. Het fundamentele verschil tussen de cloud en “oude” platformen zit hem in het feit dat de cloud meer verantwoordelijkheid bij de applicatie legt. Een simpel voorbeeld is beschikbaarheid. In de “oude” wereld levert de onderliggende infra de redundantie. Alles is dubbel uitgevoerd en soms merkt de applicatie niet eens als er wat fout gaat. Bij cloud is het andersom. De applicatie regelt zelf de beschikbaarheid en maakt gebruik van het feit dat onderdelen in de cloud heel snel opnieuw opgestart kunnen worden en dit geautomatiseerd gebeurt. Een falende “server” levert dan een korte onderbreking op, maar de applicatie draait gewoon door.
Voor de netwerk mensen onder ons kun je de cloud vergelijken met het TCP/IP protocol. IP is de cloud die er alles aan zal doen om een pakketje af te leveren. Er is echter geen garantie. De TCP laag (applicatie) beidt vervolgens die garantie. Die samenwerking geeft grote flexibiliteit en mogelijkheden. Dat zie je ook terug in de cloud waar de flexibiliteit mogelijkheden biedt, met als “prijs” meer of andere intelligentie in de applicatie.
Replatforming maakt de applicatie meer cloud-enabled maar niet volledig cloud-native. Hiermee profiteer je wel van verschillende voordelen van de cloud - zoals kosten- en prestatieverbeteringen - maar zonder het risico, de complexiteit en de kosten van een radicale applicatie verandering.
Replatforming zorgt voor een paar cloud-optimalisaties zonder dat je de kernarchitectuur van de applicatie verandert. Zo kun je bijvoorbeeld de hoeveelheid tijd die je besteedt aan het beheer van database-instances verminderen, door over te stappen op een database-as-a-service-aanbod zoals beschikbaar op de verschillende clouds. De cloud biedt dan een (redundante) DB aan waar je geen omkijken meer naar hebt. De cloud houdt de database in de gaten en regelt (op verzoek) backups. Je bent natuurlijk zelf nog steeds verantwoordelijk voor de indeling en optimalisatie van de database, het beheer wordt echter voor een groot deel uit handen genomen.
Net zoals elke migratie methode heeft ook replatforming voor en nadelen.
Voordelen:
Nadelen:
Met refactoring, ook wel rearchitecting genoemd, herbouw je de gewenste functionaliteit door de beschikbare cloudservices te gebruiken. Of wijzig je op zijn minst belangrijke delen van de codebase van de applicatie (waar zit de redundantie, waar wordt de “status” van de applicatie bewaard), zodat deze in uw nieuwe cloudomgeving past. Voor refactoring zit de businesscase in het beschikbaar komen van nieuwe functies, prestatieverbeteringen of betere schaalbaarheid die in de huidige omgeving van de applicatie moeilijk te realiseren zijn. Mogelijk wil je ook de wendbaarheid of bedrijfscontinuïteit verbeteren door over te stappen op een (micro) service oriented architectuur.
Refactoring is zinvol voor lange termijn projecten of voor projecten die cruciaal zijn om competitieve voordelen te behalen die anders niet bereikt kunnen worden. Het rendement moet de investering in tijd en budget rechtvaardigen en je moet bereid zijn om te wachten op de voordelen ervan. Refactoring is ook een verstandige keuze voor grotere applicaties, waarbij je meerdere nieuwe componenten tegelijk wilt toevoegen in plaats van stukje bij beetje. Met de Refactoring-aanpak haal je de meeste waarde uit de cloud, omdat je zonder compromis de beste en meest geschikte services kiest voor de behoeften van je gebruikers.
Bij refactoring moet je ook nadenken of je de applicatie nog wel as-is wilt gebruiken of dat je beter af bent met een volledige nieuwe (SaaS) applicatie die beter aansluit bij je nieuw plannen. Hier komen ook dan ook gelijk de laatste R-en tevoorschijn die we in de volgende blog behandelen (repurchase, retire en retain)
Bij refactoring moet je heel bewust kijken naar je cloud- en businessstrategie. Als het goed is zijn die twee in sync. De vraag die gesteld moet worden is of een kandidaat applicatie as-is omgebouwd moet worden, in een aangepaste vorm of volledig opnieuw moet worden gebouwd, opgaan in een andere applicatie (retire) dan wel vervangen (repurchase). In de voorbereiding op je cloudstrategie kan namelijk bepaald zijn dat je business model is veranderd waardoor je volledig anders met je gegevens wenst of dient om te gaan. Het kan zijn dat applicaties op je business zijn geschreven of dat je de business aan een applicatie aan hebt gepast. Als je nu op het punt staat je strategie om te gooien kan het heel goed zijn dat een applicatie helemaal niet meer voldoet. Dat zou een volledige rewrite kunnen betekenen of zelfs een vervanging (repurchase).
De nieuwe applicatie gaat de nieuwe manier van werken goed ondersteunen en maakt optimaal gebruik van features die de cloud heeft te bieden. Het is dus bijna een open deur om dit altijd te doen. Het vergt echter vaak een grote investering, zowel in de tool als mensen die wel (binnen afzienbare) terug verdiend moet worden. Verder gaat in de cloud alles sneller dus je moet zeker zijn dat een nieuw ontwikkelde applicatie dit bij kan benen zodat je niet binnen de kortste keren weer door de zeven R-en heen moet worstellen. Refactoring is dus een hele sterke methode, maar eist de meeste voorbereiding en analyse van alle R-en.
Voordelen:
Nadelen:
Replatforming en refactoring zijn complexer, langzamer en vergen meer effort dan rehosting of relocate, maar bieden op de lange termijn meer voordelen. Het kan lang duren om applicaties te refactoren, dus overweeg om eerst die activiteiten aan te pakken die je de belangrijkste waarde opleveren in je cloudreis. Aan deze migratiemethoden zijn meer risico's verbonden, dus overweeg om een iteratieve aanpak te gebruiken. Bijvoorbeeld door later te starten met rehosting en refactoring of door een agile project aanpak in te zetten dat telkens een Minimal Viable Product oplevert dat je kunt blijven verfijnen.
In ons laatste blog gaan we in op de laatste drie R-en: Repurchase, Retire en Retain. Heb je vragen of wil je eens van gedachten wisselen over jouw cloud strategie of migratie aanpak? Neem dan contact met me op via het contactformulier op onze website.
