In the fast-paced world of software development, buzzwords and trends often dominate discussions around application architecture. One term that has garnered significant attention and, at times, confusion is microservice.
While the concept of breaking down applications into smaller components has significant value, as anyone who reads my writings regularly will attest, there is also significant hype around the term microservices itself that leads to misconceptions and oversimplifications.
I think the biggest problem with the microservices hype is that people have been tied up with unhelpful terminology, and the language we all use to describe these concepts involves using incorrect terms. The word “microservice,” in particular, is used to describe anything that’s a non-monolith. I don’t like the word microservice (though I use it in some of my writing because it’s the term people accept nowadays).
When describing the architectural pattern that makes sense for most modern applications, the more correct term is “service architecture,” not “microservice architecture.”
What’s wrong with microservices?
What’s the problem with microservices? The term microservices implies small, and there is nothing in good application architecture that says your services must be small. When people design and build microservice-based applications, they naturally assume the application must be composed of many small components. This causes two problems: First, it discourages some people from using this extremely useful architectural pattern in the first place because they are afraid of the complexity inherent in a large number of tiny, interconnected components (an incorrect but commonly accepted view of microservice architectures). Second, it puts inappropriate pressure on software architects to split their applications into smaller and smaller pieces, even if the pieces shouldn’t be made any smaller.
Some people also conflate the concepts of “microservices” with “serverless.” People who follow me know my views on serverless computing services such as AWS Lambda. There is nothing inherently wrong with using serverless architectures appropriately within an application design. But I have huge issues when people use serverless exclusively. They use it because it’s “the next big thing,” not because it’s solving a particular business problem for them. I hear people doing this all the time. I’ve had people stop and talk to me at trade shows to tell me how proud they are that they built their entire application using nothing but Lambda.
Serverless computation is a good architectural pattern for some types of problems, but it is a bad pattern for many application architecture concepts. It does have its proper place, and in those scenarios can be extremely useful. It’s just not a pattern that should be used exclusively, as many people tend to do.
Why monolith gets a bad rap
And there is also nothing wrong with monoliths. Many fantastic applications are monoliths. Again, the word monolith implies size (big), and that is not at all what the word should imply. After all, a service architecture is nothing more than an application composed of many small monoliths.
To me, the most important driver for application architecture is to use an architectural pattern that is supportable by your organization, and that strengthens the communications patterns already in place there. Nothing is more important for determining overall application architecture than ensuring it fits within the constraints of your organization and business needs.
The key is to make sure the application architecture matches your organizational structure to properly provide an appropriate team ownership model for maintaining the architecture. This needs to be done in such a way that neither the size nor the complexity of the architecture—whether composed of many larger pieces or many smaller pieces—gets in the way of effective construction and operation of the application itself.
In most cases, this would mean using a service-based architecture, with each service owned by a team of 8-10 developers and operations people with a strong ownership mindset. This model is so important that I have created a standard model for describing the process, known in the industry as the STOSA, or Single Team-Oriented Service Architecture model, which is documented in my O’Reilly Media book, Architecting for Scale.
Goldilocks was right
The best advice I can give to move beyond the microservices hype? Don’t build your services too big, or they will be complex and hard to maintain. Don’t build them too small, or the inter-service complexity will be too complex. Pick the right service size that works for your application architecture and development organization. I call this the Goldilocks calculation.
And most importantly, don’t depend on a single, specific architectural pattern because it is “popular.” This includes serverless, microservices, cloud-native, etc. Instead, the best way to move beyond the microservices hype is by choosing the right architecture that matches your application’s needs and, just as importantly, your organization’s needs and abilities.
More from Lee Atchison:
