Checklist deel 1: bepaal jouw strategie voordat je migreert naar Azure

Voordat je aan jouw Azure reis begint, is het belangrijk om een stap terug te doen en na te denken over wat je daadwerkelijk wilt bereiken. De eerste stap naar het succesvol moderniseren van jouw oplossing is het bepalen van je strategie, zowel op korte als lange termijn.

 

                                                                                                                                                                            Wesley Haakman, Intercept

In eerste instantie heeft dit weinig te maken met jouw werkelijke technische cloudoplossing. Om jouw IT strategie te bepalen houd je doorgaans rekening met wat jouw klanten willen, waar zij zich bevinden, het financiële aspect en nog veel meer. In een vraag samenvattend: waar wil je als organisatie de aankomende jaren naartoe en hoe ga je hieraan bijdragen vanuit een IT-perspectief? En ergens tijdens deze meerjarige, doordachte strategie ontstaat er een plan om je oplossing continu te kunnen verbeteren, om waarde toe te voegen, te innoveren en de concurrentie voor te blijven. Er zijn veel redenen om je oplossing te moderniseren en gebruik te maken van de mogelijkheden en technologieën van de Public Cloud. Het is veel eenvoudiger, kost minder moeite om de nieuwste technologie in je oplossing te integreren en het financiële plaatje is veel interessanter vergeleken met het opnieuw bouwen van je applicatie. En last but not least, een moderne applicatie betekent een voorsprong op je concurrentie. 
 
Strategie voor het moderniseren 
Er zijn veel redenen om je oplossing te moderniseren en gebruik te maken van de mogelijkheden en technologieën van de Public Cloud. Het is veel eenvoudiger, kost minder moeite om de nieuwste technologie in je oplossing te integreren en het financiële plaatje is veel interessanter vergeleken met het opnieuw bouwen van je applicatie. En last but not least, een moderne applicatie betekent een voorsprong op je concurrentie.  
Voordat je jouw oplossing op Azure gaat uitrollen zijn er een aantal aspecten waar je rekening mee moet houden. Ten eerste is het belangrijk om de verschillende scenarios vast te stellen die je cloudstrategie en de architectuur bepalen. Ten tweede moet je bepalen hoeveel je wilt investeren in je oplossing voordat je de stap maakt naar de cloud. Kies je bijvoorbeeld voor rehosting (lift en shift) en blijf je voorlopig nog gebruik maken van virtual machines of ga je onderdelen van de oplossing herschrijven zodat dit beter past op Azure native platforms zoals Web Apps of Functions?
Iedere strategie heeft zijn eigen voordelen en uitdagingen, zolang je  maar begrijpt dat het moderniseren van je oplossing een continu proces is dat de juiste financiële middelen en de juiste technologieën vereist.  
Als we kijken naar de verschillende scenario’s, dan zijn de volgende het meest toonaangevend als het gaat om oplossingen in de Public Cloud: 

  • “On and off” scenario; 
  •  “Growing fast” scenario; 
  • Unpredictable bursting; 
  • Predicable bursting''.

Als we dan kijken naar de stappen voor het moderniseren kunnen we kiezen uit de volgende migratie strategieën: 

  • Rehost (lift en shift); 
  • Refactor (repackage); 
  • Rearchitect (het optimaliseren van je code); 
  • Rebuild (build cloud native).

Natuurlijk ben je niet verplicht om deze exacte stappen te volgen, want je kan zelf kiezen waar je start en waar je eindigt. Wellicht wil je het lift en shift scenario overslaan en beginnen met het doorvoeren van kleine aanpassingen (refactoring) van je applicatie. Bijvoorbeeld het repackagen van je applicatie om  gebruik te maken van containers Voor de geïnteresseerde, de diverse migratie strategieën zijn hier uitgebreider beschreven.  

