Live data from Hacker News

An update on GitHub availability

github.blog

51–60 of 266 posts

Re: An update on GitHub availability

#51
post #12

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

I think this is more tailored towards enterprise clients that lose money when Github is down, that would probably help with retention.

You’d think they could have had the existing GitHub on whatever continue as is (maybe for paying customers) while all the AI new inrush goes to the Azure setup.

Re: An update on GitHub availability

#52
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!).

Love the idea, would replace the LLM generated content ony our site, though. I recently migrated to codeberg because I'm okay with self-hosting big runners, while using codeberg's available runners for smaller cron-based things (they even have lazy runners for this).

It’s… all hand written? We just sound “professional”.

Re: An update on GitHub availability

#54

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.

This sounds more like a belief, based on little more than "correlation is causation", than analysis that controls for macro-trends backed by evidence.

Re: An update on GitHub availability

#55
anyone who's actually worked there, could you explain why they're finding scalability and reliability so hard? naively it seems like 'repo groups', ie clusters of repositories linked by being mutual forks, would be fairly isolated for the whole git storage layer, and everything else feels pretty easily parallelisable (issues, actions, etc, modulo taking locks now and then to submit results or whatever). and given that, surely you can incrementally deploy changes across those many shards to avoid most big outages?

are there big conceptual serialisations that I've missed? is it just not well factored? was the move to Azure just a catastrophically bad idea? some other thing?

Re: An update on GitHub availability

#56
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…

> we're sending them $250/dev/yr for (what is in all honesty) hosting a bunch of static text files.

You know, you can just host your own code forge. Or you can just drop gitolite on a server. Or pull directly from each others' dev machines on a LAN.

GitHub is not git.

Re: An update on GitHub availability

#57
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…

> we're sending them $250/dev/yr for (what is in all honesty) hosting a bunch of static text files.

so start a GitHub competitor which bills $50/dev/yr for solving this easy problem and make a lot of money?

Re: An update on GitHub availability

#59

Earlier quoted context omitted.

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

Prime video uses a non-AWS CDN when I watch football on it here in the UK

The BBC were unable to find a single CDN that could serve the UK during its peak football matches. https://www.bbc.co.uk/webarchive/https%3A%2F%2Fwww.bbc.co.uk...

Re: An update on GitHub availability

#60
post #21
post #15

Earlier quoted context omitted.

What data is that? There's an unlabelled graph and a number at the current peak.

Some previous numbers: https://x.com/kdaigle/status/2040164759836778878

This is the data that should be in the blog post. Thanks for sharing.
Post reply on HN