GitHub gaat in twee jaar naar Azure migreren: waarom duurt dat zo lang?

Tekst

GitHub kondigde eerder deze maand aan dat het de servers gaat overzetten naar Azure-servers van moederbedrijf Microsoft. Momenteel gebruikt het ontwikkelaarsplatform nog eigen hardware in de Amerikaanse staat Virginia. De migratie kan tot twee jaar duren. Is dat niet heel erg lang voor een 'simpele' migratie van servers?

Voor onze eigen bofh Kees Hoekzema, die de Tweakers-servers zelf in beheer heeft, komt de opgegeven tijdsduur niet als een verrassing. Natuurlijk hebben we geen direct inzicht in de serverstructuur van GitHub, maar Kees kan wel een goed beeld schetsen van hoeveel werk er bij een servermigratie kan komen kijken.

Zeker bij de migratie van een groot platform als GitHub komt volgens Kees veel kijken. Bij een eenvoudige applicatie is het mogelijk om de applicatie eerst in de cloud op te bouwen zonder dat gebruikers erbij kunnen. De beheerders kunnen de applicatie testen en controleren of alles werkt. Vervolgens maken zij de datasynchronisatie, beveiliging en prestaties in orde en zorgen zij dat alles parallel kan draaien. Daarna wordt de overstap definitief gemaakt.

Microsoft rondde de overname van GitHub in 2018 af.

Bij ingewikkelde applicaties, zoals GitHub, voeren beheerders de migratie vaker per onderdeel uit. Op die manier kunnen beheerders snel terug naar de vorige, werkende situatie als er werkelijk iets misgaat. Dat maakt de migratie veiliger en zorgt voor minder downtime, maar zorgt ook voor een langzamere overstap.

Elk van die onderdelen van GitHub, waaronder functies zoals zoeken en gebruikersbeheer, draait op zijn eigen code. In theorie moet die software zo geschreven zijn dat het geen probleem is om deze over te zetten. Dat kan onder meer door gebruik te maken van configuratiebestanden in plaats van statische waarden, DNS in plaats van harde aannames over IP-adressen en abstracte lagen, waarbij een bepaalde laag verantwoordelijk is voor een aspect van het systeem zonder afhankelijkheden van de rest van het systeem. In de praktijk werkt dat vaak echter anders en moeten er toch zaken in de code worden herschreven of gefixt.

Rehost, replatform, refactor of rebuild?

De snelste manier van migreren is een zogenoemde lift and shift. Dit wordt door Microsoft een rehost genoemd. Daarbij wordt de infrastructuur vrijwel zonder veranderingen gemigreerd naar de cloud. Virtual machines en iaas worden overgezet naar iaas en paas naar paas. Deze migratie is volgens Microsoft snel en met minimale aanpassingen te doen en is geschikt voor workloads die stabiel zijn en geen directe modernisering nodig hebben. Ook een lift and optimize of replatform kan redelijk snel. Hierbij wordt de workload verhuisd naar een moderne hostingomgeving met minimale codewijzigingen om gebruik te maken van de voordelen van paasoplossingen.

Het is mogelijk dat een van deze strategieën onderdeel van het migratieproces vormt. Uiteindelijk zal GitHub waarschijnlijk echter een (gedeeltelijke) refactor, rearchitect of rebuild willen doen. Bij een refactor wordt code opgeschoond, waardoor hij efficiënter is en beter gebruik kan maken van de voordelen van de Azure-omgeving. Deze strategie beoogt de technische schuld, de 'schuld' die beheerders opbouwen door snelle oplossingen te kiezen in plaats van meer complexe, structurele oplossingen die langer duren om te schrijven, te verminderen.

Een rearchitect richt zich op het herontwerpen van de volledige architectuur om gebruik te maken van cloudnative mogelijkheden. De bestaande code wordt aangepast en geoptimaliseerd om de applicatie schaalbaarder, performanter en flexibeler te maken. Het geraamte van de huidige applicatie blijft nog wel staan, maar wordt drastisch vernieuwd.

Een rebuild is nog arbeidsintensiever: het platform wordt hierbij volledig herbouwd. GitHub ontstond in 2008 en de oprichters zullen toen geen rekening hebben gehouden met hoe het platform uiteindelijk zou groeien. Chief technology officer Vladimir Fedorov liet in een interne memo ook doorschemeren dat de schaalbaarheid van de huidige infrastructuur, die volledig draait op een datacenter in de Amerikaanse staat Virginia, beperkt is. Mogelijk is deze met een rearchitect te moderniseren, maar als dat niet het geval is, moet Microsoft het platform compleet opnieuw opbouwen.