Laten we eens kijken naar de vier scenario’s die helpen bij het bepalen van de beste moderniseringsstrategie voor je oplossing. Zoals eerder benoemd is het belangrijk om je business, je klanten en het financiële plaatje van je huidige situatie goed te bekijken.  We willen tenslotte appels met appels vergelijken. Maak daarom je performance inzichtelijk (we gaan hier dieper op in de komende weken), zorg ervoor dat je documentatie in orde is en niet te vergeten; identificeer je knelpunten(migreren naar de cloud moet juist toegevoegde waarde geven toch?) 

On and Off scenario 
Het on and off scenario is het scenario dat echt geld bespaart als je komt van een lift en shift migratie en je omgeving maakt gebruik van virtual machines (infrastructure as a service).  Met Microsoft Azure betaal je alleen voor wat je gebruikt. Voor compute resources zoals virtual machines betaal je per uur en de teller begint te lopen wanneer de virtuele machines zijn gealloceerd (resources zijn toegewezen).  
Afhankelijk van de maand betreft dit 720-744 uur (met uitzondering van februari). Stel dat je een omgeving hebt waar het verbruik overdags piekt en weer daalt tijdens de avonduren en in het weekend (of s nachts). Dat betekent dat je applicatie minder capaciteit nodig heeft in de daluren dan gedurende de piekuren. Als je de capaciteit in de daluren naar beneden zet dan zal dit van grote invloed zijn op de kosten om je oplossing draaiend te houden.

Bijvoorbeeld: als je een virtual machine hebt die 0.088 per uur kost,  dan kost dit per maand gemiddeld 65.  Als je meerdere van deze machines zou hebben draaien (laten we zeggen zes stuks) om de klanten te bedienen, zou dit neerkomen op 390 per maand. Als je inzicht in je gebruik hebt en in het klantenbestand (en hun gebruik), kun je dit aanzienlijk verlagen. Laten we bovengenoemd scenario uitwerken op basis van gebruik (fictief): 

  • Piek uren: 09:00 – 17:00 
  • Gemiddeld verbruik 06:00 – 09:00 en 17:00 – 21:00 
  • Laag verbruik 21:00 – 06:00 

Als we het aan en uit scenario implementeren zou dit er zo uit zien:  

 

Uren per dag 

Uren per maand 
(31 dagen) 

Aantal vereiste VM’s  

Totale prijs 
(0.088 per uur per vm) 

Piek uren 

8 

248 

6 

131 

Gemiddeld gebruik 

7 

217 

4 

76.38 

Laag gebruik 

9 

279 

2 

49.10 

Totaal 

 

 

 

256.50 


Dat is een behoorlijk groot verschil en als je echt tijd zou besteden aan
het inzichtelijk maken van  het gebruik van je platform, zou je dit nog verder terug kunnen schalen of ervoor kiezen om het schalen te automatiseren waardoor je daadwerkelijk alleen maar de resources aan zet welke je op dat moment nodig hebt. Dit werkt ook uitstekend voor batchverwerking (als je weet wanneer jouw batches worden uitgevoerd).  

Growing fast scenario
Het op- of afschalen van je oplossing op Azure kan een gecompliceerd proces zijn en er zijn veel bedrijven die het lastig vinden om de groei bij te houden. Dus wat we nodig hebben is de mogelijkheid om op- en af te schalen op het juiste moment. Wat goed is om te weten is dat schalen en groeien twee opzichzelfstaande concepten zijn (hoewel dit vaak door elkaar wordt gehaald). Als we het hebben over schalen, dan willen we dat de juiste resources op het juiste moment en in de juiste hoeveelheid beschikbaar zijn. Groei heeft daarentegen weinig te maken het echte schalen (ja, je hebt wel de juiste resources nodig), maar we hebben het over de implementatie van nieuwe versies van je software of identieke versies naar verschillende regio’s (het toevoegen van klanten wereldwijd). Dit scenario is voornamelijk van toepassing op bedrijven die hun time-to-market willen verbeteren en software dicht bij hun klanten willen inzetten (voor beheer of latency doeleinden) zonder dat je handmatig het installatie- en onboarding proces van klanten hoeft te doorlopen (wat je waarschijnlijk nu wel doet). 

