I recently presented an event about refactoring to a microservices architecture, and part of my preparation is research that led me to thinking about when to use this architecture and when not to. In the process, I came across this rather quaint blog post by Ozan Onay, where he wrote about software engineers going crazy using complex technological solutions to solve the simplest problems at work.
[When] we have to choose a technology, we end up in a kind of frenzy — bouncing from one person’s Hacker News comment to another’s blog post until, in a stupor, we float helplessly toward the brightest light and lay prone in front of it
He specifically pointed out how Stack Overflow remained successful and performant despite being an on-premise application using a traditional technology stack:
As of 2016, Stack Exchange served 200 million requests per day, backed by just four SQL servers: a primary for Stack Overflow, a primary for everything else, and two replicas.
Stack Overflow, if only to underscore the irony, isn't only a massive web app using "uncool" technology despite being the go-to place of all the same developers above. It's also co-founded by Jeff Atwood, who attested his disdain for so-called "magpie developers". He compared developers to the species of bird that lines its nest with unnecessary embellishments, and attributes the behavior to a feeling of inadequacy when a system is using "old technology":
[Magpie developers] feel inadequate if [they] aren't lining [their] nest with the shiniest, newest things possible. Who cares what technology you use, as long as it works, and both you and your users are happy with it?
But while both Jeff and Ozan warns of the perils of using something new and shiny as an example of why not to use a microservices architecture, during my Microservices talk relevant questions came up.
The first one was "When is the best time to adopt a microservices architecture?"
This was a rather interesting question because microservices is one of those things that presents a paradox. If it is adopted too early, it introduces unnecessary complexity and burden in building a system that might do well as a monolith. However, if done too late, there will be technical and design decisions that might make it very difficult if not impossible to migrate to the new architecture.
So timing is not really the answer. On the contrary, I ended up giving the answer that "the best time is when the business needs it." When customers demand for a public API to use for their own applications, or the team requires a major redesign of the app's UI, then it's imperative to probably move to a microservices architecture.
The second question is along the lines of "when is an application or organization big enough to consider using microservices?"
I initially wanted to rehash my first question, but realized that size is indicative of a large application size. Not only do people succumb to Conway's law, wherein the design of a system reflects the communication structure of the systems, but I was also reminded of a Joel Spolsky anecdote about the Windows Shutdown Team where it was said that there were 24 people involved in that one feature alone (for Windows Vista).
While that was ideal, my real answer was that "if it is a separate business capability, it could be a separate microservice". While this takes its roots from parts of my presentation (which in turn borrows heavily from Martin Fowler's excellent article on microservices), it correlates the number of people involved in an application as indicative of its complexity and size, and a sign that it might be chopped up to fulfill the "micro" in "microservices".
Both answers however lead to a common denominator: the move towards microservices is dictated by needs. Business needs in the earlier case, organizational in the latter. Simply wanting to do something cool and hence splitting up an application to microservices will introduce unnecessary complexity -- complexity that you certainly don't need.
UPDATE: I amended the link that says that the microservices article is by Robert Martin. It is, in fact, by Martin Fowler.