Blog

Zeven betrouwbare strategieën voor migratie naar de cloud

Dit is het tweede deel in de blogserie over Kostenbesparing in de cloud. Het eerste deel lees je hier. Nog meer lezen en leren? Download het whitepaper, schrijf je in voor onze webinars, en lees de andere blogs.

Het moment om naar de cloud te gaan is ook het moment waarbij je alle software applicaties nog eens tegen het licht houdt. Kan deze software as is draaien in de cloud en is deze nog echt nodig? Is er inmiddels betere software op de markt? Dit zijn slechts enkele vragen die wellicht bij je opkomen.

Organisaties die de tijd nemen om de best passende migratiestrategie per applicatie te kiezen, besparen de meeste kosten en halen de meeste toegevoegde waarde uit de cloud.

“Application Rationalization is the process of evaluating assets to determine the best way to migration or modernise each asset in the cloud. The best way to analyse your applications environment is by using what Gartner articulately coined as the five R’s of application modernisation – this will help you choose the best path for your migration.” – Microsoft


Dit zijn de 7 strategieën die wij in de praktijk tegenkomen.

  1. Retire
  2. Retain
  3. Rehosting
  4. Replatforming
  5. Replace
  6. Refactor
  7. Rebuild

Meer weten over échte kostenbesparing in de cloud?

Download whitepaper

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.

rehost

de eenvoudigste migratie die er is

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.

Replatforming (‘lift -tinker- and shift’)

grotere voordelen behalen met kleine aanpassingen

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)

refactor

herstructureren voor optimaal gebruik in de cloud

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

rebuild

cloud-native opnieuw ontwerpen

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)

replace

bespaar jezelf de moeite van het migreren van je app naar de cloud

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

retire

heeft je app nog wel nut voor de organisatie?

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

beslis later wat je wil doen met je applicatie

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.

Geïnspireerd? Deel dit artikel

Ga naar de bovenkant