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

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.“]