Microsoft begint met migratie van GitHub naar Azure-servers

Microsoft gaat GitHub naar Azure-servers migreren, meldt The Verge. Bronnen van het medium melden dat het grootste deel van de verhuizing in twaalf maanden afgerond moet zijn. Chief technology officer Vladimir Fedorov zou de stap deze week intern hebben bekendgemaakt.

Volgens Fedorov heeft GitHub een gebrek aan datacentercapaciteit. Het ontwikkelaarsplatform wordt momenteel gehost op de eigen hardware van het bedrijf in de Amerikaanse staat Virginia. "We hebben beperkte dataservercapaciteit en de mogelijkheden om meer capaciteit online te brengen in de regio Noord-Virginia zijn beperkt", stelt Fedorov in een bericht aan GitHub-medewerkers dat in handen is van The Verge.

GitHub heeft al een aantal projecten naar Microsoft Azure-servers verplaatst, zoals Git in Azure en Azure Sites Automation. Volgens Fedorov zouden die eerdere migraties niet volgens plan zijn verlopen. Om ervoor te zorgen dat de overstap naar Azure nu wel goed verloopt, heeft het managementteam van GitHub medewerkers naar verluidt gevraagd om de ontwikkeling van nieuwe functies uit te stellen ten gunste van de migratie naar Azure.

GitHub streeft ernaar om binnen twee jaar volledig van zijn eigen datacenters af te stappen. Dat zou het bedrijf achttien maanden de tijd geven om de migratie uit te voeren, met een buffer van zes maanden voor eventuele vertragingen. Fedorov zegt intern dat het meeste werk in de komende twaalf maanden moet worden afgerond.

Tegenover The Verge bevestigt chief operating officer Kyle Daigle dat GitHub in de komende 24 maanden naar Azure migreert: "We moeten sneller opschalen om de explosieve groei in ontwikkelaarsactiviteit en AI-gestuurde workflows bij te benen, en onze huidige infrastructuur loopt tegen zijn grenzen aan."

Twee maanden geleden werd bekend dat ceo Thomas Dohmke GitHub na zeven jaar gaat verlaten. Hij blijft tot het eind van dit jaar aan. Dohmke krijgt naar verluidt geen directe opvolger; leidinggevenden van moederbedrijf Microsoft zouden zijn taken overnemen.

Reacties (51)

[whersmy]

Kan iemand mij uitleggen hoe dit gebeurt?

Ik neem aan dat het niet een kwestie is van 1 megafile drag en drop naar de server en vervolgens heel lang wachten?

[arnovr]

Ik vraag het me ook af, en vraag me eigenlijk ook af waarom het zo lang moet duren.

[david-v]

Omdat je niet alleen de data migreert. Je moet in Azure je infra uitrollen en dat zal voor zoiets als github uit heel wat onderdelen bestaan. Vnets, loadbalancers/gateways, firewalls, nsg, databases, storage, queues en noem maar op. Dit is een enorme klus. Een jaar is dan niet eens zo lang. De meeste verhuis trajecten die ik meemaak duren minstens een jaar, van tekentafel tot oplevering.

[i-chat]

en dan is nog maar de vraag of alle code (die voor bare metal is ontworpen) zomaar goed schaalt naar Azure clusters en meer van dat soort grappen. met een beetje pech moet je her en der zomaar nog tientallen FTE's aan bugs fixen vordat je uberhaubt die stationwagon full of tapes (zoals @rbr320 zo mooi aangeeft) op weg kunt sturen.

[codeneos]

Ik acht de kans heel klein dat GitHub applicaties direct op bare metal draaien. In deze tijd is dat gewoon niet schaalbaar genoeg en ook lastig en duur in onderhoud.

Zeker een bedrijf als GitHub zal iets van een Kubernetes cluster gebruiken of een ander vorm van virtualisatie.

[Accretion]

Github komt uit 2008 en is in rap tempo gegroeid.

De hele reden dat Microsoft hieraan begint is omdat het momenteel niet schaalbaar is?

D'r zal best een bult aan legacy meuk en slechte keuzes in zitten.

