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

Drie manieren om apps naar de cloud te migreren

Channelweb Expert

Ruud Pieterse
Master Information Systems Architect, DXC Technology. Expert van Channelweb voor de topics Cloud Computing, Infrastructuur en Datacenters.

Een migratie naar de cloud is relevant voor veel bedrijven en organisaties. Er verschijnen ook voortdurend nieuwe oplossingen in de cloud, die weer leiden tot verse inzichten. Ze maken nieuwe migratieperspectieven mogelijk, die eerder niet bestonden. Dit alles heeft zijn effect op de strategie om naar een cloudomgeving te gaan.

Het uitgangspunt voor hoe je kijkt naar een cloudmigratie is veranderd: je kunt niet meer alleen vanuit een infrastructuurperspectief kijken. Het applicatieperspectief heeft inmiddels de overhand genomen. Wat betekent dit en wat zijn de mogelijkheden? Een applicatie naar de cloud brengen kan grofweg op drie manieren.

Een lift-and-shift scenario is vaak een goede oplossing als de on-premise omgeving aan het eind van haar lifecycle is gekomen. Het plannen van zo’n migratie vereist een secure benadering waarbij men gelijktijdige activiteiten zoals het openen van firewall-poorten en een inventarisatie van de omgeving niet meer op een Excel-sheet kan plannen. Hier zijn meer geavanceerde tools nodig om de planning en uitvoering te begeleiden. Ook is het belangrijk te bedenken dat deze iaas methode er voornamelijk voor zorgt dat een server in een cloudomgeving staat waar je de applicatie vervolgens op kan hosten. Het kostenvoordeel is vaak niet aanwezig. We spreken hier dan ook van een transitie in plaats van transformatie, omdat er aan de opzet van de applicatie niets verandert.

Applicaties kunnen ook naar een saas-model worden omgevormd. Dit kan echter de nodige administratieve overhead met zich mee brengen. Ook zijn saas-oplossingen in verhouding kapitaalintensief en is de mogelijkheid om applicatiefunctionaliteit te veranderen erg klein. Het voldoet echter, als men uit de voeten kan met de standaardfunctionaliteit.

Een derde mogelijkheid is om een echte cloudtransformatie uit te voeren. Deze oplossing gebruikt een methode waarbij men gebruik gaat maken van cloud-native oplossingen die in de publieke cloud worden aangeboden. Publieke cloud-providers bieden al een tijd webservices of databases als een service aan. Binnen de publieke cloud zijn er platformen zoals een containerplatform, die organisaties kunnen helpen om een nieuwe richting in te slaan. Voorheen lag dat misschien wat verder weg, omdat de kennis moest worden ingekocht of er eenvoudig niet genoeg mensen waren die de kennis konden opdoen omdat ze met operationeel gerelateerde zaken bezig waren. Op applicatiegebied was men in het verleden vaak geneigd de publieke cloud als een infrastructuuroplossing te zien. 

Cloud-architect aan zet

Het inrichten van een cloud-omgeving kan niet zonder een cloud-architect die weet hoe de eigenschappen van een publieke cloud omgeving benut kunnen worden. Organisatorisch helpt het als hij of zij feitelijk niet in de infrastructuuromgeving een plaats heeft, maar in de applicatieomgeving. De cloud-architect kan de applicatie-gefocuste engineers helpen om een verandering teweeg te brengen die er toe leidt dat beide werelden van applicatie en infrastructuur tot één geheel kunnen worden gevormd. Er kunnen dan ideeën worden uitgewisseld die aan beide kanten een voordeel gaan opleveren. De applicatie-architect leert meer over de mogelijkheden van de cloud, terwijl de cloud-architect het gebruik van de diverse cloud-functies kan promoten en helpen in te richten. De geïsoleerde torens van applicatieontwikkeling en infrastructuur kunnen nu verbroken worden. Door de inrichting van de organisatie te veranderen, ontstaat er een betere integratie van twee werelden die vroeger ver van elkaar af lagen.

