When to use microservices?

This is a follow up to an earlier article on microservice architecture implementation principles. It was promised back then to get back to the question of “when to use microservices”.

A bit of history

The overall architecture pattern of microservices was successfully implemented in 2010-ish. That was an endeavor on the part of a few big & successful companies, namely Amazon, Netflix, Twitter. What followed that I would call nothing but a hype.

The reasoning of the followers from the startup space may seem pretty logical:

• If “big guys” adapt microservices AND I want to be like “big guys” THEN I should use microservices too.
• Microservices is the next “big thing”, so I should jump on the bandwagon ASAP.
• If we won’t use microservices right from the start we’ll end with a painful & costly rewrites down the line.

However, this reasoning overlooks some of basic objections:

• There is a ladder of growth steps between a “big guy” and a fresh startup. It’s just too different context to assume such simplistic reasoning may actually work.
• Rarely any new tech piece renders previously well-established items obsolete overnight. In most of the cases a new item gets it’s share of the space and becomes an option to consider.
• Development costs of early distributing the system can be prohibitive for a company struggling to survive. Most of startups are in such a situation, so realization of that cost comes too late.

Business / organization first

From my experience there’s only one definitive criterion in regards to “when to use microservices”. That criterion is business / organization context. All early successful adopters of microservices were massive organizations. 20 years in business but less than 100 people on board and Basecamp is totally happy with what its CTO David Heinemeier Hansson coined as “Majestic Monolith” architecture approach.

Is that a coincidence? I doubt so. There are inherent technical properties of microservices architecture approach which makes it a natural choice for an organization to adhere to it if the business context is right:

• Independent teams behind each microservice. Even if it’s just one man. At the same time one man team is obviously an anti-pattern due to the intolerable bus factor value. Anyways headcount is the primary driver of standing costs for a typical software product company. You have to get to the point of affording enough people business-wise.
• Massive scale & heterogenous nature of workloads. Shaping up compute resources consumption on individual microservice basis per workload needs is the sweet payoff of the architecture approach which isn’t available in monolithic approaches by design. You still have to get to that point business-wise first.
• Portfolio/platform offering. Reusing existing microservices as building blocks of new portfolio/platform pieces is a natural choice. For a new piece it lowers time to market and total cost of ownership. It makes the portfolio/platform strategy of the organization much more flexible. And you still have to get to that point business-wise.

Everything is a tradeoff

I can’t overstate the importance of that statement in CS / IT. There’s no silver bullet and anyone saying the opposite unlikely to really understand what they are talking about.