BT

Martin Fowler on Characteristics of Microservices

| by Jan Stenberg Follow 34 Followers on Nov 06, 2014. Estimated reading time: 1 minute |

Service-Oriented Architecture (SOA) is a very broad term and practically meaningless. Microservices is a subset of SOA with the value being that it allows us to put a label on this useful subset of SOA terminology, Martin Fowler stated in his keynote opening the GOTO Berlin Conference.

Martin finds it hard to come up with a definition of Microservices, instead he prefers to look at common characteristics, i.e. things that most of the people working with Microservices are doing. The most interesting characteristics include:

  • Componentization, the ability to replace parts of a system, comparing with stereo components where each piece can be replaced independently from the others.
  • Organisation around business capabilities instead of around technology.
  • Smart endpoints and dumb pipes, explicitly avoiding the use of an Enterprise Service Bus (ESB).
  • Decentralised data management with one database for each service instead of one database for a whole company.
  • Infrastructure automation with continuous delivery being mandatory.

One problem with the term Microservice is it’s implication of size, but Martin’s experience is that people are very reluctant to define the size, instead preferring to talk about responsibility which is an equally vague definition. One commonly accepted way limiting the size upwards is using a two-pizza team.

An important Monolith advantage is its relatively simple and familiar approach for many developers; an advantage Martin notes should not be underestimated. Another is refactoring, especially between modules. If boundaries needs to be changed that is relatively easy to do compared with Microservices, where parts of one service may need to be moved to another service, a more complex refactoring.

Two important advantages for Microservices are the ability to deploy different services independently, and reliability, due to the ability for a service to run even if another service is down. One final advantage is the ability to build them on different platforms, e.g. as a way to experiment with a new language.

Earlier this year Martin and James Lewis wrote an article describing Microservices.

InfoQ contains numerous resources about Microservices, including an eMag.

The GOTO Berlin Conference 2014 is the second GOTO conference in Berlin, with around 550 attendees and 80 speakers.

Rate this Article

Adoption Stage
Style

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

The CAR Theorem by Jean-Jacques Dubray

"microservices", as defined by Martin, will always be constrained by the CAR theorem:
One cannot have Consistency, Agility and a Rich data model at the same time, you have to pick two. You can have a high degree of consistency over a rich data model but a low level of agility. You can have agility over a rich data model, but consistency will be difficult to achieve.

There is also one fundamental principle of SOA missing in Martin's description, which for me excludes these components from being part of an SOA: ESB is not about "plumbing" as Martin states, an ESB's role is to manage change effectively, i.e. hide change to consumers which do not want to see it and make it available for the ones that do. Over the last 15 years, I have witnessed, without exception, that each time a team didn't use an ESB, it ended up coding one at a huge cost for its organization. Now that there are open source alternatives, I am not quite sure why Martin makes it a requirement.

Re: The CAR Theorem by David Dawson

A theorem is a mathematically derived, indisputable truth. Personally, I'd like to see evidence for your assertion of the existence of a provable CAR theorem.

CAP theorem (which is fairly well known, but should be known better and sounds spookily similar to CAR), is mathematically proven, and is a lovely proof in that it takes a simple scenario and can easily scale it to complex things (it's also not "pick any two").

Re: The CAR Theorem by Jean-Jacques Dubray

Unlike the CAP theorem, that one is pretty easy to demonstrate since it is based on a simple combination analysis (N services, D degree of denormalization of the data model across the N services, C the amount of code needed to keep the now distributed information system together). Compound that with a minimum of four consumers of varying capability (each service exposing 4 APIs). Agility is inversely proportional to the amount of code you need to write to implement a given user story.

I have seen so many companies dying under that combinatory power that's not even funny. Even thoughtworks had a video on YouTube about a large customer in Australia, that nearly killed itself as an early adopter of microservices. Mysteriously, that video is no longer available. This was the link.

I find it quite interesting that Martin recommends an architecture that end up lowering significantly the degree of agility of most organizations.

Architecturally in an SOA you have to distinguish between APIs, Services and Integration Points (into the Systems of Record). What people call "microservices" are for all intent and purposes integration points. The difference between an integration point and a service are two-fold:
a) when the system of record changes, the corresponding integration point interface changes (and ripples to its consumers). Systems of record do not have the ability to keep interfaces constant. They are optimized to evolve rapidly, but not to keep consumers happy.
b) integration points are only wired to the underlying system of record, their implementation does not orchestrates other integration points (or services).

I wish you good luck when you'll need to achieve consistency from the IP point of view. Microservices Architectures are about to redefine spaghetti code. I am sure someone will come up with a new name for it like vermicelli code.

Microservices have been tried for at least a decade and always landed to the most horrific architectures that can only be sacrificed. Why? because of they can't deal with Consistency properly. Delivery teams will always pick Agility and Rich Data Models over Consistency.

Re: The CAR Theorem by Robin Villiers

You should call that a hypothesis. A Theorem can be proved. And in this case that means mathematically defining what is means to be consistent, agile or have rich data. Then you have to use logic to prove the result.

These are subjective terms, so its impossible.

Advantage of testing on microservices by Robin Villiers

I'm very much in favour of blackbox testing of micro services rather than trying to test monolithic architecture. In terms of performance of the testing process itself, testing a micro service is simpler and quicker and has less dependencies than testing a monolith.

The obvious counter argument is that you aren't testing the whole picture when testing micro services. This is true, but you can never test the whole picture anyway. So its a trade off. Completeness of testing compared to timeliness of test results.

Re: The CAR Theorem by Jean-Jacques Dubray

Let's be less subjective them, could you please explain how you achieve consistency in a microservices architecture?

If you want to take a specific example, let's talk about Customer Details in an ecommerce web site (with marketing, shipping, payment, ... microservices).

Re: The CAR Theorem by Ken McCormack

Interesting idea Jean-Jaques!

Considering CAP theorem (this was once called "Brewer's conjecture"), just as we no longer aspire to achieve data consistency via a distributed transactions, nor would we now look for "monolithic consistency" of contract in a microservices architecture.

In data, we have concepts of eventual consistency (e.g. Amazon, Ebay) to help us mitigate CAP, and in contract we have concept of versioning and resiliency (see Netflix www.activestate.com/blog/2014/08/microservices-...)

So, for example, we might update a payment service, but that doesn't necessarily mean it can no longer accept requests in its previous format. We might retain the legacy version capability until all clients are updated. Or, we might cause the payment service to fail "version not supported", and engineer the client to then retry another service until it succeeds.

We don't need to be consistent at the same time.

Re: The CAR Theorem by Danut P

Jean-Jacque, I agree with you, an ESB is more than just plumbing, managing change is the best part of it, doing transformations when needed, service virtualization, managing security so the services do not have to worry about it, etc.

Regarding ESBs I saw both sides:

* A place where the ESB had to be everywhere even where it did not belong and that made things worse in some cases

* Another job where we tried to use the ESB "with wisdom"

With the following note: there is no such thing as an ESB in the real world, it is an abstraction.

The tools called ESB are implementing only a subset of the Enterprise Integration Patterns, that is why you may need a tool for the Request-Reply patterns, one for Pub-Sub and so on.

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

8 Discuss

Login to InfoQ to interact with what matters most to you.


Recover your password...

Follow

Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.

Like

More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.

Notifications

Stay up-to-date

Set up your notifications and don't miss out on content that matters to you

BT