3 mistakes we made moving to a microservices architecture

During our move away from a monolithic architecture, we came up with three sources of friction in our microservices migration. We also developed ways to address them

number three painted on concrete
Silvia Frank / Pixel2013 (CC0)

My company, CircleCI, is a big believer in the blameless postmortem—the idea that when you discuss a project and take emotion out of the picture, you create a true learning experience. Following our migration to a microservices architecture, we had a good opportunity to run a blameless postmortem on what we did right and wrong, and what we’d do differently next time. If you’re thinking about starting the journey to microservices, I’d like to share some advice for creating a smoother transition.

Our move away from monolithic architecture took on urgency when we had a 24-hour outage in 2015. We wanted to be cautious: We’d heard a lot of tales of poor decision-making when transitioning full-stop into microservices. On the other hand, incremental changes to architecture weren’t bringing the transformation we needed.

Early wins breaking up our architecture gave us confidence that this was the right direction for our team, and we decided to go all in. Almost immediately, the wheels started coming off the wagon. Engineering productivity ground to a halt. We realized we were throwing people into an unfamiliar environment—like moving from the small-town comfort of the monolith to the unknown microservices big city.

In our post-mortem, we came up with three sources of friction in our microservices migration, and we developed ways to address them.

1. Decision-making

“Analysis paralysis” is being faced with a decision that’s so complex that you spend ages considering all the options without pulling the trigger on anything. The solution is to make hard decisions early on, and then reduce future decision-making to exceptions only—choosing to go in another direction only when that initial decision fails you.

In our case, we said to our engineers, “We’re a Clojure shop. It’s not an option for you to decide what language or stack you’re going to use. We all know Clojure, and it has treated us well.”