Deze oplossingen kunnen eventueel in elkaar overlopen. Zo kunnen beheerders ervoor kiezen om eerst een rehost of replatform te doen om het platform zo snel mogelijk in een Azure-omgeving te laten draaien. Daarna worden tijdens een refactor alvast de technische schuld verminderd en de prestaties verbeterd met relatief kleine codewijzigingen. De beheerders krijgen in dat proces vaak ook meer inzicht in de beperkingen van de architectuur. Mochten zij die beperkingen als te zwaar beoordelen, dan kunnen zij alsnog kiezen voor een rearchitect of, als blijkt dat de huidige architectuur niet te moderniseren is, een rebuild.

Welke strategie Microsoft met GitHub gaat toepassen, is moeilijk te zeggen zonder inzicht in de architectuur. Bovendien zal dat nog verschillen per onderdeel. Een complete rebuild lijkt echter onwaarschijnlijk, aangezien GitHub in 2021 besloot over te stappen van een monolitharchitectuur naar microservices. Bij een monolitharchitectuur is de applicatie opgebouwd als één eenheid, terwijl deze bij microservices bestaat uit meerdere kleine, onafhankelijke inzetbare diensten. Een monolith is in principe makkelijker te beheren, omdat de hele applicatie een enkele codebase is. Deze architectuur is echter minder schaalbaar en flexibel. Diensten kunnen niet afzonderlijk worden geschaald, teams moeten allemaal dezelfde programmeertaal en databases gebruiken en applicaties kunnen vaak niet onafhankelijk worden gedebugd. Microservices zijn schaalbaarder, flexibeler en kennen minder afhankelijkheden, waardoor het onwaarschijnlijk lijkt dat het platform geheel opnieuw opgebouwd moet worden.

Tientallen petabytes aan data

Ook het overzetten van de grote hoeveelheid data zal de nodige tijd kosten. In 2022 schreef GitHub dat het 18,6PB aan data had opgeslagen. Dat zal in de tussentijd niet minder zijn geworden. Zelfs met een snelle verbinding duurt het waarschijnlijk maanden voordat alle Git-data van de ene naar de andere omgeving is overgezet.

Tot slot zal GitHub ook een tijdsmarge hebben ingebouwd. Dat schemerde al door in de verklaringen van chief technology officer Vladimir Fedorov. Hij wil binnen twee jaar volledig over zijn, maar zes maanden daarvan vormen een 'buffer' voor eventuele vertragingen. Binnen twaalf maanden moet het grootste deel van de overstap al voltooid zijn. Daarmee blijft het een grote overstap, maar het is niet waarschijnlijk dat de engineers van GitHub diep in 2027 nog beginnen aan de overgang van de zoekfunctionaliteit van GitHub naar Azure.

Een woordvoerder van GitHub geeft in een reactie aan Tweakers aan dat de migratie naar Azure nodig is om de 'explosieve groei in ontwikkelaarsactiviteiten en AI-gestuurde workflows bij te benen'. "Deze migratie zorgt ervoor dat GitHub het snelle en betrouwbare platform blijft waar ontwikkelaars op vertrouwen, terwijl we tegelijkertijd in staat zijn om meer te bouwen, meer te leveren en onbeperkt te schalen", geeft zij aan.

_{Redactie: Imre Himmelbauer • Eindredactie: Monique van den Boomen}

Reacties (69)

[Ricko1]

18,6 petabyte is 156028108.8 gigabit. Met 100 gigabit p/s snelheid zou dat 180,588 dagen duren om te versturen. Ongeveer 6 maanden.

Dat is echt een absurde hoeveelheid data om 'even' naar de cloud over te zetten. Het geeft aan wat voor operatie dit is.

Correctie: ik had unitconverters.net gebruikt om van petabyte naar gigabit te gaan. Die gebruikt een . Ipv , als decimaal teken. Mijn rekenmachine negeerde die daardoor. Het is dus inderdaad 18,0588 dagen en geen 6 maanden.

[Reactie gewijzigd door Ricko1 op 27 oktober 2025 10:02]

[Dimtemp]

"never underestimate the bandwidth of a station wagon full of tapes hurtling down the highway"

Van onze Nederlander Andrew Tanenbaum.

Verschillende cloud leveranciers hebben hier ook diensten voor, zoals Azure data box of AWS snowball.

[Jeroen]

