How Airbnb Scaled by Moving Away from a Rails Monolith | Hacker News Reader

How Airbnb Scaled by Moving Away from a Rails Monolith

engineercodex.substack.com

25 pointsthunderbong20 comments

I recently saw a talk from lead engineer at Intercom who talked about how they're moving away from micro services and porting them over into their rails monolith. Their reasoning was that that managing all these services creates a huge amount of operational overhead and siloing of knowledge while providing no actual benefit when it came to scalability.

Is there a recording? Would love to watch.

They've just posted the recording

https://www.youtube.com/watch?v=wV1Yva-Dp4Y

I’ve got a special place in my heart for Ruby and rails and the scaling argument always kills me. If you’re a small app, why solve a problem you don’t have? It’s not cool to write Ruby apps anymore, that’s why. Most problems people face are architectural problems, not language problems, and even if you do hit them, it’s probably a pretty damn small slice of your app you have to optimize.

Yeah... "you are not Google". Web apps that need huge perf are almost an anomaly in the web dev industry.

> In 2018, Airbnb began its migration to a service-oriented architecture, as the Ruby on Rails “monorail” started becoming hard to maintain and was a single point of failure.

A monolithic codebase doesn't have to be deployed as a single artifact to be a single point of failure.

There's nothing stopping you from deploying a monolith application across a distributed number of machines in a highly available manner, including making machines favour some types of work (e.g. web workers and background job workers). Nor is there anything stopping you from performing blue-green deployments or A/B testing if you want to interpret single point of failure as a bug is deployed to all machines simultaneously and affects your entire application.

Twitter also had to move away from Ruby into a service-oriented architecture back in the late 00s. It's not a very scalable language, even when you hire people who work on the compiler.

It seems that the Ruby on Rails monolith lasted through 10 years of explosive growth at airbnb. Thats a pretty scalable to me.

FTA it sounds that it wasnt he language of framework that was an issue, but rather the monolith model.

Well, you have to put the human cost investment into the picture. When the cost to develop/maintain becomes significantly high, it’s a natural choice to deprecate it and move on to something faster.

Twitter had to move away from Rails because their high-volume read/write pattern of unrelated data doesn't scale on rdbms and that made ActiveRecord a poor fit for tweets.

They famously and stupidly blamed Ruby and everyone ate their blogpost up because this industry is full of cargo cult behavior patterns. Everyone acts like lemmings and just assumes BigCo knows better than they do.

It scaled for a long time for Twitter. With few exceptions, we're not going to work at anything close to the scale of Twitter at the time, so that's plenty scalable for most use cases. Now, if you want to be more compute-efficient that's a different question...

DDH made a funny comment about this in his keynote for the Rails World conference that just happened:

"Twitter moved off rails and I was always really curious about that story. Here's a testimony from someone who actually worked at Twitter when they moved off. Yeah they moved off because they had a badly designed Rails app, that happens. Okay and then they moved into what they thought was better a constellation of java microservices and then nothing fucking happened for 10 years. They poured concrete over the application and hired thousands of people to make no progress at all."

You can watch the whole talk here, the quote starts around the 15 min mark:

https://www.youtube.com/watch?v=iqXjGiQ_D-A

Does anyone have any good counterpoint articles/references that describe how a company has been able to scale while keeping the rails monolith backend?

Shopify is probably the most obvious example.

Well, yeah, but "adopt and become the main driving force in both the language and the framework development" is -- while sometimes the least cost way of achieving your goal, especially compared to tossing and rebuilding a complex stack you've built on top of the language and framework -- hardly an endorsement of the inherent suitability of the platform for your use case.

Intercom gave a talk at the recent Rails world conference about how they moved to a micro service based architecture, but all it ended up doing was increase operational complexity. They're now in the process of porting their microservices into their monolith.

All the talks are being released in the next week or so, you should take a look when it's out, it was very interesting.

There's ZenDesk. Here's a comment from last year: https://news.ycombinator.com/item?id=32178105

It references a RailsConf 2022 talk where they chatted about handling a billion requests a day with mostly a Rails monolith. The author of the talk ended up commenting in that thread mentioning it's closer to 2 billion, all of which hit the application (these aren't CDN cache hits).

Shopify is massive. It has grown to a small collection of specialized services but the monolith is still the main backend and the traffic is database heavy and transactional, it’s not just dumb cache reads.

Tens of millions RPMs is the baseline and there’s massive, massive spikes for Black Friday or high profile events

It’s not Facebook/Google/Netflix traffic but it’s up there. Language is very rarely the bottleneck that people think it is

Why did you change the title to include "Rails"?

Isn’t Rails relevant in this case?

Reply on news.ycombinator.com