BT

Microservices: Usage Is More Important than Size

by Jan Stenberg on May 08, 2014 |

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.

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

Async, Reactive and Actor are the trending programming models by Faisal Waris

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

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.

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

2 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT