Je applicatie met pensioen of opnieuw bouwen?
Vaak worden de 5 R-en van Gartner als
uitgangspunt gebruikt om te beoordelen wat het
beste migratiepad is voor een specifieke
applicatie. AWS (Amazon) heeft hier nog een 6e
R aan toegevoegd en architecten van Team
Rockstars IT zien in de praktijk zelfs een 7e
strategie. Wat jouw ideale migratiepad is, hangt
af van vele factoren.

Bij rehosting, ook bekend als ‘lift and shift’, verander je de architectuur van de applicatie het minst. Het is de eenvoudigste migratie die er is, aangezien je de applicatie van de ene, on-premise omgeving, naar de andere, cloud, verplaatst.

Voorbeeld: Een bestaand order-verwerk systeem met specifieke software, database en instellingen, die geen cloud-alternatief kennen. Deze kan als VM in de cloud gehost worden.

Wanneer rehosten?

• Migratie legacy software
• IT-team met beperkte cloud kennis
• On-premise wordt te duur
• On-premise vereist veranderingen (vernieuwing, uitbreiding of redundancy)

Voordelen:

• Snelle migratie naar de cloud
• Direct kosten besparen
• Na de eerste migratie naar de cloud, gaan verdere migraties makkelijker. Enerzijds wegens kennisopbouw, en anderzijds wegens de aanwezigheid in de cloud.

Met replatforming kan je de operationele kosten van je applicaties aanzienlijk verlagen. Vaak wordt replatforming omschreven als het een beetje aanpassen van een applicatie zodat deze beter in een PaaS-gebaseerd model past.

Hier zou je een paar cloud- (of andere) optimalisaties kunnen maken om een tastbaar voordeel te behalen, maar verder verander je de kernarchitectuur van de applicatie niet. Misschien wil je de hoeveelheid tijd die je besteedt aan het beheren van database-instances verminderen door te migreren naar een database-as-a-service-platform zoals Amazon Relational Database Service (Amazon RDS), of door je applicatie te migreren naar een volledig beheerd platform zoals Amazon Elastic Beanstalk.

Voorbeeld: Een webapplicatie op IIS met SQL Database kan replatformed worden op Azure App Service met Azure SQL Database. Veelal met minimale aanpassingen in de broncode.

Wanneer replatforming?

• Met relatief kleine aanpassingen, grote(re) voordelen halen uit migratie naar de cloud.

Voordelen:

• Kortere en snellere updates
• Code portabiliteit
• Meer cloud efficiency (minder resources nodig, meer snelheid, lagere kosten, efficiënter operationeel beheer)
• Schaalbaarheid (eventueel automatisch)

Bij refactoring, soms ook re-architecturing genoemd, bekijk je de applicatie opnieuw, met de cloud voor ogen, en ga je code herstructureren om zoveel mogelijk gebruik te maken van de functies die de cloud biedt.

Sommige verouderde applicaties zijn niet-compatibel met de cloud architectuur. In dat geval moet de architectuur eerst opnieuw ontworpen worden voordat de applicatie naar de cloud gaat.

In andere gevallen is de applicatie wel cloud-compatible, maar niet cloud-native, terwijl een nieuwe cloud-native architectuur je grote kostenbesparingen kan opleveren. Ook dan is rearchitect een optie.

Voorbeeld: Een order-verwerk systeem dat als Windows service draait met een SQL database. Deze kan op Azure als Function App draaien, die luistert naar berichten in een Storage Queue, en kan zo schaalbaar orders verwerken. Op Black Friday schaalt de Function App eventueel automatisch naar meerdere instanties. De foundation is totaal anders, maar de broncode voor orderverwerking kan grotendeels hergebruikt worden.

Wanneer refactor?

• Je (legacy) applicatie is niet cloud-compatible
• Je applicatie is (enigszins) cloud-compatible, maar niet cloud-native
• Je wil kansen grijpen waar dat in de bestaande (on-premise) omgeving niet kan

Voordelen refactor

• Hogere schaalbaarheid en wendbaarheid
• Eenvoudiger adoptie van nieuwe cloud mogelijkheden
• Mix van technology stacks

Soms zijn applicaties zelfs geen verdere investering waard, omdat ze niet voldoen aan de huidige behoeften van je organisatie of niet aansluiten bij je huidige bedrijfsprocessen. Maar ook als de broncode wordt omschreven als spaghetti-code. In dat geval kan je je applicatie beter opnieuw ontwerpen en ontwikkelen met een code base vanuit een cloud-native benadering.

Voorbeeld: Een order-verwerk systeem met oude technieken zoals en oud .NET Framework en een oude (of geen) ORM(Object Relational Mapping)-tool zoals SubSonic. In dit geval is het beter het order-verwerk systeem opnieuw met .NET core en Entity Framework te bouwen. De oude broncode is nauwelijks te hergebruiken (en misschien maar beter ook :-)).

Wanneer rebuild?

• Applicatie toekomstbestendig maken en automatisch kunnen schalen
• Gebruik maken van de nieuwste software en cloud technologieën
• De bestaande applicatie is nauwelijks te beheren is (hoge leercurve voor nieuwe ontwikkelaars)

Toen je applicatie gebouwd werd, heb je waarschijnlijk gebruik gemaakt van de beste technologie en aanpak die tóen beschikbaar was. Software as a Service (Saas) applicaties bieden nu misschien al wel alle functionaliteit die je nodig hebt in jouw applicatie. Dan is het logischer om van de SaaS applicatie gebruik te gaan maken en daarmee je bestaande software te vervangen. Daarmee bespaar je je ook de moeite van het migreren van de applicatie naar de cloud.

Voorbeeld: Een order-verwerk systeem met maatwerk software waar tegenwoordig (betere) SaaS- oplossingen voor zijn. In plaats van hoge ontwikkelkosten (en totale vrijheid) stap je over op licentiekosten en conformiteit aan geboden features.

Waarom Replace?

• Standaardiseren op basis van industrie standaarden / best practices
• Focus verleggen naar investeren in ontwikkeling van applicaties die echt waarde toevoegen en concurrentievoordeel opleveren

Vaker niet dan wel komen we er tijdens de Cloud Scan® achter dat 10% of meer van de applicaties in het IT portfolio van een organisatie niet meer gebruikt wordt en/of eigenlijk geen nut meer heeft. Die kunnen dus simpelweg uitgezet worden.

Voorbeeld: Een order entry-systeem voor ISDN2. Deze techniek is vanaf 2021 niet meer beschikbaar, en dus ook niet meer te bestellen.

Wanneer Retire?

• Applicatie heeft geen nut meer voor de organisatie

Retain betekent meestal ‘later nog eens bekijken’ of (nu) niets doen. Misschien ben je nog aan het afschrijven op je applicatie, of is die net ge-upgrade, of heb je andere redenen om een applicatie nog niet naar de cloud te migreren. Dat is prima. Je zou alleen applicaties moeten willen migreren als het logisch is voor jouw organisatie om te doen. Waarschijnlijk merk je dat je in de loop van de tijd steeds meer naar de cloud migreert, waardoor uiteindelijk ook deze applicatie hogere prioriteit krijgt. Voor nu is het helemaal ok om de applicatie on-premise te houden!

Voorbeeld: Een order-verwerk systeem dat gebruik maakt van een zeer zware SQL-server (bv 2TB SSD disk, 100GB RAM en 80 CPU’s). Dit systeem hosten in de cloud kost jaarlijks een fortuin. Als het systeem prima on-premise draait, dan is dit kostentechnisch sterk te overwegen. Dit is een typische applicatie die later kandidaat kan zijn voor Rebuild of Replace.

Wanneer Retain?

• Je wilt nu nog geen beslissing wil nemen over deze applicatie.
• Hosting kosten voor Rehost in de cloud zijn veel te hoog.