Microservices: Usage Is More Important than Size

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.