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:
- Allocating data to services.
- Identifying data.
- 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.
Async, Reactive and Actor are the trending programming models
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
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.