Migreren naar de cloud

Dus je wilt migreren naar een cloud omgeving. Super!

Maar hoe ga je zoiets bewerkstelligen? Er zijn verschillende opties beschikbaar en afhankelijk van de verwachtingen binnen de organisatie en de beschikbaarheid van IT’ers moeten er andere keuzes worden gemaakt.

In het geval dat je organisatie als doel heeft de operationele kosten van de software & cloud omgeving zo laag mogelijk te krijgen zal er relatief veel ontwikkelwerk moeten gaan plaatsvinden.
Wanneer er weinig tot geen IT’ers beschikbaar zijn voor een migratie kan het een valide keuze zijn om een zogenaamde ‘lift and shift’ migratie uit te voeren.

In principe zijn er geen slechte keuzes voor een migratie, mits deze goed is overwogen en de consequenties duidelijk zijn voor de organisatie & de uitvoerende partij(en).

Lift and shift

Normaliter is dit een migratie met de minste risico’s en zo weinig mogelijk effort. Wat wordt er mee bedoeld? Een ‘lift and shift’-migratie is een migratie waarbij alle virtuele machines van het huidige datacenter worden gekopieerd naar het nieuwe datacenter, in dit geval die van de cloud provider.

In de praktijk zullen de virtuele machines niet daadwerkelijk worden gekopieerd, aangezien dat te veel tijd & bandbreedte in beslag zou nemen. Er zijn gelukkig verschillende manieren om toch efficiënt de machines naar de cloud te migreren. Binnen het Microsoft Azure landschap zijn bijvoorbeeld Azure Migrate en de Azure Data Box beschikbaar. Met behulp van deze tooling wordt het uitvoeren van een ‘lift and shift’-migratie een stuk eenvoudiger gemaakt.

Hoewel de kosten van een ‘lift and shift’-migratie relatief laag zijn, zijn de operationele kosten wel een stuk hoger. Over het algemeen zijn de kosten van virtuele machines bij een grote cloud provider een stuk hoger vergeleken met die van dezelfde virtuele machines bij een reguliere hoster.
Deze kosten kunnen prima worden verantwoord, maar het is wel iets om vooraf rekening mee te houden.

Persoonlijk heb ik niets tegen een dergelijke migratie, mits deze van tijdelijke aard is.
Het is bijvoorbeeld prima om op deze manier kennis op te doen van het cloud platform, bekend raken met de inrichting, services en uiteraard de betalingen. Ook wanneer de huidige fysieke servers op het einde van hun levensduur zitten kan het kosteneffectief zijn om direct te migreren naar een grote cloud provider om op een later moment beter te gaan benutten.

Zodra men bekend is met wat de cloud, bijvoorbeeld Microsoft Azure, te bieden heeft kan er worden gekeken naar de huidige virtuele machines, software & services en hoe deze beter kunnen worden ingezet binnen het betreffende cloud landschap.

Containerization

Containers, Docker, Kubernetes. Allemaal woorden welke te pas en te onpas worden gebruikt wanneer men spreekt over het ontwerpen & ontwikkelen van een microservices platform in een on-premises omgeving of in de cloud.

Containers, en dan met name het Docker & Kubernetes ecosysteem, bieden heel veel voordelen voor het ontwerpen & implementeren van een schaalbaar platform dat locatie onafhankelijk (on-premises of bij een van de vele cloud providers) kan worden uitgerold. Er wordt gebruik gemaakt van enkele standaarden die ook zijn opgenomen in de Cloud Native Computing Foundation. Dit betekend dat de software cloud onafhankelijk is en er dus ook geen zogenaamde vendor lock-in is.

Waar containers ook een enorm interessante rol kunnen spelen is voor het migreren van on-premises oplossingen naar de cloud. Wat we vaak in de praktijk tegen komen is dat bepaalde software en services zijn geïnstalleerd op virtuele machines waar niemand meer precies weet hoe die zijn ingericht, hoe de software überhaupt op die machines is gekomen en zijn de kennishouders van de systemen in het ergste geval al vertrokken bij het bedrijf. Dit is vervelend, maar met de hulp van containers kan er toch goed naar de cloud worden gemigreerd en wordt de oplossing, vaak, ook nog een stuk goedkoper vergeleken met het hosten van een vergelijkbare zware virtuele machine.

Omgaan met legacy software

Een stuk legacy software kan vaak heel goed in een container worden geïsoleerd om zo bij een cloud provider te hosten. Het is natuurlijk wel van belang dat er tijd wordt genomen om uit te zoeken hoe een stuk software precies werkt en wat de afhankelijkheden zijn. Wanneer dit bekend is, is het relatief eenvoudig om hier een container voor te maken.
Zoals eerder geschreven is een container vaak vele malen goedkoper vergeleken met een virtuele machine.Een bijkomend voordeel is dat ook niemand meer de container kan aanpassen. Wanneer de software in de container vandaag goed werkt kan er met 100% zekerheid worden gesteld dat deze over 2 jaar nog steeds goed functioneert. Mits de afhankelijkheden van de software ook op exact dezelfde manier blijven werken.

