Migraties naar de Public Cloud zijn booming. Vrijwel elke digitale organisatie zet de Public Cloud in als onderdeel van de technologische strategie. Zoals elk project begint zo’n migratie met een goede kosteninschatting. Wat gaat de migratie ons kosten, maar vooral ook, wat ga ik straks voor maandelijkse factuur van AWS, Azure of GCP ontvangen? Vragen die je alleen kunt beantwoorden als je alles overziet, goed geïnformeerd wordt en de valkuilen kent. In deze blogpost vertel ik je wat een inschatting goed maakt en hoe je ervoor zorgt dat een migratie niet als een (budgettaire) ramp eindigt.
1. Begrijp wat de Public Cloud anders maakt
Een migratie naar de Public Cloud kan pas succesvol ingeschat worden als je snapt wat de Public Cloud zo aantrekkelijk maakt in vergelijking met On-Premise of Private Cloud. Wat we vaak zien is dat als dit niet goed begrepen wordt, applicaties zonder vooronderzoek (en eventuele aanpassingen) gemigreerd worden.
Lift-and-shift is de term die vaak voor zulke migraties gebruikt wordt. Lift-and-shift migraties zijn op zichzelf niet slecht, maar je laat veel van de voordelen die de Public Cloud biedt onbenut en je maandelijkse kosten vallen dikwijls hoger uit.
Een van de fundamentele verschillen van het werken met de Public Cloud is dat je vrijwel oneindig kunt schalen. Dat klinkt als iets positiefs, maar de keerzijde is dat je maandelijkse factuur ook vrijwel oneindig kan schalen. Vooral als je per ongeluk je credentials in public repositories zet kun je hier op een zeer nare manier achter komen. Maar als je geen alerts instelt en een van je collega’s een domme fout maakt door een maand lang dagelijks 40 terabyte aan nieuwe data op te slaan, kan dit ook aardig in de papieren lopen.
2. Geschikt of ongeschikt?
Laat vooraf onderzoeken of je applicatie wel geschikt is voor de Public Cloud.
De Public Cloud is zo populair omdat het flexibiliteit en schaalbaarheid biedt. Daar moet een applicatie mee om kunnen gaan. Het kan zijn dat een applicatie eerst aangepast moet worden. Refactoring noemen we dat. Je gaat bij het refactoren van de applicatie de architectuur en code dusdanig aanpassen dat de applicatie met het vluchtige karakter van bijvoorbeeld ‘auto-scaling groups‘ om kan gaan.
Als je dit niet doet kun je er na de migratie achter komen dat je maandelijkse kosten minstens net zo hoog zijn als in de oude situatie en je ondertussen een hoop budget aan het verhuizen van je problemen hebt besteed.
3. Voorkom een ‘big bang’
Een van de meest gemaakte fouten bij een cloud migratie is teveel in een te korte periode willen. Ons advies is de tijd te nemen voor zo’n omvangrijk project en klein te beginnen. Niet alleen houd je het project overzichtelijk en krijg je de kans alle functionaliteiten gefaseerd te testen, maar je krijgt ook een veel beter beeld van de werkelijke maandelijkse kosten. Door vroeg in het project in de praktijk te leren hoe de kosten worden opgebouwd, voorkom je dat je later in het project voor grote verrassingen komt te staan.
Je doet daarnaast ervaring op met je migratiepartner, de Public Cloud en je kunt de tijd nemen om beter in te schatten hoe je kosten kunt optimaliseren. Elk project kent tegenslagen en met dit voortschrijdende inzicht kan je de rest van het project soepel laten verlopen.
4. Selecteer de juiste partner(s)
Applicaties analyseren, migreren en de nieuwe omgeving(en) op de Public Cloud inrichten is specialistisch werk. Wie laat je dit specialistische werk doen? Je ziet op dit moment een driedeling in de markt.
Grote organisaties beleggen alles intern. Ze hebben de schaalgrootte en de middelen om interne specialistische teams op te bouwen. Een verstandige strategie omdat je kennisdeling met interne ontwikkelteams faciliteert en zo minder afhankelijk bent van derde partijen. Voor de komst van de Public Cloud waren veel van dit soort organisaties nog aangewezen op managed service providers (msp’s). Deze msp’s investeerden in datacentra en systeembeheerders. De Public Cloud verdringt in toenemende mate de rol van de msp’s door globaal gestandaardiseerde diensten aan te bieden die vaak goedkoper en beter zijn dan de traditionele msp’s aan kunnen bieden.
Traditionele organisaties kiezen er vaak voor met een (bestaande) msp samen te werken. Daar kleven nogal wat risico’s aan. Veel msp’s lopen erg achter met investeringen in kennis op het gebied van Public Cloud. Waarom investeren in Public Cloud als de marges op Private Cloud veel hoger zijn? Daarnaast ontbreekt het veel msp’s aan kennis op het gebied van applicatieontwikkeling. Plat gezegd: het zijn meestal, uitzonderingen daargelaten, voornamelijk systeembeheerders.
En dan zijn er nog de (vaak relatief jonge) specialistische bedrijven die zich alleen op Public Cloud richten. Niet gehinderd door een erfenis van klanten op een Private Cloud, zetten deze bedrijven vol in op Public Cloud. Zij zijn bij uitstek geschikt als je organisatie niet de slagkracht (of wil) heeft om dit werk intern op te pakken.
5. Calculators geven vaak maar een half beeld
Alle grote Public Cloud vendors bieden calculators aan waarmee je kunt berekenen wat je maandelijkse kosten in een ideale wereld zullen gaan zijn. Ik zeg ideale wereld, omdat deze calculators vaak een beperkt beeld geven van je werkelijke kosten. Al dan niet bewust missen veel services en worden inschattingen dusdanig complex gemaakt dat je er als leek eigenlijk maar weinig mee kan.
Een ander voorbeeld zijn de reserveringen die je kunt doen. Met reserveringen kun je veel geld besparen door vooraf capaciteit in te kopen, maar hier kleven allerlei nadelen aan die je niet in de calculator getoond worden. Combineer dit met het handmatig uit moeten rekenen van bepaalde diensten en je snapt dat het inschatten van de kosten niets iets is dat je ‘even’ doet. Vraag een onafhankelijke specialist je hiermee te helpen. Verzamel vooraf zoveel mogelijk statistieken (bijvoorbeeld huidig verbruik dataverkeer, resources, etc.) zodat je een beter beeld krijgt van de werkelijke kosten.
6. Bepaal een gedeelde strategie
We zien vaak dat de redenen om naar de Public Cloud te willen intern erg kunnen verschillen. Dat is op zichzelf niet erg, maar het is wel goed om vooraf in kaart te brengen waarom een migratietraject ingezet wordt. Wat bepaalt of het project succesvol is geweest? Wil je kosten besparen en waar zitten die kosten? Is een kortere time-to-market de inzet? Hoe meet je of dit daadwerkelijk gelukt is?
Bij het opstellen van een strategie zal er vrijwel altijd een discussie ontstaan. Het is beter deze discussie vooraf te hebben. Het klinkt als een open deur, maar een migratietraject zal vaker succesvol zijn als je vooraf definieert wat succesvol überhaupt is.
7. “Kill your darlings”
Geformuleerd door schrijver William Faulkner in een tijd ver voor de opkomst van de Public Cloud, maar zeer toepasbaar op hedendaagse migratietrajecten. Wat je als beste onderdeel van je strategie ervaart, verzwakt vaak de rest van je keuzes.
Wees niet bang fundamentele delen in je strategie te schrappen en opnieuw tegen het licht te houden.
De keuze voor partners is een goed voorbeeld hiervan. De wereld van Public Cloud verandert in zo’n rap tempo dat het maken van de juiste keuzes voor de strategie van morgen soms al een onmogelijke opgave lijkt. Onafhankelijke partners kunnen het verschil maken en je waarschuwen voordat je die ene figuurlijke doodlopende weg inslaat, struikelt en je migratie een (budgettaire) horror story wordt.
Meer lezen?
Je vindt meer informatie over onder andere strategie, executie en beheer op Public Cloud Migraties. Daarnaast schreven we een case over de migratie die we deden voor onze klant Beslist.nl. Ted van Dongen zei hierover “Het grootste project ooit voor Beslist.nl en ik had niet kunnen wensen dat het zo soepel zou verlopen en met zo’n goed resultaat”. Sjoerd schreef tevens een blog waarin hij je vijf redenen geeft waarom je juist (nog) niet naar de Public Cloud zou moeten migreren. Je vindt dat blog hier.
