Ervaringen met overstappen naar Microsoft Azure

Een lift'n'shift is relatief snel gedaan, maar als je te maken hebt met een legacy omgeving dat je geschikt wilt maken voor de toekomst, zal je aardig wat werk moeten verzetten om het naar huidige technieken om te zetten. Denk van complete VMs waar een webserver in draait naar een cluster van containers die dynamisch opschalen afhankelijk van de load. En dan heb je het alleen nog maar over het simpel serveren van je content en Git repository (die overigens ook aardig wat werk vereist om te verhuizen).

Er kunnen ook taken op de achtergrond draaien, pipelines en automations om builds te controleren e.d. Dat moet je ook zo maken dat het resultaat hetzelfde is, zowel tussen de twee platformen als met elke run.

Ik heb wel eens in m'n eentje migraties gedaan tussen hypervisors en nieuwe hardware. Dat kostte dan een weekend bijna non-stop werk op wat pauzes voor eten en slapen na. MS heeft natuurlijk een heel team of meerdere wereldwijd om dit uit te voeren, maar dat maakt de hoeveelheid werk niet minder. Bij mij ging het om complete VMs, maar als je zoals eerder al aangegeven de techniek gaat moderniseren is dat een stuk complexer. Op m'n huidige werk zijn de ontwikkelaars ook bezig om hun code meer geschikt te maken om in containers te kunnen draaien. Afhankelijk van de technical debt die je hebt, is dit niet zomaar 'eventjes' gedaan.

Om te beginnen moet je je realiseren dat 'Azure' bestaat uit meer dan 200 verschillende diensten. De bekendste is waarschijnlijk die waar je een complete virtuele server afneemt waar je dan zelf software op installeert, maar er zijn ook talloze andere diensten voor bijvoorbeeld databases, verwerken van grote hoeveelheden berichten, speech, machine learning, AI, etc.

Daarnaast is een dienst als Github een product waarvan de ontwikkeling gestart is in een tijd dat cloud-computing nog geen ding was. Startend met een heel basaal platformpje waar in de afgelopen 17 jaar (!) allerlei dingen aan toegevoegd zijn. Hoe je dingen in zeg 2012 aan elkaar knoopte is misschien niet hoe je het anno 2025 zou doen, laat staan dat men op dat moment kon voorzien dat je ooit meer dan 100 miljoen gebruikers zou hebben. Een enorm complexe, grote omgeving dus met allerlei onderliggende issues en technology debt.

Zo'n migratie zal dus geen lift and shift zijn, want dan neem je alle onderliggende problemen mee die je vervolgens als nog een keer zult moeten aanpakken. Dat betekent dat ieder onderdeel bekeken moet worden en je zorgvuldig moet plannen hoe je van alle legacy af gaat komen en in plaats daarvan moderne en schaalbare diensten gaat gebruiken. Super super complex dus.

Als je het zo bekijkt is een tijdlijn van 18 tot 24 maanden helemaal niet zo bijzonder. Voor context, als hier in Nederland een bedrijf van gemiddelde omvang een ander bedrijf overneemt en ze allebei dezelfde technische oplossingen gebruiken (zeg Windows voor de desktop, AD en Entra voor authenticatie, Microsoft 365 voor collaboration) dan praat je al snel over een doorlooptijd van eerste uitdenken tot afronden van de uitvoering van snel 6 maanden tot een jaar.

Dan heb je natuurlijk bij kleine organisaties kleine problemen, bij grote organisaties grote problemen. Denk aan politiek, kritieke personen die ineens op vakantie zijn of een andere baan hebben gevonden, inhuur van externen voor specifieke zaken, etc.

Het blijft heel lastig om uit te leggen aan iemand voor wie dit geen dagelijkse kost is, maar met mijn 30 jaar ervaring waarvan de laatste 15 in de grootzakelijke hoek kan ik wel zeggen dat ik niet zo schrik van die doorlooptijd.

