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 scenario’s 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.
Lees ook de Azure migratie checklist deel 2.
