Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Microservices: Usage Is More Important than Size

Microservices: Usage Is More Important than Size

This item in japanese

Lire ce contenu en français


Using only size for defining microservices is a poor measure and useless for determining whether a service has the right responsibilities, Jeppe Cramon states in a series of blog posts clarifying his view on microservices and the coupling problems he finds in synchronous two-way communication.

Jeppe, a Danish contractor and expert on large-scale system integration and SOA, argues that if we combine small microservices with synchronous communication we are actually sent back to the 1990s with Corba, J2EE and distributed objects, only this time with technologies such as HTTP instead of RMI or IIOP. Just because microservices tend to use HTTP, JSON and REST doesn’t make the disadvantages of remote communication, as summarized in the 8 fallacies of distributed computing, disappear.

Creating an alternative to this synchronous communication Jeppe builds on among others Pat Helland and his Life beyond Distributed Transactions: An Apostate’s Opinion where Pat argues against distributed transactions. Jeppe’s solution is three-folded:

  1. Allocating data to services.
  2. Identifying data.
  3. Communication between services.

Jeppe solves his first two points using Domain-Driven Design (DDD) concepts with data collected into entities and aggregates where each aggregate is uniquely identifiable using e.g. a UUID and allocated to one service. These aggregates must be consistent after a transaction, the rule of thumb being: 1 use case = 1 transaction = 1 aggregate.

Communication between services is solved with asynchronous communication, specifically a true one-way communication with the sender transmitting a message using a transport channel, e.g. a message queue. The sender is not waiting for the message to be received; instead the transport channel assumes responsibility for receiving and delivering the messages to the recipient.

Jeppe’s ambition is to continue with a blog post looking at ways to divide services into smaller services and how they can communicate using asynchronous one way communication.

Microservice Architecture has emerged during the last few years as a concept to describe a way of designing software applications as suites of autonomous and independently deployable services that cooperate to fulfill business capabilities. A conference is scheduled for late November in London.

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

  • Async, Reactive and Actor are the trending programming models

    by Faisal Waris,

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

    I would say that pretty soon they will become mainstream.

    Async is hard and you need some kind of a workflow capability in the language to easily manage complex flows.

    Among typed languages F# (partially C#) and Scala have the chops and so should be favored languages going forward.

  • Re: Async, Reactive and Actor are the trending programming models

    by Jean-Jacques Dubray,

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

    I deeply agree with Faisal, we are at a point where we reached a critical mass of APIs/Services. Coordinating these APIs in smarter and smarter scenarios will push us toward this Async/Reactive/Actor model.

    I would add that there is a general trend in the industry to focus on the "minimum", the "small" or even the "micro" (could someone remind me how many lines of code we would need to validate a request again, especially in a stateful scenario?).

    Some people in our industry have built a successful franchise chopping complex problems into what appears to be manageable chunks. Altough it is always preferable to keep things simple, making them "simpler" is generally a good recipe for accruing copious amounts of technical debt. Microservices seem to be yet another of those "simpler", **non viable** approaches our industry loves so much.

  • OK, you are talking about using the brain

    by Rando Facade,

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

    Then how does "microservice" differ from SOA other than another dragon to sell books? After all, nobody said you can only have one (cluster of) server serving all end-points in your SOA; and "micro" implies "extremely small".

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

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