About When Not to Do Microservices

Full original post here

All businesses have to deliver value to customers. But when you are just starting out, you don’t know what will deliver value. Everything you think will deliver value is just an assumption. The answer to “when not to do microservices” lies in knowing which part of the “value delivery” lifecycle of your business are you working on. An analogy describing technology teams as Pioneers, Settlers & Town Planners help us in understanding this.

Pioneers experiment with wild, divergent approaches running many experiments hoping to reduce uncertainty about what may bring value to a company in 3+ yrs. This “pioneering” effort leads to a few options that can be built upon and taken to the next level. The “settlers” end up building these options. They figure out how to scale product engineering and also work on building the ancillary pieces in the organization to make the product successful in delivering differentiated value. Over the years, these once new products will no longer be uniquely differentiated but will still deliver massive value. Town Planners are the people who work on such products.

If you are the Pioneers, sticking with the monolith is almost always the right choice. You have to run a lot of small experiments, build many MVPs and throw many of them away. A monolith is always the faster option in this case. When you are the Settlers, think of using microservices once you have figured out which of the experiments likely to deliver value are actually delivering some value. When you are Town Planners, microservices help you optimize for speed and can be a good option.

If you are thinking about your architecture choices, you must read this post by Christian Posta.

5 mins read