|
|
|
|
|
by weatherlite
1502 days ago
|
|
Their monolith is millions of lines of code, one of the biggest in the world, so I don't think some 2 year startup writing a blog "how we moved from Ruby to Go" is quite the same as what Shopify will have to do to rewrite their monolith.
Add to that the cost of losing productivity since they have so many Ruby experts.
This will be completely disruptive at a time where Shopify has to grow like crazy and add new features. So I think they know what they're doing. Also I'm somewhat skeptical of all those rewrite success stories, it seems to me like a CTO or principal engineer deciding to make the rewrite will never admit that it was a bad decision since his job depends on it. So of course he will make the case how great and beneficial the rewrite was. I bet there are many stories where the rewrite was detrimental to the business. |
|
Since there's always huge conservatism in relation to rewriting or making in-house frameworks then there's a confirmation bias in these stories: "whew, we dodged a bullet by not even trying thing X".
Yeah, everyone could have said that.
I've attended and participated in at least 7 successful rewrites. You don't hear about them though because people read HN and are like "I am not willing to engage with biased people so let's keep it to ourselves".
That's an aspect of these conversations that a lot of people around here don't account for: the people who get stuff done are quiet. This should be included in analyses but often isn't.
---
...And finally, millions of code in a monolith isn't that scary. Find a part that has minimal dependencies to everything else, rewrite it, put a reverse proxy in front of your service that points a particular endpoint to the new code, test for a bit, done. Rinse and repeat. The process itself is trivial, not especially creative, and mostly just laborious than anything else.