Het is een typisch geval van mensen zonder ervaring die denken dat je zoiets wel snel even doet. Kan toch niet moeilijk zijn. Gewoon even alles overzeten, live gaan en klaar ermee. Maar als je eenmaal enkele grotere ICT infra projecten gedaan hebt, dan besef je dat het zo eenvoudig niet is natuurlijk.

Bij ons in de firma is recent ook de beslissing genomen om weg te migreren van on-premise servers naar Azure. Wij hebben daar een tijdsvak van maar liefst 5 jaar voor voorzien. Niet alleen omdat we geen lift and shift willen doen, maar ook omdat we alles tussendoor draaiende willen houden zonder dat er echt mankracht bij komt.

Zoals @Jazzy aangeeft gaat Github dit waarschijnlijk ook als kans aanzien om alles te moderniseren. Hoewel ik er niet aan twijfel dat Github vandaag al veel met kubernetes en Infrastructure-as-Code doet, veranderd de onderliggende omgeving wel enorm. Dat wil zeggen dat je van 0 af aan je architectuur moet gaan herontwerpen. Nadat je dat gedaan hebt moet je je automatisatie gaan herontwerpen en grondig testen. Daarbij ga je ook proberen van verouderde concepten weg te gooien en nieuwere concepten op te zetten. Dat moet allemaal ook zeer grondig getest worden voordat je iets in productie kunt zetten.

En dan heb je nog het formaat van de omgeving. Ik heb geen idee hoe groot Github is, maar het zal een gestage migratie zijn waarbij eindgebruikers niet veel mogen zien van die migratie. Want dan lever je slecht werk af. Ook daarvoor zal men meerdere, tijdelijke oplossinen moeten zoeken en grondig uittesten voordat men die live zet.

En bedenk dan ook nog even dat Github onderdeel van Microsoft is en dus vermoedelijk sneller support kan krijgen en escaleren in geval van problemen dan wanneer externe partijen zo een migratie zouden doen. Daarnaast vermoed ik ook dat Microsoft de problemen wil voorkomen die ze hadden na de overname van Hotmail en de migratie die ze daar gedaan hebben.

Imre Himmelbauer schreef op vrijdag 10 oktober 2025 @ 10:11:
... Is het te zeggen welke Azure-diensten mogelijk interessant zijn voor GitHub?...

Bij zo'n enorme klus wil je eigenlijk zoveel mogelijk as-is migreren (lift n shift) en dus niet gelijk ook allemaal veranderingen en aanpassingen doen.
Als je dat wel doet, verlaagd dat de kans op succes en verlengd dat de migratietijd.

Zodra de migratie een feit is, zouden ze een 2e project kunnen opstarten om Github te moderniseren, tech debt weg te werken en mogelijk meer Azure services te gaan gebruiken.

Imre Himmelbauer schreef op vrijdag 10 oktober 2025 @ 10:11:
@Jazzy Is het te zeggen welke Azure-diensten mogelijk interessant zijn voor GitHub? Ik kan me namelijk bijvoorbeeld voorstellen dat Entra ID en vooral Blob Storage goede oplossingen zouden zijn voor dat platform.

Het zou best kunnen dat Microsoft op termijn een Entra ID dienst gaat gebruiken voor de identiteiten en het aanmelden, maar dat is een goed voorbeeld van een verandering die impact op werkelijk al het andere heeft. Stel dat een gebruiker op een repo klikt of een commit wil doen, dan moet worden bekeken wie de gebruiker is en of die daar rechten toe heeft. De kans is groot dat we het dan niet over één functie hebben die moet worden aangepast, maar dat er een wildgroei is van allerlei code die je moet controleren en aanpassen.

Blob storage zou best een onderdeel van de oplossing kunnen zijn, misschien ook niet. Zonder de architectuur van Github te kennen valt daar echt geen zinnig woord over te zeggen.

Ik begrijp dat je het probeert plat te slaan, maar het is toch een beetje als een Gamma binnenlopen en vragen in welk pad de spullen staan om Almere na te bouwen.

[ Voor 7% gewijzigd door Jazzy op 10-10-2025 11:37 ]

