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

111–120 of 266 posts

Re: An update on GitHub availability

#111

Post by benterix »

embedding-shape wrote: post #65
jasoncartwright wrote: post #9

Earlier quoted context omitted.

Seems pretty sensible to not rely on a single provider for their large complex system?

Man, you should have been there 6 months ago when they decided to start tearing down GitHub's own data centers and move everything exclusively to Azure. Seems they themselves realized this after they started moving, but imagine if you could have helped them realize this before they even started :)

> Seems they themselves realized this after they started moving

I guess most people at Github knew exactly it makes no sense but they didn't really have a choice. Maybe some voiced their statement, got "we hear you" in response and were told to proceed anyway.

Re: An update on GitHub availability

#112

Post by johndough »

SkiFire13 wrote: post #102
johndough wrote: post #83

Earlier quoted context omitted.

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

That link shows the number of PRs created to be less than 10M though.

Yes, to be honest, that graph could use some improvements as well. I should probably just link to the blog post with actual numbers: https://github.blog/news-insights/octoverse/octoverse-a-new-...

Re: An update on GitHub availability

#113

Post by steve1977 »

remus wrote: post #87
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.

Oh as said I'm pretty sure things are more complex. It's just funny in a way that all these technologies that are usually being sold as "enablers for scale" don't seem to do their job very well.

Re: An update on GitHub availability

#114

Post by ljm »

icy wrote: post #18

I'm biased (founder of tangled.org), but the future really should be federated forges. Host repositories on sovereign infra with global identity + federated "metadata" (issues, pulls, etc.). Global indices for this should be trivial to spin up so availability is never a concern (we're working towards this!).

I would love if it coding agents didn't default to GitHub for their deep VCS integration.

If I could get the same bells and whistles by wiring up another forge, so long as it offered a decent API and/or sent events over a webhook, I'd have everything self-hosted.

The agents would need to expose an interface on their own end but as long as you implemented it with a plugin, it'd take the dependency of GitHub and you could use MCP or skills for the rest of it.

Re: An update on GitHub availability

#115

Post by embedding-shape »

benterix wrote: post #111
embedding-shape wrote: post #65

Earlier quoted context omitted.

Man, you should have been there 6 months ago when they decided to start tearing down GitHub's own data centers and move everything exclusively to Azure. Seems they themselves realized this after they started moving, but imagine if you could have helped them realize this before they even started :)

> Seems they themselves realized this after they started moving I guess most people at Github knew exactly it makes no sense but they didn't really have a choice. Maybe some voiced their statement, got "we hear you" in response and were told to proceed anyway.

Yeah, I don't know how it went down, but I also know exactly how it went down:

Microsoft Execs: Everyone needs to move to Azure!

GitHub developers: But Azure is not gonna be able to handle our load, we literally have our own data centers!

Microsoft Execs: Sure, but you're Microsoft now, please publish blog post about how in half a year you'll be 100% on Azure.

Few months later...

GitHub Developer: We've tried our best, users are leaving in droves and Azure can't keep up!

Microsoft Execs: Ok fine, you can use something else too, but only if you mainly use Azure and continue publishing blog posts about how great Azure is.

Re: An update on GitHub availability

#116

Post by jameskilton »

Nice, they have availability numbers now on their status page, but they aren't aggregating.

If you multiply all current numbers together (as of Apr 28), you find out that GitHub has a 97.26% uptime.

One ... single ... 9.

They can do better.

Re: An update on GitHub availability

#117

Post by mijoharas »

ksimukka wrote: post #75
mijoharas wrote: post #16

Earlier quoted context omitted.

I mean, amazon (shopping, along with prime video e.t.c.) runs on AWS.

When I was at AWS, retail was not yet running on AWS. Has that changed? Prime video does use some AWS services, but live and on-demand are two entirely different beasts.

Really? I thought retail was. It's been almost a decade since I worked at prime video but I think everything was running on AWS. (Some things didn't use brazil etc, but I think all the servers etc. were on AWS)

Re: An update on GitHub availability

#118

Post by icy »

ljm wrote: post #114
icy wrote: post #18

I'm biased (founder of tangled.org), but the future really should be federated forges. Host repositories on sovereign infra with global identity + federated "metadata" (issues, pulls, etc.). Global indices for this should be trivial to spin up so availability is never a concern (we're working towards this!).

I would love if it coding agents didn't default to GitHub for their deep VCS integration. If I could get the same bells and whistles by wiring up another forge, so long as it offered a decent API and/or sent events over a webhook, I'd have everything self-hosted. The agents would need to expose an interface on their own end but as long as you implemented it with a plugin, it'd take the dependency of GitHub and you co…

The neat thing about Tangled is it's built on an open protocol (https://atproto.com)—this allows us to effectively build an API-free system since all data on Tangled can effectively be ingested via the AT Protocol firehose.

Which is to say, this is perfect for agents given they don't need any bespoke SDK from us: simply write Tangled records for issues, pulls, whatever to your PDS and it'll show up on Tangled. We plan to start working on some exemplar agents first-party that would 1. enhance Tangled itself, 2. showcase cool things you can do with an open data firehose.

Re: An update on GitHub availability

#119

Post by [deleted] »

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

[deleted]

Re: An update on GitHub availability

#120

Post by embedding-shape »

jameskilton wrote: post #116

Nice, they have availability numbers now on their status page, but they aren't aggregating. If you multiply all current numbers together (as of Apr 28), you find out that GitHub has a 97.26% uptime. One ... single ... 9. They can do better.

Kind of unfair though, do the same for any platform with multiple services and you'd probably get > you find out that GitHub has a 97.26% uptime

Calculating that to "Downtime per day" you get ~40 minutes of downtime per day, almost a week per year. Crazy stuff for something essential like this.

Post reply on HN