> We installed as much hardware as available power allowed in our existing data centers while accelerating our migration to Azure.

And from the RCA [1]:

> The immediate cause of the failure was network saturation on load balancers in Central US due to a new peak in traffic.

[1]: https://www.githubstatus.com/incidents/zkxwbgr0cnmx

You’re torturing your own logic to make Azure the villain here. And it also sounds like you lack experience with capacity exhaustion. Things fail slowly, then suddenly.

I’m firmly in the camp of “something stinks at GitHub” but

> It is unbelivable that aload of 2.8b commits was totally fine, and a load of 2.9b was a sitewide outage

In my experience, there are hard thresholds that get passed that expose hidden bottlenecks like this. A previous system I worked on we had absolutely loads of headroom by all of our measured metrics, but one day we filled a cache because the value hadn’t been tweaked in recent memory. Plenty of space on disk and in memory, but all of a sudden we went from a very high cache hit rate to a very low cache hit rate, and everything ground to a halt.

This absolutely can happen in large systems. If some part of the system is at capacity, then slightly increasing the load can cause it to fall behind and start accumulating a backlog.

These backlogs can cause clients to make more retries, exacerbating the problem. Potentially further cascading through the system.

I believe their point is that "system is at capacity" is something they ought to start fixing before the capacity is exceeded

Sure. But you might not even be realizing that something is just at the cusp if the load is spiky enough.

The art of large system design is to identify and avoid these kinds of chokepoints. And when something happens, propagate the "backpressure" up the stack to avoid queuing.

AWS got a fair share of similar outages, so the newer SDKs now try to not exacerbate these kinds of issues: https://docs.aws.amazon.com/sdkref/latest/guide/feature-retr...

The original AWS EBS outage is probably the canonical example: https://aws.amazon.com/message/65648/

But then people like OP will claim that the capacity concerns are a lie manufactured to support an unjustified move to Azure.

There's always a cliff, this part is fine. You sometimes know the cliff but often do not.

>"While accelerating our migration to Azure," meaning, they will only solve problems if it helps them also use Azure more.

Look, I hate Microslop as much as anyone but you'd have to purposely misinterpret TFA in order to arrive at this interpretation. C'mon.

Ok, but there's no universe where a major Microsoft-owned property is not being forced to run on Azure. Just like AWS pushing to get off Oracle back in the day. It would be career-destroying to suggest otherwise regardless of technical merit (and tbf, no infrastructure is bulletproof, unless you want to port GitHub to z/OS on mainframe)

LinkedIn gave up after four years of trying: https://www.cnbc.com/amp/2023/12/14/linkedin-shelved-plan-to...

Azure just has very poor performance and reliability characteristics. It’s a particularly bad migration target for a colo-based company that mainly runs on owned hardware (such as GitHub or LinkedIn). Requires much larger architecture changes than (say) a company coming from AWS.

I'm betting on Tangled and Codeberg. Tangled has a better press and in general is a dark horse, Codeberg has the "brand" and some network effects from projects that moved to there. (famously, Zig.) I heard that Sourcehut is having a moment as well, and I love the idea of email-based workflow and not having to have an account to contribute to someone's project hosted there, but I'm not maintaining anything worthwhile paying the $4/mo sub.

What if it was $2?

that is more manageable but c'mon I can't even keep Google One 100GB up on a consistent basis, that's how poor I am. self-hosting would be a far better option because apparently I find enough people to provide free Hetzner VPSes and stuff as long as I can sell this as mutually beneficial.

for context, I would GLADLY move there my Neovim plugin. all it does is brings the current jj message into your editor and lets you integrate it with a status bar (or anything in nvim, really). that would be a decent measure against drive-by slop contributions, and I'd accept contribs over private github mirror from those who I know but can't bother setting up git mail

EDIT: TIL that one can host SourceHut themselves. discoverability may still be a problem (sr.ht just ranks higher in search engines) but 1) fixable with github mirror that points to sourcehut instance as a canonical development platform, 2) it's moderately easy to sync contributions between tangled and sourcehut, so tangled is also an option

EDIT 2: the email part would be PITA, so $4/mo is attractive on that background

Oracle has a free tier that you can self host a git server on, if that's what you're looking for.

I spent a month trying to set this thing up, to no avail

What was the sticking point?

> Github is ripe for disruption and I hope it is disrupted soon.

It's an expensive, low revenue generating site.

There are, and have always been, competitors, including "host it all yourself" solutions, but nothing has really stuck.

How is it "ripe" for disruption?