Als dit is waar je naar op zoek bent is automatisering en standaardisatie essentieel. We zijn op lange termijn niet tevreden wanneer 95% van de onboarding-taken zijn geautomatiseerd. (want de laatste paar handmatige stappen zijn vaak degene die het meeste tijd kosten), we willen voor de 100% gaan. Dit vereist dat alles in je implementatieproces gestandaardiseerd moet worden: van de ontwikkeling van templates tot licentiebestanden. Dit is niet zo eenvoudig als dat het klinkt, standaardisatie is waarschijnlijk het moeilijkste watje kunt bewerkstelligen in de wereld van IT, maar het is het zeker waard. We hebben klanten gezien met een implementatietijd van 2-3 weken en die nu terug gegaan zijn naar een onboarding-tijd van minder dan 5 minuten. Zoals al eerder benoemd, als dit is wat je nodig hebt; investeer dan in standaardisatie! 

Predictable bursting en unpredictable bursting 
Deze twee scenario's gaan hand in hand en hebben waarschijnlijk de grootste impact op wat voor platform je gaat kiezen bij het moderniseren van je applicatie. Het komt allemaal neer op het begrijpen van je klant en hun (applicatie) gedrag.  Als het waarschijnlijk is dat je een onverwachte piek in de vraag gaat ervaren (onvoorspelbare bursting), dan heb je een platform nodig dat dit goed en snel voor je opvangt en oplost. Dit is waar een groot deel van de Microsoft Azure Serverless – propositie om de hoek komt kijken. Serverless services kunnen automatisch en vrijwel onbeperkt schalen, zonder dat je moet wachten op voldoende resources om te worden ingericht (kijk eens naar Serverless computing). Je kunt je afvragen; wanneer komt dit voor? Dit komt voor als je platform bijvoorbeeld moet worden gebruikt om eerstehulpverleners te ondersteunen in scenario’s die je niet kan voorspellen (bij rampen of ongevallen bijvoorbeeld).  

Voorspelbare pieken aan de andere kant is wanneer je weet dat dit gebeurt maar je bent er niet zeker van wanneer exact en hoeveel resources je nodig hebt(want als je dit wel weet dan is het on en off scenario iets voor jou). Voorspelbare pieken kunnen op elke service in Azure gecombineerd worden. Gecombineerd met de juiste inzichten (bijvoorbeeld door gebruik te maken van Application Insights) kan je bepalen wat je minimum en maximum aantal benodigde resources is. De bandbreedte daartussen kan gebruikt worden om te schalen op basis van het gebruik van je applicatie. Dus wanneer de piek is, schaalt Azure je aantal instances die je nodig hebt naar de juiste hoeveelheid resources. Door een minimum en maximum aantal middelen en een grens vast te stellen kan je je financiën controleren. 

Concluderend 
Het kiezen van het juiste scenario bepaalt de beste strategie. Kies je voor een  lift-en-shift en is dit goed voor op korte termijn? Of kijk je naar meer complexe scenarios waar je op lange termijn meer toegevoegde waarde uit kan halen, maar wel eerst meer in moet investeren. Op basis van waar je nu bent en waar je naartoe wilt, kan je de juiste plek kiezen om te starten. Of het nu gaat om het verplaatsen of het nieuw opbouwen van je oplossing, je moet de verschillende mogelijkheden inzichtelijk hebben die Azure biedt voor jouw architectuur. Als je dit niet doet en kiest voor de korte termijnoplossing dan kan het zo zijn dat je wel klantwaarde toevoegt, maar er vervolgens een volledige revisie van het platform nodig is als je deze in de toekomst gaat uitbreiden. Er goed over nadenken, zowel over de lange als de korte termijn, kan je helpen om een toekomstbestendige oplossing te bouwen en de concurrentie ook in de toekomst voor te blijven.  

De komende periode publiceren wij van ieder onderdeel van de checklist meer informatie. Wil je dit niet missen? Laat je gegevens hier achter, dan houden we je op de hoogte.

Gerelateerde berichten