What actually changed when we moved off our monolith
Meera Iyer
We migrated off a seven-year-old Rails monolith to a service-oriented architecture over about fourteen months, finishing just over two years ago now. I want to give an honest accounting of what actually happened, because most writing about this kind of migration is either triumphant marketing from a company selling infrastructure tooling, or a cautionary "we regret everything" postmortem. The truth for us was more mixed than either extreme.
What genuinely got better: deploy frequency and blast radius. Before the migration, a bad deploy to the monolith could take down every feature in the product simultaneously, and our deploy cadence reflected that fear -- we shipped twice a week, with a full team on standby. Two years post-migration, individual services deploy dozens of times a day, and a bad deploy to the billing service doesn't touch the messaging service at all. That fear-driven deploy cadence is genuinely gone, and it's the single biggest quality-of-life improvement for the engineering org.
What got worse, and this surprised nobody who has done this before but still hit us harder than expected: debugging a request that spans six services is categorically harder than debugging a stack trace in a monolith. We invested heavily in distributed tracing, and it helps, but "heavily instrumented and still harder to debug" is the honest state of things, not "as easy as before."
What I'd do differently: we split services along team boundaries first and data boundaries second, which felt right organizationally at the time but created a genuine problem -- several of our services share what should really be one consistent data model, and now that consistency has to be enforced by discipline and contract testing instead of a database schema. If I were doing this again, I would insist on getting the data boundaries right first, even if it meant a slower, more painful org conversation about which team owns what.
The most honest summary I can give: this was worth doing for us, specifically because our deploy-fear problem was severe enough that fixing it was worth real cost elsewhere. If your monolith isn't causing that specific pain, I would think hard before assuming this migration is worth the debugging tax you will absolutely pay for it.
Meera Iyer
Writer at GreyMatters, sharing insights on technology, career, and innovation.
Comments (4)
Sign in to join the discussion.
What was the actual trigger point that made the monolith untenable, versus just "it felt like time"?
What was the actual trigger point that made the monolith untenable, versus just "it felt like time"?
What was the actual trigger point that made the monolith untenable, versus just "it felt like time"?
What was the actual trigger point that made the monolith untenable, versus just "it felt like time"?