Blog

Microservices architecture principle #1: Each Microservice delivers a single complete business capability

23 May, 2015

This post is the first in a six-part series on Microservices Principles. Other parts are: Autonomy, Small bounded context, Asynchronous Communication, Best Technology and One Team.
 
Microservices are a hot topic. Because of that a lot of people are saying a lot of things. To help organizations make the best of this new architectural style Xebia has defined a set of principles that we feel should be applied when implementing a Microservice Architecture.
This blog explains why a Microservice should deliver a complete business capability.

A complete business capability is a process that can be finished consecutively without interruptions or excursions to other services. This means that a business capability should not depend on other services to complete its work.
If a process in a microservice depends on other microservices we would end up in the dependency hell ESBs introduced: in order to service a customer request we need many other services and therefore if one of them fails everything stops. A more robust solution would be to define a service that handles a process that makes sense to a user. Examples include ordering a book in a web shop. This process would start with the selection of a book and end with creating an order. Actually fulfilling the order is a different process that lives in its own service. The fulfillment process might run right after the order process but it doesn’t have to. If the customer orders a PDF version of a book order fulfillment may be completed right away. If the order was for the print version, all the order service can promise is to ask shipping to send the book. Separating these two processes in different services allows us to make choices about the way the process is completed, making sure that a problem or delay in one service has no impact on other services.
So, building a microservice such that it does a single thing well without interruptions or waiting time is at the foundation of a robust architecture.
 
[edited: 3 aug 2015 – added preamble and removed line “Over the next couple of days we will cover each of these principles in more detail in a series of blog posts.“]

Developing software and infrastructure in teams, doing whatever it takes to get stable, safe and efficient systems in production.
guest
5 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
Andrew Phillips
Andrew Phillips
7 years ago

> that we feel should be applied when implementing a Micro service Architecture
Could you also comment on when you feel it makes sense to go for an MSA in the first place? Especially in the light of Martin Fowler’s recent advice to “[not] even consider microservices unless you have a system that’s too complex to manage as a monolith”?
http://martinfowler.com/bliki/MicroservicePremium.html

Dani Almog
Dani Almog
7 years ago

I am teaching Service orientation design patterns (graduate degree program) ‘ and I feel this approach does not get the right attention. by addressing Micro services we will be able to expend SOA into more sophisticated architecture (such as operating systems and device controllers). I do wish to here and share more on that subject.
The challenge here in my eyes is to be able to manufacture a Micro service that will be able to override our device dependability (pre dedicated API).
Dani

Tony
Tony
6 years ago

In the real world, it is tough to design and develop application that does not have loads of integration with other application. The concept of micro-service could end up being a huge system that might end up being difficult to manage as well.

Explore related posts