Intercom decided to bet on “legacy” and re-implemented perfectly functional micro-services in a monolithic Ruby on Rails application, with good outcomes.
Success stories of embracing “legacy” are rare compared to
More like this
stories of migrating to fancy new frameworks, languages and complicated distributed systems. Intercom mostly runs on a majestic Rails monolith running on basic Cloud-based building blocks, however also had a bunch of standalone services implemented in Golang, Java and Ruby on Rails that serve important customer facing functionality. Over the last few years we have replaced most of these services by bringing them back into the Ruby on Rails monolith. This talk will cover the reasons why these services existed in the first place (spoilers: worrying about the scalability of Ruby on Rails, as well as people doing what worked well elsewhere), why we felt the need to move them into our monolith, whether the moves back into the monolith were successful (more spoilers: they were!) and what we learned along the way.
Key takeaways
- Embrace boring technology, and not just for net new functionality.
- Respect what came before. Working systems are the result of a huge amount of undocumented decisions, once-off fixes and Chesterton Fences (and this is fine).
- Long-term thinking leads to outsized results – in the long term.
