The Microservices Elephant

The term “microservices” is going through a phase where everybody has their own conceptions of it, so as soon as you start talking about it in any detail you quickly realise you all mean something slightly different, and you start questioning the value of language and why you bother talking at all. However, given there is now a book out, and a conference on it next week, it feels like it’s about to become a lot more definite. I thought I’d brain-dump my own thoughts on a few of the conceptions that are out there, before my own stance gets hopelessly clouded by many others.

modules + network = microservices

This is from an article by @tef, whose opinion I generally respect and, whilst I agree that “spreading bits of state across a network is a ... world of pain and suffering” and that “keeping data in sync across a network while tolerating failure is an incredibly hard engineering problem”, I really don’t think that’s the problem that microservices are meant to solve. Note that there are plenty of other things I do agree with in that article, so please go read it.

As in so many things, if you’re faced with a very hard problem, the first thing to seriously ask yourself is whether there is actually a far easier problem lurking within, that is the one you should be solving. In this case, the problem is not keeping state in sync. Bits of state, encapsulated behind a network interface maybe, but separate bits of state, which don’t even need to always be consistent. For example, I wouldn’t build a networked filesystem using microservices techniques, but I would build an advertising system using them.

microservices = contractors for hire

Some of my contractor friends might be offended by the following, but here goes :-) Microservices collaborating within a microservices architecture don’t fully trust each other. They make reasonable demands of each other, and expect responses, based on an agreed contract, but there is always a need to be ready for that contract to be cut short, or expectations to not be met. Microservices are about wrapping unreliable actors, and making them reliable in aggregate and/or ensuring unreliability at the micro scale does not become a macro problem.

This analogy also captures the aspect of taking advantage of heterogeneity: microservices allow you to select the right tool/library/language for the job, as long as it presents itself as a semi-standard service.

A microservices architecture should treat some demands as contractually required and others as nice-to-haves. For example, all services should guarantee a low-latency response, but the quality of response can be varied, or be a partial response, so that the latency remains guaranteed. High quality should be optimised for, but low quality allowed; high latency should be survivable, but low latency expected.

microservices = a portfolio of risks

This is analogy doesn’t fit all microservice contexts, but does fit the ones I like working with. Here, you actively hedge one microservice against another, so that when one fails, or gives a low quality answer, you can fall back on another. This is actually a tactic which works within a service as well as across them. For example, within service: using an in-memory out-of-date cached copy when an external service fails; across service: use recommendations from a less-personalised service when the personalised one times out.

microservices = agent programming for the web

@robstewartuk @russmiles @boicy @russmiles no, no, and three times: no. AOP was a pie-in-the-sky dream, MS is derived from implementations.

— mike_moran (@mike_moran) February 7, 2015

(Gack; I wasted a lot of time in the 90’s thinking about agents).

As you’ll have read above, my own take on Microservices very much treats co-operating services as a network of partially trusted actors, each with their own behaviours and preferences. It’s fine for myself and others to think about them that away, and to design libraries and tools that work well together given these assumptions, but there is absolutely no need to embed this understanding in the systems themselves. I’m not saying you can't build robust, flexible, and apparently clever systems with agents, but rather that they are not necessary.

In conclusion, based on the above, my own idea of what microservices are is very much tied up with what I want to do with them, as opposed to the more wide-ranging meanings of others. No surprise there really, but now I’ve got that brain-dump out of the way, I look forward to finding out more and/or being usefully proved wrong in my assumptions about how to build systems well!