Microservices as a Service-Oriented Delivery Model

| by Jan Stenberg Follow 38 Followers on Nov 30, 2014. Estimated reading time: 3 minutes |

Microservices are valuable, but to break things up properly creating the right boundaries we need to understand our business and its processes Jeppe Cramon stated in a presentation at the Microservices Conference in London.

Jeppe, working with large scale system integration at Tigerteam, is sure there is a lot of value in componentizing and believes Microservices is a good opportunity to evaluate what was good with SOA, what we misunderstood and what can we learn and improve. But he also believes we need some guidelines to help us build better software.

Microservices should be valuable, meaning that the value must exceed the cost of building and operate it. If we follow the principle that everything runs in its own process we have to pay the penalty of serialization, communication, monitoring, etc. which adds a significant amount to the cost of building the service. Jeppe believes that if we build too small services there is a big risk that things that belong together, and should be kept together, are separated and what's left of coherence disappears. We also get both communication and layered related coupling together with temporal and behavioural coupling. If we go down this path of building small services we are just building a distributed monolith.

To break things up, we want things to be a bit smaller and easier to comprehend, but we also need cohesion and loose coupling, so we need to understand the business as a process and how data is flowing, thus enabling us to build the right system and finding the right boundaries. Many of us have been trained in thinking in entities and structure models and this is where we get into problems. We start small but as we add things suddenly the model have grown to the size where we can't see the responsibilities or the boundaries. The mental capacity required to understand a large model is very high, and in Jeppe's experience this is where monolithic systems typically get into problems.

Looking at an online retail system as an example we find different areas, e.g. purchasing, sales, inventory, shipping, each with specific and unique needs and that typically don't overlap much. This allows us to split the domain into a macro architecture, the reason being to depict the stable parts of the architecture and use it to align business capabilities, or bounded contexts, with services. Domain-Driven Design (DDD) doesn't enforce problem and solution domain alignment for bounded contexts but one reason for aligning services with business capabilities is that business capabilities are remarkably stable, if we get them right chances are they will not change. What's inside can change a lot, but at a logical level it’s stable. Jeppe emphasizes though that we must beware of separating into services too quickly; cross-boundary refactoring can be expensive.

In Jeppe's opinion a service is the technical authority for a business capability, which means it's the owner of all data and business logic that support this capability everywhere it's needed. Looking at the deployment model a service must then be deployed in every system where the service' data is required. This gives us a single source of truth for that capability, and alignment between business and IT, ensuring we can have autonomy which removes any need to call other services.

With a service being the technical authority for a specific business capability it can get quite large so we need something smaller and Jeppe states that a service is implemented by microservices, defining microservices as being a division of a service along transactional boundaries. While services are logical deployable units it doesn't mean they have to be deployed individually. We should design for distribution but take advantage of locality. With a system made up of multiple microservices there is often no reason for them to be in individual processes.

Services are for Jeppe the cornerstones when we talk about business capabilities, with Microservices an implementation detail, an advantage since they are less stable. Being small with a single purpose, they have the benefits of being easy to write, test and replace.

In conclusion Jeppe defines Microservices as a Service-Oriented Delivery Model, focusing on service alignment with business capabilities making them as small as possible, but also as big as necessary. Services are implemented as a set of Microservices that are logically deployable. Doing this Jeppe believes Microservices will help us achieve some of the things SOA has promised us.

The Microservices Conference is the first on the subject arranged by Skills Matter, in London. Next year’s conference is open for registration.

Rate this Article

Adoption Stage

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Life is a Broccoli by Martien van Steenbergen

IMO, microservices should be structured like a broccoli—every part of a broccoli is itself a broccoli. A broccoli is always whole, securing coherence. A broccoli is layered, supporting different abstractions and layers of granularity. In short, microservices should be a holarchy. The question becomes, a microservice of this size, at which abstraction layer does it best fit. Or turn it around, at this abstraction layer, microservices best fit if they have approximately this size.

Presentation is available by Jan Stenberg

The presentation is now available at:

Re: Life is a Broccoli by Erik Gollot

As always with such discussion, one or more concret samples would be better.
I had a old experience with "all is a corba service"...and it has been a nightmare and also very very for performance.
So what's new here ? How do you define the "right" size of your "microservice" ?

Re: Life is a Broccoli by Erik Gollot

Very very bad for performance. ..

locality and sequentiality by Jeff Hain

"there is often no reason for them to be in individual processes."

There are also often consistency reasons for them to read-compute-write
non-concurrently with each other, and these reasons are often hard to figure out
(and very hard for most people), so locality with sequentiality should be the default,
and asynchronism, and then distribution (hopefully asynchronously!) should be carefully designed.

On the other hand, having services ran sequentially (by default) should not be an excuse to avoid good design practices that would make it easier to run them concurrently if ever needed.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

5 Discuss