Natuurlijk, als je vandaag de dag zoiets zou bouwen, doe je het anders. Maar dan was het migreren niet zo'n problemeem/nieuws geweest.

[jaapzb]

GitHub is enorm schaalbaar, dat hebben ze wel aangetoond. Ze zijn immens groot.

Wat ze nu aandragen als reden is dat ze in hun eigen datacenter(s?) niet verder kunnen (of willen) groeien qua hardware. Aangezien ze van Microsoft zijn is het voor hun een logischere keuze om hun oude datacenter (met alle onderhoud die daarbij hoort) gedag te zetten en gebruik te gaan maken van de datacentra van Azure.

Waarom zou je al je eigen hardware gaan zitten bijhouden als je in hetzelfde bedrijf al een tak hebt die als expertise cloudinfrastructuur heeft?

[closefuture]

Waarom zou je al je eigen hardware gaan zitten bijhouden als je in hetzelfde bedrijf al een tak hebt die als expertise cloudinfrastructuur heeft?

Omdat toen ze LinkedIn naar Azure probeerde te verhuizen dit ook niet lukte.

[MehHuntah]

onwaarschijnlijke hoeveelheid data, die constant online moet blijven.. dus ik neem aan dat ze het over het internet doen, En het maakt ook niet uit hoe lang het duurt, zolang de gebruiker er niks van merkt.. gewoon 1 voor 1 repo voor repo. Als de git log head niet hetzelfde is er gecommit in de bron, dan doe je het gewoon overnieuw. Als het gelukt is schiet je een redirect erin zodat je naar de nieuwe gaat. Ten minste dat zou ik doen..

Maar goed mischien zijn er nog wel slimmere manieren

[hasseroderman]

Onderschat niet de bandbreedte van een vrachtwagen

[MehHuntah]

valt tegenwoordig wel mee hoor, je moet eerst al die data op tapes/ssds of zo copieren dat kost tijd , dan in een vrachtwagen loaden rijden en dan aan de andere kant restoren.. tegen die tijd is veel van je data aan de andere kant al gewijzigd dus dan moet je als nog een diff oversturen.. mischien is de bandbreedte wel groter, maar je backups zijn niet current.. dus dan moet je daar weer iets voor verzinnen met deltas.. of zo..

Hoop gerommel voor weinig voordeel. Ik denk dat er niet heel veel bedrijven tegenwoordig meer zijn die met vrachwagens vol tapes rond gaan rijden ;-)

[Deveon]

In een vrachtwagen laden? Microsoft heeft al jaren kant-en-klare containers die je enkel van stroom (eventueel generator) en glas voorziet om data naar Azure te migreren.

Eenmaal online in Azure zal het niet meer actueel zijn maar is de bulk in ieder geval over. Daarna online een diff en in batches over. Elke repo die over is zorgt weer voor meer bandbreedte voor de migratie.

[RSpliet]

Maar goed mischien zijn er nog wel slimmere manieren

... Toevallig is de data waar we het over hebben grotendeels letterlijk Git repositories! Ontworpen voor decentralised versiebeheer. Post-migratie synchronisatie zouden ze dus gewoon met git kunnen oplossen. Remote add de oude server, fetch-all om te kijken of de repo up-to-date is, zo niet git pull om de diffs binnen te halen.

[Buitenaerts]

Nou met zoveel data en zoveel gebruikers en geen downtime is dit niet een even simpel uit te voeren migratie.

[lenwar]

Of juist wel. Het is al zo groot in clusters, dat een migratie kan inhouden dan je iedere node vervangt met een nieuwe op Azure.

Ze gaan ‘slechts’ de onderkant vervangen. Zolang de nodes aan de bovenkant hetzelfde doen, is er weinig aan de hand.

[Noxious]

Ik heb wel wat flinke migraties gedaan (maar niets van deze schaal).

