Ing. Calogero Bono
GitHub heeft Rubicon beschreven, de nieuwe Git-storagearchitectuur die op GitHub Universe is aangekondigd. Volgens het bedrijf hield die in interne tests 5.000 gelijktijdige agents op één repository staan, met 7.200 pushes per seconde en lezingen met lage latentie. Dat is belangrijk omdat programmeeragents de belasting van repositories veranderen, en wat GitHub vandaag aankan, is over een jaar misschien niet genoeg.
Een paar begrippen, voordat we de feiten induiken. Agent is een AI-programma dat zelfstandig code schrijft en pusht. Reference is de verwijzing naar een commit, zoals een branch. Pack is het bestand dat Git-objecten bundelt. Compare-and-swap is een bewerking die een waarde alleen bijwerkt als niemand die in de tussentijd heeft gewijzigd. Blob Storage is de objectopslagdienst van Azure.
Wat is Rubicon en waarom heeft GitHub het gebouwd?
Rubicon is de naam van het project waarmee GitHub heeft herontworpen hoe het Git-gegevens opslaat en aanbiedt. Volgens het artikel van GitHub is het werk begonnen in mei 2026, direct na de eerste migratie naar Azure.
De reden is de belasting. GitHub meldt dat de drukst bezochte repositories vandaag hooguit tientallen schrijfacties per seconde krijgen, in korte uitbarstingen. Met agents die parallel en continu werken, verwacht het bedrijf dat dit binnen een jaar een constant ritme wordt. Daarom heeft het als doel gesteld minstens twee ordes van grootte meer capaciteit te halen.
Welke schaaleisen heeft GitHub gesteld?
GitHub onderscheidt twee assen. Horizontale schaal gaat over veel repositories, en daarvoor blijven bewezen oplossingen zoals partitionering en routering op basis van belasting gelden. Verticale schaal gaat over één zeer grote, drukke repository, en daar komen bijna alle eisen vandaan.
Voor één repository moet de architectuur duizenden schrijfacties per seconde aankunnen en meerdere schrijfknooppunten ondersteunen. Ze moet ook de commitlatentie verlagen, omdat een agent op elke push wacht voordat hij verdergaat. Elke push veroorzaakt bovendien meer lezingen, van CI, deployments en andere agents, en GitHub spreekt over een sterk versterkend effect.
Als voorbeeld wordt een repository genoemd waarvan het dagelijkse verkeer tussen maart en mei ongeveer vier keer zo groot werd.
Hoe werkt de nieuwe architectuur?
Het uitgangspunt is dat er alleen overeenstemming nodig is over de update van de references. Git-objecten zijn onveranderlijk en worden geïdentificeerd door hun inhoud, dus meerdere schrijvers kunnen ze samen opslaan. Zo schalen opslag, het afhandelen van verzoeken en onderhoud elk onafhankelijk.
Verzoeken komen binnen bij Spokes, dat verder de routering en load balancing verzorgt. Daaronder zit een nieuw dataplane met virtuele replica's en wegwerpbare rekenkracht, waarvan de lokale schijf alleen een herbouwbare cache is. De duurzame staat zit op twee plekken.
- Packs en versnellingsdata in Azure Blob Storage.
- References en de lijst met packs (het manifest) in Ref-CAS, een gerepliceerde logdienst.
Een schrijfactie indexeert het pack, uploadt het naar Blob Storage en voert één transactie uit op Ref-CAS. Een leesactie controleert de versie van de references, downloadt de ontbrekende packs en antwoordt vanuit de cache. Het comprimeren van packs draait op aparte knooppunten, nooit op de replica's zelf.
Verandert er iets voor wie dagelijks met Git werkt?
Volgens GitHub niet. Git blijft Git, met push, fetch en branches op dezelfde manier en met dezelfde beveiligingen. De verandering zit onder de motorkap en wordt doorgevoerd terwijl het platform blijft draaien.
Het onderwerp hangt samen met wat er gebeurt in Git-tools voor agents, zoals bij OpenAI dat Pierre overneemt. Wie de basiscommando's goed kent, zoals Git bisect en blame, hoeft zijn gewoonten niet aan te passen.
Beperkingen om te kennen
De cijfers over 5.000 agents en 7.200 pushes per seconde komen uit interne tests die GitHub zelf heeft opgegeven, zonder externe verificatie. De aangeleverde tekst stopt voordat de details over de twee uitgelichte componenten komen, dus de technische afwegingen zijn niet bekend. Er zijn geen volledige invoeringsdata voor alle repositories.
Wat verandert er voor wie met digitale techniek werkt
Voor een bureau of een klein team verandert op korte termijn vrijwel niets. Het gaat om iets anders. Als je workflows agents gebruiken die veel pushen, bereidt GitHub zich voor om dat stabiel te houden. Het blijft zinvol je eigen pipeline tegen het licht te houden, want elke push veroorzaakt een keten van lezingen, zoals ook blijkt uit de vergelijking tussen GitLab CI/CD en GitHub Actions. Wie platformen bouwt voor veel klanten, kan het principe overnemen om rekenkracht en data te scheiden, een onderwerp dat dicht bij multi-tenant ligt.
Ons oordeel
Rubicon is een serieus technisch project, en het idee om alleen de references te coördineren is elegant. Maar de naam zegt ook iets anders. GitHub beschouwt de belasting door agents als een punt zonder terugkeer, en gaat ervan uit dat die zeker komt. Het is nog de vraag of de groei echt zo verloopt als voorspeld, of dat synthetische tests het werkelijke gebruik overschatten. Er zijn onafhankelijke gegevens nodig, niet alleen die van de leverancier.
Veelgestelde vragen
Wat is Project Rubicon van GitHub?
Het is de nieuwe Git-storagearchitectuur van GitHub, aangekondigd op GitHub Universe. Ze scheidt opslag en rekenkracht en coördineert alleen de updates van de references.
Hoeveel pushes per seconde kan het aan?
In interne tests meldt GitHub 7.200 pushes per seconde op één repository, met 5.000 gelijktijdige agents. Dat zijn gegevens van het bedrijf zelf, niet door derden gecontroleerd.
Moet ik mijn manier van werken met Git veranderen?
Nee. Volgens GitHub werken push, fetch en branches net als voorheen, met dezelfde beveiligingen.
Waar worden de gegevens opgeslagen?
De packs staan in Azure Blob Storage. De references en de lijst met packs staan in Ref-CAS, een gerepliceerde logdienst.
Waarom zijn er meerdere replica's per repository nodig?
Omdat het indexeren van packs en het controleren van de bereikbaarheid van objecten veel CPU kost. Meer knooppunten verdelen het werk en verbeteren de fouttolerantie.
Waar je op moet letten zodra Rubicon de repositories van iedereen bereikt
De echte test wordt de overstap van interne cijfers naar echte repositories. Dit zijn de punten om in de gaten te houden.
- Volg de volgende artikelen in de reeks van GitHub over de twee uitgelichte componenten, om de afwegingen te begrijpen.
- Controleer of de push- en fetchtijden van je repositories in de komende maanden veranderen.
- Kijk of GitHub limieten of gebruiksregels publiceert voor agents die veel parallelle pushes doen.