Voor alle drie de methodes is het van belang dat een organisatie een partner aan zijn zijde heeft die de markt kent, de migratie-tools beheerst, zowel in technische als in planmatige zin, om een transitie of een transformatie te begeleiden.

x

Om te kunnen beoordelen moet u ingelogd zijn:

Dit artikel delen:

Reacties

Kijk Dino weer een lift-and-shift clown, dit keer eentje die net als jouw de eenvoudig cyclische tech refresh van hardware heel moeilijk weet te maken. Al die cloud architecten weten blijkbaar nog niet dat door virtualisatie de lift geen rocket science meer is. En misschien is dat alleen maar cloud-in-name-only maar ik kan op een bierviltje het kostenvoordeel uitleggen en dat is nog altijd het meest overtuigende argument in lift-and-shift transities. Ik kan de plank misslaan maar besparingen behalen in een korte termijn is het uitgangspunt van de lift in een lift-and-shift strategie, zeg maar de lucht verkrijgen in de budgetten voor de volgende stap.

Die stap kan een modernisatie van je monolitische applicatie portfolio naar multi-tenant SaaS oplossingen zijn maar vaak is dat alleen interessant als ook het business model wijzigt. In dat geval is een gesprek met een makelaar in luchtkastelen interessant maar als je uiteindelijk geen aanbieder van nieuwe digitale diensten wordt maar de afnemer blijft dan zijn er gesprekspartners die je beter informeren dan wij van WC-eend, adviseren WC-eend.

Hier nogmaals het lijstje dat je zelf beschreef bij https://www.computable.nl/artikel/blogs/cloud-computing/6959291/5260614/intelligentie-en-apis-zorgen-voor-controle-en-inzicht.html :
- donderwolken
- niet beheerbaar
- te veel bewegende doelen
- puzzel met duizend stukjes
- die snel wijzigen
- korte lifecycle
- unmanaged cloud
- shadow IT
- dagelijks wijzigende autorisaties

De ene valse achitect profeet die me tegen de andere waarschuwt.
Iedere verkoper kan op een bierviltje uitleggen waarom iets bij hem gekocht moet worden. Money talks.
Maar ik geeft toe dat jij daarop een businesscase maken van je eigen lijstje inclusief een unmanaged cloud migratie van de shadow IT dat is toch wel een prestatie.

Dino,
Natuurlijk mag je een eigen mening correleren uit mijn reacties maar ik kan me herinneren dat ik wees op een nieuw IT paradigma want de software-defined stack schijnt beter te passen bij DevOps-achtige organisaties. Het afnemen van een digitale dienst op basis van een pay-per-use model is nu eenmaal wat anders dan zelf een pay-per-use model ontwikkelen zoals ondertussen dus steeds meer organisaties ontdekken. Het sturingsproces van een zakelijke rechtvaardiging is niet statisch en op een bierviltje het organisatorisch resultaat, de gekwantificeerde winst of de projectrisico's uitleggen van verandering is natuurlijk maar het begin van een business case. Gratis consutancy is hierin niet meer dan het verkooppraatjes van een elevator pitch;-)

Uw reactie

LET OP: U bent niet ingelogd. U kunt als gast reageren maar dan wordt uw reactie pas zichtbaar na goedkeuring door de redactie. Om uw reactie direct geplaatst te krijgen moet u eerst rechtsboven inloggen of u registreren

Vul uw naam in
Vult u een geldig e-mailadres in
Vult u een reactie in
Jaarbeurs b.v. gaat zorgvuldig en veilig om met uw persoonsgegevens. Meer informatie over hoe we omgaan met je data lees je in het privacybeleid
Als u een reactie wilt plaatsen moet u akkoord gaan met de voorwaarden

Stuur dit artikel door

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

×
×
article 2020-07-24T09:07:00.000Z Ruud Pieterse
Wilt u dagelijks op de hoogte worden gehouden van het laatste ict-nieuws, achtergronden en opinie?
Abonneer uzelf op onze gratis nieuwsbrief.