Monolith to Microservice Without Downtime — A Production Story
I am cross-posting for an article that I published on SalesLoft’s Medium blog.
Rather than copying the content over to this blog, I’m going to point you at the above Medium post. However, here are the lessons learned from the process:
- Migrating from monolith to microservice is not easy. In fact, it involved a lot of nuance in the coding and planning that had to be a forethought and not an afterthought.
- Stability for customers is the most important part of a refactor like this; our product exists to serve our customers and not to be a microservice-powered entity.
- Finding the seam in the monolith is important when it comes to stability. If your new code, which shouldn’t be running until it’s ready, causes old requests to fail…that is a problem.
- The timeline was significantly longer than I anticipated. This is important because we have to prioritize refactoring old code against developing new features and fixing bugs. On the flip side…
- The slower timeline helped us ensure rock solid stability. We had zero stability concern on release day, which turned out to be like any other normal day.