Imre Himmelbauer schreef op donderdag 9 oktober 2025 @ 11:40:
Naar aanleiding van dit stuk wilde ik graag een artikel schrijven over servermigraties, specifiek naar Azure.

Een "servermigratie" is een simpele lift-and-shift, en slechts één van de manieren om workloads te verplaatsen. Om de juiste strategie te bepalen wordt veelal het "7R-model" gehanteerd:

Select your cloud migration strategies

(Retire, Rehost, Replatflorm, Refactor, Rearchitect, Replace, Rebuild, Retain)

Rebuild is daarbij de meest complexe en meest tijdrovende. Ik schat de kans aardig groot in dat Microsoft nu voor de migratie van Github deze aanpak gaat hanteren.

A rebuild strategy is a full redevelopment of a workload using cloud-native solutions. This approach is appropriate when legacy systems are obsolete or when modernization isn't feasible. Rather than modernizing legacy functionality, you can reimagine the solution to use Azure capabilities like PaaS, automation, and AI. Some workloads required a rebuild, like DHCP server. For other workloads, it's better to deploy new instances of services in Azure rather than migrating them, such as Active Directory Domain Controllers.

[ Voor 3% gewijzigd door Question Mark op 10-10-2025 11:53 ]

Er is niet 1 mogelijke laat staan 1 beste manier voor een migratie. En verschillende mensen kunnen vanuit hun optiek en hun ervaring andere ideeen hebben. Waar ik vermoed dat geen van ons weet hoe het bij specifiek GitHub gaat.

Soms kan ‘oppakken en over de muur gooien’ handig zijn, soms niet. Wat dat betreft is https://learn.microsoft.c...-cloud-migration-strategy een leuke samenvatting van opties.

Een migratie naar Azure die bij mij gaande is, gaat over een aantal los van elkaar draaiende maar soms wel met elkaar gekoppelde serverapplicaties. Per applicatie wordt gekeken wat wijsheid is. As-is over zetten, inrichting en data migreren naar de SaaS-variant, nieuwe installatie in Azure en dan inrichting en data overzetten, iets anders kiezen. Op het juiste tempo voor de betreffende applicatie, wat ook betreft gebruikerstesten en de periode waarop het beste de downtime kan worden gepland. Tot nu toe is nul keer gekozen voor lift&shift.

En in Azure kan je dan meer aandacht hebben voor het beheer en de beveiliging van de dan daar draaiende servers. Qua (virtuele) netwerken, qua backup, qua beheer. Waar dan tenminste de (technisch) beheerders-accounts waar mogelijk wel in EntraID staan ook waar dat voor users en functioneel beheer nog niet kan - en worden beveiligd met de vele opties daar.

Edit: maar dat zal voor 1 hele grote gedistribueerde maatwerkapplicatie heel anders zijn.

[ Voor 3% gewijzigd door F_J_K op 10-10-2025 14:33 ]

Imre Himmelbauer schreef op vrijdag 10 oktober 2025 @ 13:55:
Ik heb het idee dat de reacties van @GarBaGe en @Question Mark wat tegenstrijdig zijn, klopt dat? Of is het mogelijk dat je eerst as-is migreert en vervolgens alsnog een complete rebuild van je systeem doet?

Dat is afhankeljk van het doel....

Als de technisch infra van de huidige omgeving op instorten staat zou het een goed doel kunnen zijn om zo snel mogelijk te migreren naar een Infrastructure-As-A-Service (IAAS) cloudoplossing (Rehost of Replatform).

Als het doel is om zo schaalbaarheid en prijstechnisch het meeste uit de cloud te halen, dan is overstappen naar cloudnative (Rebuild) een betere optie..

De eerste wordt ook wel "transitie" genoemd, en de tweede "transformatie". En deze kunnen ook in tijd na-elkaar doorlopen worden. Dus eerst de zooi zo snel mogelijk naar Azure (transitie), en daarna nog een transformatie doorlopen. De totale doorlooptijd van dat traject is alleen langer, kostbaarder en vraagt meer van mensen. Beide fases moeten immers gepland, getest en doorlopen worden (nog los van mogelijke tijdelijke impact op beschikbaarheid van diensten).