Jammer dat AWS Snowmobile niet meer bestaat, dat was effectief gewoon een grote NAS in vrachtwagenformaat (100 PB) https://aws.amazon.com/blogs/aws/aws-snowmobile-move-exabytes-of-data-to-the-cloud-in-weeks/

Ik kan me voorstellen dat zoiets nog wel op te bouwen is voor een enkel project zoals GitHub.

[YopY]

Ja denk het wel, alhoewel de dichtheid van harde schijven sinds dat een ding was natuurlijk flink verhoogd is; ik zie in de Pricewatch tegenwoordig harde schijven van 30 TB, daar heb je... 620 stuks van nodig om die 18,6 PB over te hevelen.

Ik heb er verder geen verstand van maar ik denk als die zeecontainer nog gebruikt wordt dat ie 10x zoveel data als toen kan verschepen.

[MRIdev]

Of misschien wel met vrachtwagens met heel veel opslag. Dat werd vroeger vaak genoeg gedaan. Ik kan me indenken dat afhankelijk van de snelheid van de beschikbare verbinding, de hoeveelheid data en de fysieke afstand dit een snellere en goedkopere oplossing is.

[joker1977]

Dat is nu toch een stuk lastiger. Afhankelijk van hoe je dat doet kan ik me voorstellen dat het "backuppen" en "restoren" samen op een lagere snelheid gaat dan een vlotte netwerk-verbinding.

En het is veel arbeidsintensiever. Je kunt vrij eenvoudig een script maken dat de data overjakkert. Met backupmedia, wisselen, inladen in dozen / pallets, terugplaatsen en alles is veel arbeidsuren gemoeid.

[JayPe]

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

[Squixx]

voor archived spul kan dat wellicht wel, maar active repo's kunnen niet ff 'onbeschikbaar' zijn, of je zult ze na de move alsnog moeten syncen. Ik gok toch dat ze zoveel mogelijk 'hot' willen verplaatsen

[Scriptkid]

Repos zijn volledige DIF states,

Je kunt ze dus juist super makkelijk verplaatsten en laten delta repliceren dat is juist wat GIT zo krachtig maakt. Dat zit zelfs native in het Git design en is de essentie.

Ze kunnen dus makkelijk een kopie naar azure vault doen en die dan met de courier naar volgende DC brengen en dan daar op servers installeren en een git pull van de originele server laten doen , dan daarna als master over nemen.

[GertMenkel]

Ik denk dat de bulk van het werk in issues, pipelines, releases, en andere niet-source gaat zitten. Een git pull zou een paar weken aan verschil wel efficiënt kunnen verwerken, maar de database synchroniseren gaat zo makkelijk nog niet.

[YopY]

Ze zullen niet onbeschikbaar zijn, maar ze kunnen al wel 99% van de data overhevelen en dan als laatste een sync operatie doen. (even heel vereenvoudigd, het zal natuurlijk een stuk complexer dan dat zijn).

D'r zal een periode zijn waarbij ze zowel hun bestaande als de Azure opslag in sync laten lopen, dwz dat alle data 2x weggeschreven wordt. En als dat goed gaat dan zullen ze stukje bij beetje alles naar Azure laten lopen.

[Reactie gewijzigd door YopY op 27 oktober 2025 11:26]

[jvdberg]

Azure biedt zoiets gewoon als service: https://azure.microsoft.com/en-us/products/databox/

[Mellow Jack]

Valt wel mee, kan me voorstellen dat ze het in batches hebben gegaan en daarna de diffs oversturen. Alsnog een flinke klus maar het is prima te plannen

[eBoR]

Volgens mij zit je er een factor 10 naast

[david-v]

Hij zit er niet naast, de omzetting van byte naar bit (x8) zit er ook nog bij. Snelheid van een netwerk meet je in bit/s.

Deze hoeveelheid informatie zal hier niet via netwerk maar via Azure Storage data box plaatsvinden. Met capaciteiten van 525 terabyte heb je alsnog wel iets van 35 van deze "dozen" nodig of 35x met de doos heen en weer.

Ik heb nog nooit met zulke extreem grote datasets gewerkt, het zal hoe dan ook best lang duren om dat over te zetten en daarna te blijven syncen. En dat zonder dat je data kwijtraakt, één record missen kan ervoor zorgen dat iemand zijn github project kwijt is.

[eBoR]

Reken maar eens na. Dan kom je op 18 dagen uit

[david-v]

Ooohh, het aantal dagen. Ja, je hebt gelijk, factor 10 ernaast, ik keek alleen naar de omzetting van petabytes naar gigabit. Me bad.

