5 ms·
Github used to be built on mysql / redis / ruby on rails / C / shell, running on dedicated hardware. Microsoft left it like that after they acquired the company
by andyjohnson0 29d ago
Github used to be built on mysql / redis / ruby on rails / C / shell, running on dedicated hardware. Microsoft left it like that after they acquired the company.
Eventually, though, they decided to migrate the whole thing to Azure. And they were far enough through that to be basically committed... when AI coding started hitting them with much higher workloads.
I personally think the reliability problems are more to do with the reliability of the Azure migration. But both factors are likely relevant.
- cbeach 29d agoAfter their infamous "Fail Whale" outages, Twitter replaced its Ruby on Rails / MySQL stack with modern (at the time) technologies: Scala (functional language running on the JVM) / Finagle (RPC) / Thrift (framework) / Kafka (message queues) and this made Twitter stable under the load of several hundred million users. Ruby is single-threaded, slow with poor GC and memory leaks. As Twitter's Alex Payne said publicly in 2008: "there shouldn't be doubt in anybody's mind that Ruby itself is slow" and that scaling Rails meant "just throw more instances at it"
- lab14 29d agotell that to Shopify that handles 8.15 million requests per second and processes 5.1 million per minute in sales during Black Friday. You scale your architecture, not your programming language.
- azuanrb 29d agoIt’s 2026 and we’re still benchmarking Ruby using Twitter’s 2008 architecture. It was less about a language choice and more about years of architectural redesign. I thought we were past this by now.
- cbeach 29d agoRuby (language) on Rails (highly opinionated framework) is both a language and an architecture.
- springtimesun 29d agoCurrent Rails and Co are miles away from where they used to be then, but even then my feeling was that maybe it was the skill/culture/dev ops at Twitter that was at least partly responsible for the fail whale. But I don’t have any insight as to what was actually going on inside before and after that transition.
- sosodev 29d agoThey didn't leave the architecture alone, right? They shoved React in and created a weird SSR + React frankenstein that is objectively worse in many ways.
- esperent 28d agoReact apps with SSR is standard these days.
- sosodev 28d agoSSR that is javascript native, sure. This is still Ruby doing the rendering.
- esperent 28d agoWhat's the difference? If it's SSR it's happening on the server, the only benefit of using JS is ergonomics. Ruby is fine otherwise.
- sosodev 28d agoRuby can't render React code. JavaScript can. With GitHub it seems that they sometimes can do SSR for the React bits, but that must mean that they're invoking a JavaScript interpreter within the Ruby process. Which means they have the overhead of two runtimes and the jank that comes with the IPC between the two. It's just pointless hacks on hacks. GitHub didn't need React on the frontend and any potential resource savings of client side rendering were lost when they realized they need to do SSR on that stuff too. I've encountered so much frontend jank as they expanded that portion of the stack whereas it was always excellent when it was just Ruby SSR and minimal JS on the frontend.
- Zanfa 28d agoWish they spent some AI tokens on that abomination to fix at least some of the countless issues it has, because their human engineers definitely won’t.
- 28d ago
- dgellow 29d agoThis is the reason, at least what I know from people who worked there, the azure migration has been very painful as far as I’m aware
- 0-sodium 29d agoyep this was the same with LinkedIn who killed the migration after massive massive costs ~ https://www.theregister.com/on-prem/2023/12/14/microsofts-linkedin-abandons-migration-to-microsoft-azure/1350008 https://www.theregister.com/on-prem/2023/12/14/microsofts-li...
- dgellow 28d agoOh I’m adding that one to my mental list of Microsoft failure