Bij echt grote migraties waarbij data echt naar een ander datacenter gaat wordt de bulk van de data vaak eerst fysiek vervoerd (zogenaamde 'data trucks' zoals Amazon's AWS Snowmobile) - waarna de boel gesynchronseerd wordt om gelijk te blijven, waarna je op een bepaald moment een switch van oude naar nieuwe backend endpoints krijgt.

[rbr320]

Never underestimate the bandwidth of a station wagon full of tapes hurtling down the highway.

— Andrew S. Tanenbaum[36]

[MBicknese]

Google biedt ook nog altijd de Transfer Appliance (https://cloud.google.com/transfer-appliance/docs/4.0/overview)

[locke960]

Het transport is niet de bottleneck. Het is het inlezen van al die tapes als je aangekomen bent

[SPee]

Zulke bulk data gaat niet via tapes. Die containers/trucks bevatten "gewoon" dezelfde opslag als in het datacenrer. Dus supersnelle SSD's. Snel om de kopie naartoe te schrijven en in het datacenter in te lezen.

[Accretion]

Wat als ze nu gewoon een enkele dag offline gaan en fysiek alle servers verplaatsen

[nugscree]

Oke, wie help om de fysieke servers de lucht in te gooien voor de migratie naar de cloud?

[rense]

Nog even uitgewerkt door Randall Munroe: https://what-if.xkcd.com/31/

[laurxp]

Het voordeel van deze schaal is nou juist dat fysiek transport niet meer nodig is. Voor een bedrijf als Microsoft is het aanleggen van een dedicated link tussen twee datacentra met een capaciteit van meerdere terabytes per seconden een fluitje van een cent: de hardware en expertise hebben ze al, de verbindingen bestaan al, het is alleen nog een kwestie van inpluggen en configureren.

Het huidige datacenter van Github zit in "northern Virginia" (wat in de praktijk dus zeer waarschijnlijk Ashburn is, zoom maar eens in op dit gebied), en Azure heeft daar ook het nodige staan. Het is dus puur een kwestie van één van de honderden DC-Dc fiberverbindingen in de regio (zoals de ring conduit) omzetten naar een directe synchronisatielink. Dat is véél makkelijker dan gehannes met een Snowmobile.

[Reactie gewijzigd door laurxp op 9 oktober 2025 03:54]

[Godjira]

Gezien ze er ten minste twaalf maanden voor nodig hebben, lijkt het mij aannemelijk dat ze dit in batches gaan doen. Ik ken GitHub alleen als gebruiker, hoe het onder water precies in elkaar zit weet ik niet. Het lijkt me echter aannemelijk dat ze het klant voor klant of repo voor repo zouden doen. Allemaal aannames natuurlijk.

[Damic]

OF wel iemand met een hoop tapes opsturen van de enen naar de andere DC en daarna een sync opzetten tussen servers of gewoon direct een sync opzetten.

[dasiro]

tapestorage is notoir traag naar huidige normen, om dat dan nog eens allemaal dubbel te moeten doen met zulk een gigantische hoeveelheid data die in productie moet blijven is gewoon nostalgische onwetendheid

[ZinloosGeweldig]

Ik denk dat alleen insiders je de specificaties kunnen geven.

Een platform als Github zal uit meerdere componenten bestaan die waarschijnlijk los gemigreerd kunnen worden. Dat kan natuurlijk ook weer op meerdere manieren. Zo kun je ervoor kiezen eerst hybride te gaan draaien en vervolgens de oude infra langzaam afschalen terwijl de nieuwe infra opgeschaald worden.

Of je doet een initiele data migratie (inderdaad bij grote datasets vaak via sneakernet), met op een cut-over moment nog een diff erachteraan. (Of na je initiele migratie, constant bij blijven syncen tot je cut-over moment).

Waarschijnlijk zal niet elke service op dezelfde manier gemigreerd worden, dat is echt een gevalletje case by case.

Gezien er 2 jaar over gedaan wordt lijkt mij dat er veel hybride gedraaid zal worden. 24 maanden voorbereiden en dan 1 cut-over moment voor een platform van deze schaal lijkt me onwaarschijnlijk.

[Reactie gewijzigd door ZinloosGeweldig op 8 oktober 2025 19:48]

[lenwar]

Ik vermoed bestaande nodes vervangen met nieuwe.

Nu draaien er 95 nodes op het andere oude en 5 op Azure. Dan zetten er één op Azure bij en halen ze hem weg bij de oude. De opslag kun je repliceren en synchroon houden.

(( uiteraard allemaal heel simpel verwoord 😄))

[whersmy]

Dus uiteindelijk is het gewoon handwerk en alles opnieuw bekabelen en inpluggen?

[lenwar]

Nee, alles in de cloud. Alleen het platform veranderd niet de dienst. (Heel heel heel versimpeld: alsof je Word op je nieuwe Windows 11 laptop installeert en daarna verwijdert van je oude Windows 10 laptop, en je data van de ene NAS naar de andere NAS overbrengt, maar dan op virtuele servers.)

[dvz89]

Kevin Fang heeft een leuke rapportage over een failure bij GitHub gemaakt, geeft je iets van een idee van hun infra.

https://youtu.be/dsHyUgGMht0

[usr-local-dick]

Kunnen ze na tig jaar eindelijk eens IPv6 gaan doen

[Gmount]

Kunnen ze toch gewoon

git clone GitHub.com

doen

[Marve79]

GitHub is toch van Microsoft. Waarschijnlijk draaien ze nu alles op een andere hypervisor, VMware oid. Dus dan ga je servertje per servertje naar Azure moeten overzetten al kun je dat wel automatiseren.

Ik neem aan dat het in eerste instantie een soort lift en shift operatie wordt en ze niet gelijk native Azure gaan voor bijv storage. Automatiseren tijdens het verhuizen is meestal niet zo'n goed idee.

En ik denk dat er wel een dikke lijn ligt tussen GitHub en Azure, misschien zelfs een stretched cluster. Dus dat verhuizen met tapes in een vrachtwagen lijkt me onlogisch. Het zal beetje bij beetje worden verhuisd.

[HKLM_]

Servertje voor servertje overzetten? Microsoft heeft gewoon iets als Azure VMware Solution waarbij je vanuit VMware naar azure kan of VMware gewoon binnen Azure kan draaien.

[vuurbal]

Maar dan is het niet echt goeie reclame als ze zeggen dat de eerste migratie niet volgens plan is verlopen en dat ze nu alle resources in de migratie stoppen.

Een soepele migratie naar de cloud maken ze wel reclame mee.

[Marve79]

Inderdaad zelfs dat kan nog, maar dan hoeft het geen 2 jaar te duren lijkt me.

[HollowGamer]

Het heeft niets met bezuinigingen te maken, en dat je die devOps nu kan doen bij Azure..

[0b1]

Hoe zit het nu met de content op GitHub die naar Azure gaat? Dan bedoel ik code, gevoeilige data in code, onveilige scripts/code etc... Kunnen ze dan vanuit Azure hun Microsoft Sentinel of Defender hier op loslaten voor allerlei redenen? Is er clausule dat ze niet aan de content komen of wordt de content geverifieerd bij upload naar het platform?

[latka]

Dat laatste gaat nooit werken voor 0-days: die kent de scanner pas later en dan zou een ingress scan niets toevoegen. Ik durf niet te zeggen of ze content scannen. Probeer eens eicar te uploaden zou ik zeggen.

[yatogami28]

Dit lijkt mij de eerste stap van Microsoft om van Azure Devops om te schakelen naar GitHub. Dit wordt al meer duidelijker voor de hoeveelheid nieuwe functionaliteit dat wordt ontwikkelt voor Gitthub.

[DaanHetEendje]

Ik hoop niet dat dit de migratie naar een volle dual stack applicatie tegenhoudt. Azure heeft helaas nog steeds belangrijke core diensten die ipv4 only zijn en GitHub is al jaren bezig om het e.e.a. volledig Dual Stack te maken.

[closefuture]

Microsoft heeft ooit ook geprobeerd zijn andere overname, LinkedIn, naar Azure te brengen. Dit is mislukt en hebben ze kennelijk opgegeven. Zie dit artikel: Not even LinkedIn is that keen on Microsoft's cloud: Shift to Azure abandoned.