Wanneer het zin heeft, en wanneer niet
De cloud betaalt zich terug bij schommelende belasting, bij systemen die snel moeten kunnen groeien, en bij organisaties die geen beheerteam willen onderhouden voor hardware. Hij betaalt zich niet terug bij een stabiele applicatie met een vaste belasting die al jaren prima draait op twee servers in een datacenter. Die twee servers kosten per maand minder dan hun tegenhanger in de cloud, zolang er iemand is die ze bijhoudt.
De vraag om mee te beginnen is dus: wat kost het ons nu, inclusief de mensen die het bijhouden, en welk deel daarvan lost de cloud op.
AWS of Azure
Draait uw organisatie op Microsoft 365 en logt iedereen in met een Microsoft-account, dan ligt Azure voor de hand: identiteit, rechten en beheer sluiten aan op wat er al is. Veel Nederlandse overheden en zorginstellingen zitten om die reden op Azure. AWS heeft het breedste aanbod en is bij veel softwarebedrijven de standaard; wie een team heeft dat AWS kent, hoeft daar niet van af.
Beide hebben regio’s in Europa, wat voor persoonsgegevens en voor de meeste aanbestedingen een eis is. Wat u in beide gevallen doet: de infrastructuur als code vastleggen (Terraform) en waar het kan op open standaarden bouwen (containers, PostgreSQL), zodat een overstap later mogelijk blijft en geen leverancier u vasthoudt.
Kosten die u niet ziet aankomen
De rekening van de cloud is voorspelbaar, maar alleen als u weet waar u op moet letten.
- Uitgaand verkeer: gegevens de cloud uit halen kost geld, gegevens erin zetten niet
- Machines die aan staan zonder iets te doen; een testomgeving die ’s nachts doordraait telt elke maand mee
- Reserveringen: wie een jaar vooruit vastlegt, betaalt fors minder dan wie per uur afrekent
- Beheerde diensten zoals databases en wachtrijen kosten meer per uur, maar besparen de mensen die anders het beheer doen
- Het supportplan, dat bij productie geen luxe is
Aanpak in fases
Eerst de basis: een landing zone met netwerk, identiteit, logging en kostenbewaking, als code. Dan de eerste applicatie, meestal de minst kritieke, zodat het team leert zonder dat er iets op het spel staat. Daarna één voor één de rest, en per applicatie de keuze: verhuizen zoals hij is, of herbouwen op onderdelen die de cloud beter doet.
Verhuizen zoals hij is gaat snel maar levert weinig op. Herbouwen levert veel op maar duurt lang. Meestal is het antwoord: eerst verhuizen, dan meten waar de kosten en de pijn zitten, en die stukken herbouwen.
Wat u zelf regelt
Drie dingen die de migratie zelf niet oplost.
- Eigenaarschap: wie beslist over de cloudomgeving en wie betaalt de rekening
- Een lijst van wat er draait, want elke migratie vindt systemen waar niemand meer van wist
- Tijd van uw eigen mensen; een migratie die alleen door een externe partij gedaan wordt, blijft van die partij
Migreer om een reden, kies de cloud die aansluit op uw identiteit en uw team, leg alles vast als code, en verhuis in fases: eerst de basis, dan het minst kritieke, en herbouw alleen wat aantoonbaar loont.