Introduction
Microservices are all the rage these days. You’ve seen so many blog posts, technical articles, even job postings calling for microservices experience. So it must be the new way to architect applications, right?
Well, as with everything else in software architecture, it depends. It depends on the context you are dealing with. It depends whether the benefits of microservices outweigh their drawbacks for your situation.
In this post I’ll describe what microservices are, why they’re so good, and what their drawbacks are. I’ll finish off by giving you some guidelines to help you decide whether microservices are right for your situation.
What Are Microservices?
Microservices are just another architecture style, in the same vein as the Layered architectural style. The microservices and layered styles, along with other architecture styles, have their own pros and cons. Each is applicable in certain situations, and come with their own set of trade-offs
Martin Fowler first coined the term “Microservices” in an article he and James Lewis published in March 2014. Though there is no precise definition of the term, microservices have a number of common characteristics:
They are designed around a bounded context.
“Bounded context” is a term borrowed from Domain-Driven Design. Essentially it means a single workflow within a business domain. A bounded context could be a CartCheckout in an e-commerce domain. Or it could be a CreateClaim within a health insurance domain. If that sounds to you like the Single-responsibility Principle, you’re not wrong. A microservice does one thing and does it well.
What about the granularity of a microservice? That is, how coarse or fine grained should it be? How much or how little should it do? Well, it depends on your specific situation. It’s a judgement call that is difficult to get right at the beginning. As time goes on, if you find your microservices are doing too much coordination (orchestration) between the same set of services in a given workflow, that’s a sign that maybe some of them should be combined. On the other hand, if you often need to test other workflows whenever you make changes to your microservice, that’s a sign it should be split up. Again, all this is a judgement call. As with anything in software architecture, there are no right or wrong answers, just a different set of trade-offs.
Lightweight Communication
Microservices communicate with their clients and collaborators using a lightweight protocol, usually HTTP (over TLS of course). But sometimes they also use messaging to read from or write to a JMS queue or topic, or even a Kafka stream.
Independently deployable
That CartCheckout microservice we talked about earlier is a separate deployment unit. So is that CreateClaim service. Each is a JAR file, or a WebAssembly unto its own. It contains everything it needs to run: its own database, its own utilities, its own copy of framework libraries, etc. Yes, that means there is some duplication with other services. But what this duplication buys you is loose-coupling that lets the services evolve at their own pace without being encumbered by the service that evolves at the slowest pace.
This also means the microservice runs inside of its own JVM. That means going java -jar myservice.jar lights up the service with its own web framework (though a microservice can use JMS to sniff on an MQ broker instead of HTTP to listen to web calls).
Now a microservice does not necessarily mean it is a small service. It may be fine-grained or coarse-grained. It depends on your specific context.
The term “microservice” is a label, not a description.
Martin Fowler
The Good Parts about Microservices
Microservices mean smaller deployment units. They are simpler to change so you can respond faster to changing business needs. If you only need to make a change to the New Claim workflow in that health insurance application, you are only touching the CreateClaim service. Other than a cursory functional test, there is no need to perform a deep regression test suite on the RecordVisit Or SundryItems services, because you didn’t touch them.
The smaller deployment units mean the team can respond faster to changes. Whether it’s a new market opportunity or a change in regulatory compliance, the team can get these changes into production and into the hands of the business users much faster. You get feedback faster, which in turn lets you iterate faster. This helps your organization increase revenue, reduce costs, or avoid regulatory compliance penalties.
You can scale faster with microservices. When some portion of the overall workflow sees a dramatic increase in volume, you simply spool up more instances of the microservices involved. So, for example, if our health insurance organization uses annual policy renewals at the same time of year, they can launch more instances of the PolicyRenewal service. Once the demand dies down, they can shut down those extra instances they spooled up.
The Price You Pay With Microservices
Of course, there is no free lunch here. Coordinating the various services in a workflow is more complex. No longer is it a simple in-process method call to another object. Now you need to figure out whether you are going to make synchronous REST HTTP calls to the collaborating services, or asynchronous JMS calls to publish to a queue or topic. (Hint: begin with synchronous REST HTTP calls, and go asynchronous when you have to. Synchronous is simpler.)
Now you’re making more network calls. Networks have a finite capacity. They do fail from time to time. You need to consider what to do when a service becomes unreachable.
Your test and deployment processes need to be highly automated. If it takes three weeks or more to manually execute a full regression test suite, you sure aren’t going to deploy very often. You’ll end up batching the change requests and release only two or three times a year. That makes it pretty difficult for the business to respond to market opportunities. Instead, you’ll want to automate your tests as much as possible to reduce the testing cost.
Deployment needs to be highly automated too. You want these deployment to be as simple as they can be; automation makes it so. If your organization relies on MS Word documents that you email around for various levels of authorization and approval, you’re moving too slow. Automate. With automation, you can dramatically reduce the possibility of human error.
Wrapping Up
If you need to scale part of your workflow up or down in response to changes in demand, consider the microservices architecture style. If your layered application has grown to the point where changes are taking too long to code, test and implement, consider adopting microservices.
But if your software engineering processes are not highly automated, get them in place first before adopting the microservices style.
Finally, suppose your existing monolithic application sees a relatively flat demand throughout the year. Suppose it is relatively stable in terms of evolutionary changes. Suppose it is fairly simple to change, test and deploy. Then maybe there’s not much to gain when you pay the price of microservices complexity.
As with any new (to you) architecture, examine the benefits and weigh them against the trade-offs. Make an informed decision.