Microservices, as a term, gained prominence thanks to this article by Martin Fowler in March 2014. In it, he s...
"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."
At first glance, this may not sound any different than what SOA pundits promoted years ago. There's certainly some truth to that statement, but there's also truth in that many SOA efforts of the mid-2000s failed to follow Thomas Erl's principles of service orientation, or the principles espoused in microservices architecture. These past efforts frequently became more about the technology (e.g., implementing SOAP interfaces for integration or an enterprise service bus) than about the services. What Fowler has done with his definition is try to capture the best attributes of successful SOA efforts, such as Amazon Web Services and Netflix. So let's break it down.
First, let's talk about the microservice itself. It runs in "its own process" and communicates via "lightweight mechanisms, often an HTTP resource API." The key here is that the service is running in its own process. This differentiates between service exposure (layering an API in front of an existing system) and a microservice architecture. In service exposure, many services may be hosted within that single process. If any one of those services needs additional capacity, the entire process must be scaled. In a microservice architecture, you can add capacity for only the service that needs it.
A microservice doesn't have to be a single function, or a single resource, even though it frequently might be. The definition states that a microservice is aligned with a business capability, which is correct. Unfortunately, it still means that if the granularity of the capability model is wrong, you may still struggle. If you read Fowler's entire article, you'll find that the guidance is very pragmatic: When deciding to bundle components together, developers need to be very confident those things will change and scale as a whole. The more coarse-grained services are, the harder it will be to follow that principle. The more fine-grained services are, the more flexibility will be needed to minimize the impact of change and load. The tradeoff, however, comes in complexity and, potentially, in infrastructure costs, depending on allocation and funding models.
In many organizations, the unit of cost is still based on CPU core, with the minimum being two or three in high-availability scenarios. A service that gets 100 requests a day may have the same amount of infrastructure allocated to it as a service that gets 100,000 requests a day. On the complexity side of things, a more fine-grained service does mean more moving parts. That's a big reason why the definition includes "fully automated deployment." Without automation, the increased number of moving parts will cripple manual processes.
The last point I want to make about the definition is that it uses the phrase "approach to developing." This isn't solely about creating Visio diagrams with boxes that have "service" in the name. Success must include the processes associated with decision making, development, deployment and the full lifecycle of the service. You must think of them as products, not projects. Many, if not most, IT departments are just large project-execution engines, with no real notion of "products" with a lifecycle.
With product-based thinking, you can establish that longer-term view. This can include an evolutionary approach to the service's design, combined with use of the tolerant reader approach to avoid affecting existing consumers. Additionally, product-based thinking means changes in ownership. Fowler points out that past approaches aligned ownership with technologies or traditional layers (e.g., UI team, service team, data team). Product-based thinking aligned with business capabilities emphasizes top-to-bottom ownership, which means that where it makes sense, you can use different technologies based on the circumstances.
As Fowler calls out near the end of his article, only time will tell whether the term microservices will stick. But in the spirit of evolutionary design, microservices is part of SOA's evolution. Whether you view microservices as merely a change in emphasis or a change in approach, the principles embodied in it have the potential to improve systems.
About the author:
Todd Biske is an enterprise architect with a Fortune 50 company in the St. Louis metro area. He has had architecture experience in many different verticals, including healthcare, financial services, publishing and manufacturing, over the course of his 20-year career.
Lightweight architectures featuring more productivity tools
Weighing the pros and cons of bus technologies
Using Docker containers to develop a serverless architecture
Dig Deeper on Distributed application architecture
Related Q&A from Todd Biske
The emergence of the stack brings up an important question: Are app servers dead? Contributor Todd Biske examines the future of the app server in a ... Continue Reading
Everyone has a different viewpoint on SOA, but three key differences between SOA and microservices architectures can help you determine which is best... Continue Reading
Why do we need mircoservices architecture? How can we benefit from it? Continue Reading