Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

Microservices architecture 101: What the heck is it?

Whether you view microservices architecture as merely a change in emphasis or a change in approach, its principles have the potential to improve systems.

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.

Success must include the processes associated with decision making, development, deployment and the full lifecycle of the service.

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.

Follow us on Twitter @SearchSOA and like us on Facebook.

Next Steps

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

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

Have you used microservices architecture to improve your system?
No, but we've been looking into it. My company is what I like to call a 'middle adopter', and we tend to wait a few years after the development of a new service to give it time to mature into a better form. However, I think we'll be making use of microservices architecture in the future - I like on the idea of scaling just the individual parts we need more of, not the full system.
Microservices is very similar to SOA, so it will possibly be an easy transition for your company, James. 
We have slowly started moving down this path as we work on different pieces of our existing systems. It has been nearly two years, now.

It is definitely true that there are more moving parts. It can make the system seem more complex and less intuitive. It can make it a little more difficult to get accurate information to an end user. For instance, instead of immediately telling a user that their action has completed, all that the application can tell them is that their request has been submitted. It's possible that their request will fail in some service down the line, and this will not be visible to them.
In my mind, the real challenge is whether or not multiple services and managing them will prove more appealing to users as compared to having heavy feature laden products. My own experience has been that micro-services are great for mobile devices and lightweight apps where a workflow is captured and readily repeatable. Micro-services falls part in spaces where the need for greater flexibility is needed (not to say that can't be overcome, but it will likely take some time to make happen).
I'm surprised that you feel that microservices fall down in areas where greater flexibility is needed. Normally, the bigger and bulkier things are, the more inflexible they are. In my experience, areas where high flexibility is needed are exactly the places where microservices work better.

I do believe, however, that it does begin with API design, and if you haven't thought about flexibility needs at design time, it doesn't matter whether you have macro or micro services.