Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

An update on GitHub availability

github.blog

Post reply on HN
Print view View original

81–90 of 266 posts

Re: An update on GitHub availability

#81

Post by jansan »

mijoharas wrote: post #2

> we started working on path to multi cloud. Is this microsoft stating that they aren't able to get acceptable reliability from Azure? (I mean, I think a lot of us have heard that, but it's interesting to hear it from microsoft themselves).

The entire concept of multi cloud is amusing if you think what cloud originally was supposed to be. They could call them meta clouds (might infringe trademarks), and with the current growth trajectory of AI generated code eventually multi-meta-clouds, renamed to beyond-clouds, and then multi-beyond-clounds. I see no limits.

Re: An update on GitHub availability

#83

Post by johndough »

georgyo wrote: post #36
maccard wrote: post #13

It's kind of hard to read this with a straight face. The unlabelled graph with big numbers on top, the priorities that don't match with what we're experiencing, and a list of things that they're doing without a real acknowledgement of the _dire_ uptime over the last 12 months....

These are not the worst graphs in the world... Sure the bottom left axis is not labeled, but it still conveys the point correctly. The growth between 2023->2024->2025->2026 is growing quickly. And that in the end/beginning of 2026 they say more growth than the three years before, combined! You don't need to know the bottom left axis number. We do have to assume the graph is linear, and not some kind of negative expon…

> You don't need to know the bottom left axis number.

We very much do. The graph suggests an insane growth in PRs from almost zero to 90M. Now compare this misleading graph with this much clearer one, which shows that the growth over the last three years has been less than 80%: https://github.blog/wp-content/uploads/2025/10/octoverse-202...

Re: An update on GitHub availability

#84

Post by icy »

embedding-shape wrote: post #47
tfrancisl wrote: post #33

Earlier quoted context omitted.

No less than self hosted, imo. If youre on some cloud it doesnt really matter that you pay them absurd amounts of money, you arent sovereign.

So literally a computer at home/in the office, as with anything else you don't really "own" the infrastructure? Or is this just about "cloud"?

Yeah sorry it's marketing BS speak for self-hosted or just infra that you control. It could be a VPS, it could be a Raspberry Pi at home. Your repos live on your servers. (And we support this on Tangled today!)

Re: An update on GitHub availability

#86

Post by embedding-shape »

ArcHound wrote: post #78
embedding-shape wrote: post #44

Earlier quoted context omitted.

There are distributed forges? Yes, git is distributed, but often everything around it isn't. The case parent is trying to make, is that the rest ("federated forges") should also be distributed, not just git.

Ok, gotcha. So there's a demand for the additional features that are not bundled within git to be federated somehow. I'd say we have emails, mailing lists and bug trackers. Or maybe: what is the missing killer feature that needs federation?

> what is the missing killer feature that needs federation?

Issues, pull requests, collaboration/permissions/access, "staring"/"favoriting", etc.

I think ultimately the goal is that people can run their own forges, yet still collaborate on repositories hosted in other forges, leveraging your existing authentication so you no longer need to sign up individually for each forge.

Re: An update on GitHub availability

#87

Post by remus »

steve1977 wrote: post #48

I know that I'm simplifying (probably too much), but it seems like things were fine when GitHub was still a Ruby on Rails monolith and all the rigmarole with microservices etc. only made things worse.

Unless everything else stays the same (underlying traffic etc.) then you can't really compare. Could be that you hit some fundamental scaling limit with the old design and it completely falls over after a certain scale.

Re: An update on GitHub availability

#88

Post by embedding-shape »

icy wrote: post #84
embedding-shape wrote: post #47

Earlier quoted context omitted.

So literally a computer at home/in the office, as with anything else you don't really "own" the infrastructure? Or is this just about "cloud"?

Yeah sorry it's marketing BS speak for self-hosted or just infra that you control. It could be a VPS, it could be a Raspberry Pi at home. Your repos live on your servers. (And we support this on Tangled today!)

> just infra that you control

But a VPS isn't actually infrastructure you control, you essentially have as much control over it as "cloud", so I don't think that'd be counted as "sovereign", would it?

Re: An update on GitHub availability

#89

Post by 2ndorderthought »

himata4113 wrote: post #69

so what they're saying is that Co-Authored-By claude@anthropic.com is overloading their systems? and that azure cannot scale fast enough to handle the load so they're embracing multi-cloud as a company... owned by microsoft? woah. what am I reading.

AI is the new DNS when it comes to service failure.

Re: An update on GitHub availability

#90

Post by ncruces »

OtherShrezzing wrote: post #40
ncruces wrote: post #26

Earlier quoted context omitted.

More numbers: https://x.com/kdaigle/status/2040164759836778878 What's the question here, you don't believe growth is currently exponential, or do you think it shouldn't be hard to scale, when 10x YoY is not enough?

As a business user, our costs have gone up while service has gone down dramatically. Meanwhile our marginal cost to GitHub has hardly changed. Where our costs to them have increased, they mostly charge us per cpu minute, so obviously aren’t making any kind of loss on our account. I’m sure they’re experiencing scaling issues across the platform, but it’s unacceptable for that to have a negative impact on us when we're…

I understand that, and maybe GitHub became a bad deal because of that.

But if anything, their post and your reply are precisely an endorsement of usage based billing.

The bit that's growing 13x YoY (and which they expect will easily blow past that) is unmetered - commits. The bit that is metered (for some, not all folks) - action minutes, grew only 2x YoY.

GitHub was not built to limit the number of commits, checkouts, forks, issues, PRs, etc - nor do we want them to - but that's what's growing ridiculously as people unleash hordes of busy beaver agents on GitHub, because their either free or unlimited.

Where there are limits - or usage based billing - people add guardrails and find optimizations.

Because for all the talk, agents don't bring a 10x value increase; otherwise, they'd justify a 10x cost increase.

Besides, other forges are having issues too. Even running your own. We have Anubis everywhere protecting them for a reason.

Post reply on HN