They had $1b revenue in 2023 and now probably more than $2b in revenue... do you have cost figures showing what their expenses are?

> We have since added more than 3 million CPU cores, 120 petabytes of high-speed storage, and significant network capacity. We installed as much hardware as available power allowed in our existing data centers while accelerating our migration to Azure.

That can't be cheap.

A server box now has around 256 CPU cores. So that's about 12000 servers. If each one is $10k that's $120 million. Not a lot compared to Github's income.

$10,000 is only enough for CPU cost (2x AMD EPYC 9754). The rest of the servers (mainboard, RAM, storage, power supply, network card, rack, cooling, etc.) can easily triple or quadruple the cost.

Yup. Still, it's less than their annual income by several times.

Does that $10k server not need RAM?

If parent commenter is off by an order of magnitude in their costs, their point still stands.

$1.2 billion of costs on revenue of $1-$2b certainly seems like a big concern.

They do not throw away the servers every year..

But at this rate of growth, sounds like they'll need to buy around that amount every year just to keep up with current (not even taking into account future) growth.

Microsoft don't release the costs as you know, but

Compute and Storage for Free Tiers: Hosting code for over 150 million developers and processing over 2 billion GitHub Actions (CI/CD) workflows a month requires astronomical server power and data storage. The "Free" tier is a massive cost sink that Microsoft treats as a loss-leader marketing expense

Let me know when you understand how that's not free.

The Azure horror stories are on this blog post and HN discussion.

https://news.ycombinator.com/item?id=47616242

If you're a big company, you can afford having one engineer spend one or two days per year to maintain your self-hosted GitLab or Forgejo. On top of better reliability than GitHub, you'll get the additional bonus that your source code won't accidentally leak through being in Copilot's training set.

If you're a hobbyist, Codeberg is great, has a nice community and automatically shields you from slop contributions.

Speaking from experience, it cost mW about a week or two per year to maintain GitLab for the startup I worked at.

My personal GitLab on the other hand really does take only a day or two per year.

That said, a week or two per year is just what it costs to maintain any one thing period. I spent about that much time maintaining PCs in the office, or my personal proxmox setup. It's not onerous at all.

GitLab is super bloated and a little sucky to admin, but it's not too bad all things considered. I'm admin in my new job's GitHub org and it sucks a whole lot more to maintain.

The issue with these systems is that they lack Github's sophistication for issue tracking, knowledge transfer, and automation. I think Gitlab is a mature product in its own space and unlikey to change, for instance, at this point.

Codeberg also has the issue of having a political stance which means they will not accept just anyone's use of the platform. That is absolutely their right and I have no issue with it, but it's unattractive to me - as someone who agrees with most of their current politics - because the day they decide they don't like me, I'm screwed.

I never found GitHub's systems for issue tracking to be all that great. Cross-repository issues and development plans are hard to track within a git host. I've always used an external panning and issue tracking tool, mostly Linear, and it works really well. GitLab's Linear integration is excellent, FWIW.

I've actually worked with a couple of companies who do use GitHub for their code, and they all use Linear in addition to GitHub.

I understand the concern you're talking about wrt. Codeberg, but I wouldn't view it as a significantly bigger risk than anything else. Any platform can suddenly decide that your project is against ToS (GitHub will absolutely not accept just anyone's use of their platform either) and Codeberg introducing some rules recently doesn't, in my mind, drastically increase the risk of a dramatic ToS change in the future. But we all have to make our own risk evaluations and I won't judge yours. Luckily, moving between Git hosts isn't that difficult; setting up CI again and losing merge request history does suck but it's not the end of the world, unlike something like, say, losing your AWS/GCP/whatever account.

"sophistication" seems like a strange way to describe GitHub to me - I've found in every individual aspect (code browsing, issue tracking, code review, package management, etc), it's the worst out of all the systems I use regularly... But it's good _enough_ for most people, and it has all those features in one place, which is more convenient than wrangling 10-15 high quality but disconnected systems

Gitlab has the benefit of having very little traffic, both free and paid. Their limits are still way above the current usage so less likely to be an issue

Worth mentioning GitLab's paid enterprise offering are more expensive than GitHub's, on a per-seat basis.

Lots of companies moved because it was cheap, but it's not anymore. Ironic that companies might choose to migrate to them now for stability, rather than price.

GitLab has its own problems. It might be somewhat more available than GitHub lately, but it too is not immune to incidents, particularly involving workflow dispatch and managed runner availability.

Plus the UX isn’t nearly as good. Sometimes it feels downright clunky in comparison.