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 kampt GitHub met 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 (26)

[Gmount]

Kunnen ze toch gewoon

git clone GitHub.com

doen

[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.

[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.

[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.

[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

[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

[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?

[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

[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.

[HollowGamer]

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

[rvt1]

Na ja, als het zo traag wordt als Azure bij ons op het werk... Gitlab here we come!!!! :D Want een drama kan dat Azure toch soms zijn, traag als dikke str*nt, build duren vaak +30 minuten terwijl het op de eigen laptop 3 minuten duurt...
An dan die hele interface van Azure die vaak niet werkt.... De pipelines OMG OMG OMG!!! Heb nu al PTSD :D