The buzz around microservices

The term microservices has been humming around in the industry quite a long time now. Several articles and videos have been posted. People have been arguing about whether their services are true microservices or not on twitter and other social media streams. Lately Martin Fowler published an article about microservices which quickly led to discussions, flamewars and a lot of blog posts about this topic. Here is my personal opinion about the microservices architecture style. You have the right to disagree 🙂

The term “Microservice Architecture” has sprung up over the last few years to describe a particular way of designing software applications as suites of independently deployable services. While there is no precise definition of this architectural style, there are certain common characteristics around organization around business capability, automated deployment, intelligence in the endpoints, and decentralized control of languages and data. Martin Fowler

I provided a small reading list at the bottom of this article which might help you get your own opinion. As I see the current hype going on with microservices is that it is just a new word for something which has been around for ages in Service Oriented Architecture. My call is that a microservice is just an Autonomous Component. Let us take a step back and see how a SOA service can be decomposed.

What is a SOA service?

The service is the technical authority for a specific business capability. For example if we talk about a sales service then all data which belongs to the sales business capability remains within the service itself. This holds also true for all business rules attached to this business capability. After we have identified all services in our business domain, nothing is left over in our business domain but clearly identified to which service it belongs. So everything is contained within a service.

Tenets of Service Orientation

A SOA service needs to follow the tenets of Service Oriented Architecture:

There are four tenets describing real service orientation. A service needs to be autonomous meaning that it cannot rely on anything else in order to be operational. It also needs to have explicit boundaries. It must be crystal clear what belongs to it and what doesn’t. It only shares contract and schema but not classes or types between others. Therefore none of its behaviors can be used outside of it but only their effects can be observed. If interaction is necessary between services this has to be controlled by policies.

With the tenets in mind we can begin decompose our business into distinct services. As I see it a SOA service is a conceptual boundary and a decision how the business is organized. The architecture itself represents that in distinct services. People have been struggling with that a lot, especially when a service contains a large-scale business capability. So a service itself can be broken down into Business Components. Business Components are technical elements that implement the capability’s constituent parts. From the service consumer perspective Business Components are not visible (they are hidden in the Service black box). An often quoted example is when you happen to have a “sales” services you might want to treat strategic or VIP customers differently from regular customers. Let’s visualize it:

The divide of the sales services into those two Business Components is fully internal (private to the service). A Business Component can be further broken down into Autonomous Components. In the simplest scenario a business component is itself an Autonomous Component. In more complex scenarios a Business Component can be a composition of multiple ACs. An Autonomous component is responsible for one or more message contracts and therefore composed of one or more message receivers (or handler depending on how you want to call them). An AC is independently deployable and therefore has its own endpoint. Let’s visualize the decomposition:

I didn’t visualize stuff like persistance. Because Autonomous components are part of the same service, they may share the same database schema. But they don’t have to. Because an AC is the smallest deployable part which is completely autonomous inside the same service boundary you can compare it to microservices. It is small, deployable, can be monitored seperately, has its own process, the boundaries are clear, its own schema if desired, can be thrown away and rebuilt any time, can define its seperate SLAs, language and technology agnostic… Does this sound familiar? I even think that microservices is just a buzz word which rephrases the concepts of ACs into something fresh and shiny.

What is your take on that topic?

Note: Martin Fowler has just updated the Microservices article with an insight into the debate whether microservices is just “SOA done right”. It has fair and valid points. Check it out!

Readings

• Microservices by Martin Fowler
• Microservices by Yobriefca.se
• Microservices by Fred George
• Microservices by Chris Ford
• Decomposing services by Bill Poole