Editorial note: I originally wrote this post for the TechTown blog. You can check out the original here, at their site. While you’re there, have a look at the tech courses they offer.
Do you find that certain industry buzzwords set your teeth on edge? If so, I assure you that you have company. Buzzwords permeate every professional space, but it seems that tech really knows how to attract them. Internet of things. The cloud. Big data. DevOps. Agile and lean. And yes, microservices.
Because of our industry’s propensity for buzzwords, Gartner created something it calls the hype cycle. It helps their readers and clients evaluate how much attention to pay to emergent ideas. They can then separate vague fluff from ideas that have arrived to stay. And let’s be honest — it’s also a funny, cathartic concept.
If you’ve tired of hearing the term microservices, I can understand that. As of 2016, Gartner put it at the peak of inflated expectations. This means that the term had achieved maximum saturation a year ago, and our collective fatigue will drive it into the trough of disillusionment.
And yet the concept retains value. Once the hype fades and it makes its way toward the plateau of productivity, you’ll want to understand when, how, and why to use it. So in a nod toward pragmatism, I’m going to talk about microservices in terms of the problems that they solve.
First, What Are Microservices?
Before going any further, let me offer a specific definition. After all, relying on vague, hand-waving definitions is the main culprit in buzzword fatigue. I certainly don’t want to contribute to that.
Industry thought leader Martin Fowler offers a detailed treatment of the subject.
In short, the microservice architectural style  is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery.
Now, understand something. The architectural trade-off here is nothing new. In essence, it describes centralizing intelligence versus distributing it. With a so-called monolith, clients have it easy. They call the monolith, which handles all details internally. When you distribute intelligence, on the other hand, clients have more burden to figure out how to compose calls and interactions.
The relative uniqueness of the microservices movement comes from taking that tradeoff and layering atop it delivery mechanisms and the concept of atomic business value. Organizations touting valuable microservices architectures tend to offer them up over HTTP and providing functionality that stands neatly alone. (I make the distinction of valuable architectures since I see a lot of shops just call whatever they happen to deliver a microservices architecture.)
For example, a company may offer a customer onboarding microservice. It can stand alone to create new customers. But clients of this service, internal and external, may use it to compose larger, more feature-rich pieces of functionality.
So, having defined the architectural style, let’s talk about the problems it solves.