Gero Vermaas 21 Jun, 2010
Share 
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.“]
by Jan Vermeir
Developing software and infrastructure in teams, doing whatever it takes to get stable, safe and efficient systems in production.
> 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
Hi Andrew, it’s always important to consider the limitations of architecture. I think it would be interesting to consider the consequences of MIcro services in terms of deployment complexity, run time costs, message-passing overhead, and what have you against the advantages of creating human-sized units people can understand, faster feedback and enhanced changeability of systems.
I don’t have answers yet, time will tell I guess. I’m currently reading Sam Newman’s book ‘Building Micro services’. I don’t think anyone actually knows what a good Micro service is, but the book gives you some considerations.
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
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.
Hi Tony, I agree that Microservices by itself will not save us from doom. It may turn out to be yet another tragic mistake. Great tools can lead to epic failures when applied in the wrong way (this is true since people started using sharp stones to cut stuff with and I guess it will always be true).
Like you say, in the real world you end up making compromises or decisions that come back to bite you later. Still, I think there’s value in carving up a problem in pieces that can be integrated later. We now have technology that allows us to integrate those smaller pieces into a larger whole. These tools are better than what we had, say 20 years ago, but probably not the final version.
I do see a good match for Microservices and container based infrastructures. That at least gives me some hope we’re onto something. Now we have to find out what are the best design patterns and how to apply them effectively.