[pietje63]

Als ik zijn getal in windows rekenmachine plat dan volt de . weg waardoor je 1560281088 in plaats van 156028108.8 krijg (en je de factor 10 te hoog uitkomt.

Maar worden dergelijke hoeveelheden data over een lijn heen gepompt of eerder via vrachtwagen met harddisks?

[lenwar]

Het is denk ik goedkoper om het te kopiëren. Kun je überhaupt bij een Azure-datacenter aankomen met een paar kratten SSDs?

Het hoeft ook niet allemaal tegelijk hè? Project voor project of zo?

[2Keys]

Hangt er ook een beetje vanaf hoe de data is opgebouwd. Als ze het kunnen splitsen en 10x 100gbit doen gaat het al veel sneller.

[supersnathan94]

Hebben ze 10x 100gbps datacenter uit liggen ja?

Weetje wat dat kost?

Intern twijfel ik er niet aan, maar zo even naar het GBO, denk het niet.

[2Keys]

Mijn aanname was dat ze backups gebruiken en die fysiek naar het nieuwe datacentra kunnen brengen om daar de data overdracht te doen.

[supersnathan94]

Zou ik een prima idee vinden. Klinkt als 1 keer vrachtwagen volladen en gas.

Je wil ook niet je uitgaande lijn continu belasten.

[La1974]

Inderdaad. Ca. 18 dagen ipv 180. Valt dus wel mee

[raschaoot]

Ik kom op 18 dagen uit, wie van ons heeft een rekenfout gemaakt?

[johnny2000]

Waarschijnlijk zijn ze nu al bezig met kopiëren en zorgen dat ze incrementeel op moment X redelijk snel over zijn.

[Marzman]

Zouden ze geen toestemming van de klanten nodig hebben? Of hebben die al ergens een vinkje gezet ?

[Boronguyd]

Ik vond het juist vrij weinig, microsoft is wel een absolute behemoth van een bedrijf he, en github is losstaand ook zeker geen kleine speler. Staat ongeveer gelijk aan anderhalf millioen uur aan youtube 4k videos kijken of 10000 icloud gebruikers op de hoogste tier. Zoveel data zal voor een bigtech bedrijf als microsoft peanuts moeten zijn. En naast dat je er een factor 10 naast zit, zal github toch ook wel beschikken over een terabit uplink.

[MadEgg]

Een factor 10 verkeerd, een week of 3 is genoeg met 100 gbit.

Maar als ik dit zou regelen zou ik niet alles in een keer overzetten. Eerst zorgen voor een functionele omgeving bij Azure. Je kunt dan een flinke schifting maken: repositories die "idle" zijn kun je veilig overzetten en de kans dat er in de tussentijd iets verandert is vrij klein.

Dan ga je beetje bij beetje repositories overzetten en ondertussen monitoren of alles naar wens blijft werken, met een eenvoudige rollback.

Incrementeel is ook zeer goed te doen, zolang je geen grootschalige rebases doet blijven de files in een git repo ongewijzigd en nieuwe wijzigingen hoeven alleen maar gesynchroniseerd te worden. Dit is juist iets waar het Git-protocol voor ontworpen is.

Al met al denk ik niet dat de data-transfer enige bottleneck gaat zijn hier.

[supersnathan94]

Eens. Als er iets goed gemaakt is voor dit soort eenvoudige migraties is het wel GIT. ik zou overigens in eerste instantie gewoon met databoxes je backup terugzetten. Je wil immers niet je main line dichttrekken. Dat gaan je gebruikers merken.

Nee ik denk dat het migreren van github actions en bijbehorende infra een stuk lastiger is.

[lenwar]

Even los van de getallen, zal GitHub niet op een fysieke locatie zijn. Ik durf er om te wedden dat het over de wereld heen verspreid staat? Dus stel dat het op 10 plaatsen staat en het weer naar 10 plaatsen gaat, dan kun je het dus al delen door 10 (al is dit wel een heel theoretische manier van werken. 😄

edit:
Blijkbaar staat het toch niet wereldwijd verspreid. Thanks @swhnld

[Reactie gewijzigd door lenwar op 27 oktober 2025 07:49]

[swhnld]

Volgens het artikel staat het maar op een plek, in de Amerikaanse staat Virginia. Dat kan ook wel, want ontwikkelaars syncen de code lokaal om in hun ontwikkelomgeving ermee aan de slag te gaan.

[DutchReaper]

In 2018 hebben ze ooit downtime gehad omdat door een fout data onjuist werd gemigreerd naar een andere datacenter. Het lijkt me ook sterk als alles op 1 datacenter zou draaien.

Hier een korte uitleg over de situatie, (er zijn waarschijnlijk betere links te vinden, maar deze vind ik als eerste) https://bytesizeddesign.s...-second-network-issue-led

[Scriptkid]

Weet alleen wel zeker dat je die snelheid niet gaat halen,

Alles komt van trage storage af en zijn supere kleine files dus dus geen snelheid halen,
Je moet dan zoveel gaan coordineren met parralelle transfers dat is bijna niet te doen.

of ze moeten er vmdk`s van de disken maken.

[Patriot]

Je berekening klopt niet. Eén petabyte is 8 miljoen gigabit. De berekening is dan als volgt:

(((18.6*8000000)/100)/3600)/24

En je komt uit op 17,22 dagen. Ofwel 17 dagen, 5 uur en 20 minuten.

[bigtree]

Het meest opzienbarende is voor mij dat GitHub anno 2025 alles in 1 datacentrum heeft staan.

[dennisameling]

Dat lijkt niet helemaal te kloppen.

• Enterprise klanten kunnen met Data Residency kiezen om hun data in de EU, Australië of US op te slaan.
• Deze video over een storing in 2018 spreekt over databasereplicatie tussen de US East and West Coast.

En zo zijn er mogelijk nog meer voorbeelden te vinden. Ze zullen ongetwijfeld een "main" datacenter hebben, en mogelijk is dat de locatie in Virginia waar het artikel over spreekt.

[Travelan]

Ja, want het is niet alsof Git zelf decentraal is, en er daardoor miljoenen zo niet miljarden kopieen zijn van repositories gehost in Github...

[Jeroen]

Het plotseling permanent verdwijnen van de data van GitHub zal toch enige impact hebben. Ik ga er even vanuit in dit hypothetische scenario dat GitHub zelf snel weer online is, maar zonder data. Mensen die nu actief bezig zijn met projecten kunnen hun repo waarschijnlijk snel weer online zetten, maar het levert wat storing en extra werk op voor een aantal dagen en zaken moeten weer opnieuw worden geconfigureerd, zoals de toegang voor gebruikers tot de repo's, ssh keys, etc.

Daarnaast zijn er denk ik veel repo's die niet meer zo actief worden onderhouden maar waar wel mensen gebruik van maken, en daarbij specifiek verwijzen naar de hosting ervan op GitHub. In het beste geval moeten deze gebruikers er eerst achter komen waarom iets niet werkt (zoals een build pipeline), en dan de verwijzing aanpassen. Niet iedere maintainer zal echter tijd hebben om onmiddellijk deze repo's weer ergens te hosten en de nieuwe locatie bekend te maken, maar anderen die daarvan afhankelijk zijn zitten in de tussentijd met de gebakken peren en moeten een andere oplossing verzinnen.

Hoe dan ook creëert het event waarschijnlijk een hoop werk waardoor er een voelbare impact is over een aantal maanden heen. Maar het wereldschokkende deel is waarschijnlijk met en paar dagen wel voorbij.

[supersnathan94]

Tsja zou ik us east 1 van AWS pakken. Dan gaat de helft van het internet op zwart

[Skydream]

Het artikel is er best wel vaag over, maar om bij demand cloud hosting partijen als AWS, Google Cloud en in dit geval Azure te hosten, gebruik je allerlei platform specifieke SDK's. Als je geluk hebt gebruikt GitHub al een groot open source pakket als Kubernetes en wellicht gebruiken ze dan op Azure ook de Kubernetes voor 'container orchestration'. Maar ze kunnen er ook voor kiezen om voor een Azure specifieke oplossing te gaan (geen idee wat Azure biedt, maar AWS heeft als tegenhangers naast Kubernetes (EKS) ook ECS en ECS Fargate).

Daarmee ben je er niet. Voor zaken als de compute, DNS, container registry en object storage (respectievelijk bijvoorbeeld EC2, Route 53, ECR en S3 bij AWS), heb je allemaal aparte SDK's om te integreren. Alleen dit al beperkt je mogelijkheid om van platform te veranderen al door de kosten van het herinrichten van de infrastructuur code.

Zonder verder inzicht in de plannen kun je er niet veel over zeggen, maar ik verwacht met dit tijdspad dat ze zoveel mogelijk 1:1 de infrastructuur zullen migreren en niet ook nog schakelen naar nieuwe lock-in technologieën zoals Azure Cosmos.

Ik kan niet 1,2,3 vinden waar ze nu gehost worden, maar het lijkt erop dat ze het nu helemaal zelf doen [1], en dat is waarschijnlijk net ietsje makkelijker dan van bijvoorbeeld AWS naar een Azure, omdat het waarschijnlijker is dat er minder gebruik gemaakt wordt van locked-in services hebt van een cloud providers. Desalniettemin is dit lastig om goed te analyseren voor een partij zo groot als GitHub, en met zo weinig publieke informatie.


[1] https://github.com/holman/ama/issues/553 (2017)

[Reactie gewijzigd door Skydream op 27 oktober 2025 08:58]

[Scriptkid]

Een groot voordeel,

Ze kunnen gewoon de azure engineers vragen mee te helpen, het is natuurlijk een dochter van Microsoft.

[Blokker_1999]

Als je naar Azure Kubernetes wenst te gaan moet je alsnog je infrastructure-as-code daarop aanpassen. Maar met alleen het Kubernetes platform ben je er natuurlijk niet. Je schrijft DNS, maar wat dacht je van netwerken, firewalls, ... . Ook dat moet allemaal ontworpen en opgezet worden.

[supersnathan94]

Het grootste deel zal hem inderdaad zitten in het moderniseren van de stack. Dus het opnieuw ontwerpen van netwerk en segregatie, hoe ga je om met beheer van je machines, wil je intern ook firewallen? Dat soort vraagstukken.

[Riesch]

Nou, nu maar hopen dat Github met deze migratie ook eens het moderne internet gaat omarmen.
Iets met IPv6 enzo....

[GertMenkel]

Azure is notoir als het op IPv6-ondersteuning aankomt, dus ik vrees dat de kans dat ze naar de 21e eeuw komen met hun netwerk alleen maar afneemt.

[yay]

Mocht je niet weten waar 'bofh' op slaat in 'Voor onze eigen bofh Kees Hoekzema' het is een verhalen serie uit de jaren 90 gepubliceerd op Usenet door Simon Travaglia. Hier een archive: https://bofh.bjash.com/

[gertk]

Dan staan er nog wel wat afko' s en acro' s in de tekst :-) (afkortingen en acronymen)

[TheMaster004]

Downtime wordt in het artikel slechts één keer vluchtig genoemd. Zelf ben ik betrokken geweest bij migraties van kleine applicaties, denk aan Nationale Nederlanden, pensioen beheerder of een Duitse marktleider chemicals en distribution. Elk zo'n project duurde steeds minstens een jaar. Dit zijn geen partijen waar software development core business zijn, ze zijn er dus niet zo erg goed in. Ze hebben ook vaak niet zoveel gebruikers als een FAANG of een Github en kunnen zich soms wat makkelijker downtime permitteren. Ik heb gezien dat een aantal uur tot zelfs 48 downtime geaccepteerd wordt. Maar bij een Github zal het ontstaan van downtime veel minder getolereerd worden. Hier zal downtime lijden tot wantrouwen in het product en door netwerk effect gebruikers verliezen die misschien al andere frustraties hadden. 2 jaar is echt niet gek, het kan ook vast sneller, maar dan lever je in op testen en stabiliteit van je platform wat lijdt tot meer downtime. De keuze is een afweging. Maar vergeet niet dat Github gewoon enterprise SLA's heeft. Dus dat er ook zeer serieuze applicatie development lifecycles door Github gefaciliteerd worden, dus in dat opzicht is het geeneens een keus. Het moet gewoon 100% veilig en stabiel gemigreerd worden, en dan is 2 jaar niet gek voor een applicatie van deze schaal.

[Niemand_Anders]

Doen ze niet gewoon organisch machines uit faseren. De gemiddelde leeftijd voor een server is normaal 3 jaar, dus het voelt meer dat zodra een server (machine) end of life heeft bereikt, dan ze dan een blok omzetten. Anders heb je een gigantische afschrijving van je hardware.

Nu weet ik niet of Microsoft GitHub een azure factuur gaat sturen, maar duizenden servers hosten bij Azure is niet goedkoop.

Ik hoop niet dat Microsoft de naam GitHub gaat laten vallen, want GitHub is veruit de bekenste git hoster.

[FrostyPeet]

Zou het zo erg zijn als GitHub planmatig één dag offline is voor een efficiënte overgang? Dan kunnen ze rustig het nieuwe systeem optuigen en testen met dummy data of stukjes echte data. Als dat goed werkt alles één dag offline, de data overzetten en opstarten.

Als je elke keer een stukje overzet, kan dat elke keer fout gaat en onvoorziene rimpeleffecten veroorzaken. Dan creër je nog meer onrust.

Het is wel leuk voor de Automatiseerders om in hun CV te zetten dat ze ervaring met zo'n grote migratie hebben. Ook leuk om aan een lang project te werken.

[GeroldM]

GitHub gaat in twee jaar naar Azure migreren: waarom duurt dat zo lang?

Om GitHub gebruikers tijd te geven om hun projecten veilig te stellen bij andere cloud diensten?

[Reactie gewijzigd door GeroldM op 27 oktober 2025 06:27]

[Luchtbakker]

Welk alternatief? Er zijn uiteraard andere spelers. Maar heel eerlijk? Welke ècht goede alternatieven bestaan er nou als github? Github heeft zo ongelofelijk veel tools, mogelijkheden, user base en vooral bekendheid dat je ook echt niet anders zou willen.

[latka]

Ja hoor. Jezelf.opknopen aan de features van GitHub is precies wat ms wil en noem je vendor lock in. Welkom bij Big Tech: we're happy you are here and will never leave.

Dus begin met definiëren van 'echt goed' : gitea doet 80% van wat ik nodig heb. Een jenkins ernaast voor CI en een Nexus server voor repos/images etc. Alleen ticketing blijft lastig. Had hiervoor altijd hosted Jira maar dat is er niet meer.

[swhnld]

Je hebt helemaal gelijk. Ik vergelijk het altijd met een auto. Een Dacia Sandero is goedkoop en brengt je van A naar B. Toch kopen meer mensen een Volkswagen die luxer is en meer toeters en bellen heeft.

Jij hebt hier een Dacia oplossing, toch gaat het merendeel voor GitHub om dezelfde reden. Zeker in grotere teams heeft dat voordelen door die extra toeters en bellen. En wil je puur ontwikkelen is het ook makkelijk minder onderhoud te hoeven doen.

[djhartman]

nou ja, Dacia vind ik wat overdreven. Ik zie het meer als een Mercedes disco busje van een Uber driver. Die is gewoon niet van jou, je kan nooit van de prijs op aan, maar wel veel toeters en bellen.

[DdeM]

Welke toeters en bellen heeft github welke voordelen bieden bij grote teams? Volgens mij is verruit het meeste gebouwd op Git en dus ook wel beschikbaar op andere platformen die Git gebruiken als basis.

[CAPSLOCK2000]

Jij hebt hier een Dacia oplossing, toch gaat het merendeel voor GitHub om dezelfde reden. Zeker in grotere teams heeft dat voordelen door die extra toeters en bellen. En wil je puur ontwikkelen is het ook makkelijk minder onderhoud te hoeven doen.

Als we dan toch met auto's gaan vergelijken dan gooi ik graag in de groep dat "we" veel te grote auto's kopen mét benzinemotor terwijl we weten dat ons klimaat aan het instorten is. Iedereen heeft z'n eigen verhaal waarom er zo'n Amerikaanse vrachtwagen voor de deur moet staan en waarom dat op benzine moet.

En het klópt dat die auto's allerlei handige voordelen hebben, maar ondertussen gaat klimaatverandering door en de hele samenleving moet meebetalen aan dijkverhogingen. In beide gevallen kan de markt dat niet niet oplossen want voor vrijwel iedereen is het gunstiger om niet te veranderen tot de meerderheid de overstap heeft gemaakt.

MS heeft Github niet gekocht omdat het ze het niet kunnen nabouwen MS heeft de klanten gekocht in de wetenschap dat het makkelijker is om klanten te kopen dan om ze overtuigen om over te stappen op een vergelijkbaar product. Ik kan geen van de klanten echt iets verwijten, maar we weten ook wel dat MS geen liefdadigheisdinstantie is en dat de prijs steeds hoger zal worden naarmate de concurrentie verder wordt weggedrukt.

[lenwar]

Je doet nou net alsof het gek is om de functies van je gebruikte software te gebruiken?

Jij kiest ervoor om meerdere producten, van verschillende organisaties te gebruiken. Kun jij makkelijk zonder veel impact overstappen van Jenkins? Zonder dat je veel effort moet steken in de rest? Meer dan dat je diezelfde functies bij GitHub zou gebruiken?

Uiteindelijk graaft iedereen zich in de tooling die ooit gekozen is. En of die tooling van Microsoft of een ander is, maakt in de basis niet uit. Het is altijd lastig om te migreren naar iets anders. Het enige dat je kunt doen, is bij het instappen, een exit-strategie te verzinnen.

[latka]

Verschil is dat de tools die ik noem vrijwel geen exit strategie op voorhand vereisen omdat je de hosting zelf kunt doen. En ook, omdat het niet 1 leverancier is, je noodgedwongen op open-API's en koppelvlakken moet vertrouwen ipv. undocumented hidden features. Ik gebruik github voor zakelijke dingen wel maar zou het zelf nooit kiezen juist om dit soort cloud-shenanigans te voorkomen.

[d3x]

als je zelf een nexus opzet dan voldoe je al niet meer aan 99% van het profiel dat hier rondloopt op deze site.... die 99% is in lijn met het verhaaltje dat de redactie hier brengt...

ze hebben al jaren een scale out service opgebouwd, nu zal die een hybride service worden, waarbij je gaat merken dat oude data dan een soort van 2e lijn data is en deze zullen dan wel cloud move krijgen stuk voor stuk.

we zullen het zien in hoeverre dit toegevoegde waarde is en hoe "cloud" moveable ze nog zullen zijn tussen M-A-G-O en anderen...

Een beetje degelijke firma zou toch al een eigen nexus moeten hebben....maar er zijn genoeg altijd en overall wel 100% cloudservice gebruikers.

[Reactie gewijzigd door d3x op 27 oktober 2025 08:02]

[Skydream]

Als het puur om de git hosting, issue tracker en piprlines gaat zijn er prima alternatieven te vinden in GitLab, Forgejo/Codeberg en Bitbucket.

Zodra je project leunt op ontdekbaarheid en de open source communiy moet je toch nog steeds echt bij GitHub zijn.

Ik werk professioneel met bitbucket (ik ben geen fan helaas), en ben actief in de open source wereld in de Rust community zowel als contributor als maintainer, en hier zie ik toch 98% van de tijd dat projecten GitHub gebruiken; misschien 1% gebruikt forgejo/codeberg en 1% iets anders.

[Kees]

Ooit was sourceforge the place to be voor OS projecten (en daarvoor Freshmeat) en het is nu inderdaad Github. Maar het kan zich dus verplaatsen.

Overigens zitten een aantal projecten nog wel op Gitlab (Gnome, om er maar een te noemen)

[bartvb]

Ik kwam recent deze tegen:

https://onedev.io/

Tot nu toe ben ik erg onder de indruk. Open Source, simpel zelf te hosten, beperkte system resources nodig, ingebouwde issue tracker, ingebouwde CI/CD, goede integratie met k8s, actieve ontwikkeling.

[Scriptkid]

Azure Dev ops

[GertMenkel]

Gitlab werkt goed. Wordt veel professioneel gebruikt en ook vaak zelf gehost door open source projecten als KDE en Gnome. Bitbucket neemt qua populariteit af maar is prima te gebruiken. Codeberg en dergelijke worden ook steeds populairder.

Github is echt niet speciaal meer. Dat waren ze tien of vijftien jaar geleden misschien, maar pipelines en discussies heeft de rest al jaren.

De bekendheid helpt, maar weinig mensen browse github om te kijken wat er vandaag voor interessants te zien is. Als mensen op fora en websites naar gitlab of Codeberg zouden linken, zouden veel mensen weinig om het verschil geven.

[supersnathan94]

Gitlab

[angerfist-yentl]

Sorry maar uhm gaat dit niet gewoon wederom een flop worden? Dat microsoft er na een poosje de stekker uit trekt en een 3e party er mee vandoor gaat. (Whatsapp ipv MSN als voorbeeld) want ik kan mij nog herinneren dat ik MSN op dezelfde manier gebruikte als ik nu whatsapp gebruik op mijn HTC Diamond Touch. maar nee het moest Skype worden want die hadden ze duur overgenomen toen.

Ik ken Github en vaak dingen weggehaald maar gebruik nooit Azure (met genoeg redenen want microsoft) en nu hebben ze Github gekocht en dwingen ze het mensen op zal mij niks verbazen als het net zoals MSN overgenomen gaat worden door een 3e partij in de toekomst, Ik kende MSN en ik gebruikte Skype nooit want het was nog geen 90% van wat MSN was. Ben erg benieuwd wat microsoft dit keer weer bedenkt wat niet aan zal slaan met de Azure alternatief. (lees begrijpen waarom iets aanslaat en succesvol is) iets overnemen en dan 90% veranderen helpt daarbij niks.