Mocht het nodig zijn, dan kan er ook eenvoudig worden opgeschaald. Door gebruik te maken van een orchestrator, zoals Kubernetes, kan er worden geconfigureerd wanneer er meerdere instanties van 1 specifieke container moeten worden opgestart. Zo kan er worden opgeschaald bij een aantal HTTP-requests, berichten op een queue, gebruik van CPU, etc.

Het verdient de aanbeveling om sowieso Kubernetes in de gaten te houden en dan in het bijzonder een van de cloud specifieke implementaties, zoals Azure Kubernetes Service (AKS), welke vele voordelen bieden ten opzichte van een eigen installatie van Kubernetes.

Cloud Native

Dit is het speelveld waar ik zelf het meest actief in ben, cloud native oplossingen ontwerpen & implementeren (PaaS & SaaS). Wat betekend dit precies? Het betekend dat men zich, momenteel, conformeert aan een van de grote cloud providers, zoals Microsoft Azure, en oplossingen probeert te implementeren met behulp van de standaard services in het cloud platform, zoals Azure App Services, Azure Storage Queue, Azure Blob Storage, Cosmos DB, Azure SQL Database, Azure API Management, Azure Front Door, Azure Event Grid, Office 365, etc.

Vendor lock-in

Door gebruik te maken van al deze services kan er voor worden gezorgd dat de operationele kosten van de totaal oplossing relatief laag kan blijven. In dit geval zorgt Microsoft er namelijk voor dat alle services up-to-date blijven en kan er ook een efficiënte schaling van services plaatsvinden.

Wel betekent dit dat het bedrijf zich, voorlopig, conformeert aan het gebruik van deze ene cloud provider, zoals Microsoft Azure, en er een vendor lock-in wordt gegenereerd. Is dit erg? Wat mij betreft niet. Er zijn verschillende onderzoeken en proeven geweest die hebben aangetoond dat het goedkoper is om een oplossing 2x volledig opnieuw te ontwikkelen met cloud native oplossingen, dan het 1x te ontwikkelen van een cloud-generieke oplossing.
Natuurlijk biedt het gebruik maken van containers wel een oplossing tegen de vendor lock-in van een cloud provider, maar dat is ook alleen maar op globaal niveau. Al die containers zullen namelijk gebruik moeten gaan maken van externe services, zoals een queue, filestorage of een database.
Hiervoor zullen veelal oplossingen gebruikt worden die worden aangeboden als een cloud service. Het is natuurlijk prima mogelijk om deze oplossingen ook in een container te hosten, maar dan blijft het onderhoud & configuratie van die systemen ook bij je eigen organisatie.

Het oog op de toekomst

Persoonlijk vind ik het een prettige gedachte om te weten dat er duizenden engineers bij Microsoft bezig zijn om alle services in Azure te onderhouden & te verbeteren. Vaak zien we ook dat deze services na verloop van tijd goedkoper en/of sneller worden.
Op deze manier kan ik, samen met een ontwikkelteam, me bezig houden met het leveren van software oplossingen voor de eindklant in plaats van het onderhouden en beheren van de gemaakte systemen.

Een belangrijke kanttekening is wel dat er voor deze oplossing aanzienlijk meer effort noodzakelijk is van de ontwikkelaars & beheerders vergeleken met de andere oplossingsrichtingen. Dit alles om de uiteindelijke operationele kosten te minimaliseren. Ook zal er te allen tijde ontwikkel- & beheercapaciteit nodig blijven om het geheel goed te onderhouden, maar ook dit zal na verloop van tijd verminderen.

Tot slot

Zoals ik al in de intro schreef zijn er niet specifiek goede of slechte strategieën om te migreren naar de cloud, mits de voor- en nadelen maar goed zijn afgewogen.

Mijn persoonlijke voorkeur is het ontwerpen & ontwikkelen van een cloud native oplossing met PaaS en SaaS. In de praktijk ontkom je er vaak niet van om ook gebruik te gaan maken van containers en zelfs virtuele machines kom ik nog geregeld tegen in de ontwerpen van m’n uiteindelijke oplossingen.

Een goede architect of ontwikkelaar zal altijd de afweging maken of een bepaalde techniek wel of niet volstaat in een scenario en niet automatisch de keuze laten vallen op de nieuwste service ‘omdat dat cool is’.

Meer weten over cloud migratie? Onze experts helpen u graag verder! Neem snel contact op.