Imre Himmelbauer schreef op vrijdag 10 oktober 2025 @ 10:11:
Dank voor de uitgebreide reacties iedereen!

@Jazzy Is het te zeggen welke Azure-diensten mogelijk interessant zijn voor GitHub? Ik kan me namelijk bijvoorbeeld voorstellen dat Entra ID en vooral Blob Storage goede oplossingen zouden zijn voor dat platform.

EntraID kan voor de toekomst interessant zijn, maar in eerste instantie zal het aardige overkill zijn met wat Github doet mbt authenticatie en autorisatie tov wat EntraID allemaal biedt. Dat je uiteindelijk met een MS account ook gelijk op Github terecht kan zal een ding van de toekomst zijn. Maar voor de migratie van platform zal dat nog niet in de scope zitten. Er verandert al zo ongelooflijk veel, dat je niet nog eens je hele account opzet overhoop wilt gooien. Want Github werkt niet met gebruikersnamen dat tevens je email adres is.

Edit:
Vergeten te vermelden. Oracle heeft jaren geleden Sun Microsystems overgenomen. Sun had daarvoor Innotek gekocht, het bedrijf dat VirtualBox ontwikkeld. Ze hedden een eigen phpBB forum voor gebruikers, toen al en nu nog steeds. Maar nadat Oracle het in handen kreeg, is het login systeem overhoop gegooid en moet je met een Oracle account inloggen. Iets dat ook niet eventjes gedaan is, men heeft hiervoor het hele authenticatiesysteem van phpBB moeten vervangen en dat maakt het updaten van de forumsoftware niet makkelijker.
Dat zal met het verplaatsen van de Github login en alles wat er omheen zit (SSH keys voor je git client bijvoorbeeld) naar EntraID ook met de nodige uitdagingen komen. Ik verwacht dus niet dat ze dit ook gelijk doen als er 1,5 jaar en 6 maanden uitloop is uitgetrokken voor het project om Github naar Azure te verplaatsen.
/edit

Blob storage klinkt leuk, maar het is echt net afhankelijk wat er nu gebruikt wordt en of het ook zinvol is. Zie de infra van Tweakers zelf. Foto's en andere media kan bijvoorbeeld prima in een blob storage gezet worden. Maar wil je ook je site code daar opslaan om vanuit te serveren? Dat zal een stuk lastiger gaan. Pas dus op dat je niet zomaar wat buzz woorden gebruikt zonder de technische mogelijkheden en beperkingen te kennen van die termen. Er was ook een tijd dat je links en rechts de term 'blockchain' hoorde en men gebruikte het als 'het' antwoord op alles, zonder echt te weten wat het nou is.

Imre Himmelbauer schreef op vrijdag 10 oktober 2025 @ 13:55:
Ik heb het idee dat de reacties van @GarBaGe en @Question Mark wat tegenstrijdig zijn, klopt dat? Of is het mogelijk dat je eerst as-is migreert en vervolgens alsnog een complete rebuild van je systeem doet?

Een migratie 'as-is', dus lift'n'shift duurt over 't algemeen geen jaren. Het is tevens een redmiddel voor als de omgeving met plakband bij elkaar gehouden wordt. We weten niet in welke staat de Github omgeving het nu draait, maar ga er maar vanuit dat als er aanzienlijke tijd en mankracht wordt ingezet, het geen as-is migratie is maar meer een rebuild om het in het huidige Azure landschap optimaal te kunnen draaien. En reken maar dat er ook gedacht wordt aan wereldwijde hosting ipv een enkele datacenter in Virginia. Het is vaak genoeg dat een Azure regio compleet uit is gevallen en uren of zelfs dagen later pas weer operationeel was. Dit wil je met Github absoluut niet hebben. Ze hebben al genoeg concurrentie met Gitlab en als de beschikbaarheid in het gering komt, zullen er meer en meer project overstappen naar een andere dienst/hosting.

[ Voor 13% gewijzigd door Hero of Time op 10-10-2025 20:55 ]