Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Microservices as a Service-Oriented Delivery Model

Microservices as a Service-Oriented Delivery Model

This item in japanese


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


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.

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

Community comments

  • Life is a Broccoli

    by Martien van Steenbergen,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    The presentation is now available at:

  • Re: Life is a Broccoli

    by Erik Gollot,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Very very bad for performance. ..

  • locality and sequentiality

    by Jeff Hain,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    "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

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