Services, Microservices, Nanoservices – oh my!

Apparently, there’s this new distributed architecture thing called microservices out and about – so last week, I went ahead and read Martin Fowler’s & James Lewis’s extensive article on the subject. And my reaction to this was basically:

I guess it is easier to use a new name (Microservices) rather than say that this is what SOA actually meant – re http://t.co/gvhxDfDWLG

— Arnon Rotem-Gal-Oz (@arnonrgo) March 16, 2014

Similar arguments (nothing new here) were also expressed after Martin’s tweet of his article, e.g. Clemens Vasters’ comment:

@martinfowler @boicy but these are the very principles of SOA before vendors does pushed the hub in the middle, i.e. ESB — Clemens Vasters (@clemensv) March 16, 2014

Or Steve Jones’ post, “Microservices is SOA, for those who know what SOA is.”

Autonomy, smart endpoints, events, etc. that the article talks about are all SOA concepts – If you happen to have read my book and you read this article, you’ve probably identified these as patterns like “inversion of communication”, “Service Host“, “Service Instance“, “Service Watchdog” and others.

So microservices, as they appear from Martin’s & James’s article, are pretty much service orientation without some of the bad misconceptions that tied into the SOA moniker like WS*, ESBs as a must, etc. -perhaps that’s a good enough reason for a new name, but personally I doubt it.

However, the story doesn’t end here; there are various other opinions as to what microservices are, such as Chris Ford’s view, which says that

“My own opinion is that microservice architectures can be understood through a single abstract architectural constraint which can be interpreted along many different degrees of freedom.

X can be varied independently of the rest of the system.”

The idea that something is separate and can be varied independently from the rest of the system is good, but I would hardly say it is a definition of anything or at least anything new. CSCI (Computer Software Configuration Item), which I first heard of as part of  DOD-STD-2167A (published in 1988), essentially means the same thing: a CSCI is a component that can be varied independently from the rest of the system. In 2167A eyes, it also means a very detailed, waterfall, documentation-laden process,  which isn’t what anyone thinks service or microservices should entail, but it does demonstrate that “being varied independently” doesn’t mean much.

I am sure some readers say something like, “But wait, we’re talking about micro-services here  – so they should also be small.”  – indeed, there are posts like James Hughes’s on microservice with a quote like

“First things first what actually is a micro service? Well there really isn’t a hard and fast definition but from conversations with various people there seems to be a consensus that a micro service is a simple application that sits around the 10-100 LOC mark.”

(truth be told, in the next sentence, James says that LOC is an atrocious way to compare implementations, but I thought it was worth repeating due to the use of the  words “there seems to be a consensus.”)

So, how can you have 100 LOC services? You can get there if you rely on “Service Host” on frameworks (like Finagle or Sinatra James mention) to generate serialization/deserialization code (Protobuff, Thrift, Avro, etc.)  – this is essentially building on a smart  “service host”.  Another example of this would be developing Erlang with its supervisor hierarchies, which also brings us to another way to reduce LOC by using languages that are less verbose (like the aforementioned Erlang, Python, or Scala vs., say, Java).

I would say., however, that if you find you have ten lines of code service, you are more likely than not implementing a function as a service and you don’t have a real service micro or not- e.g., I can’t see you having decentralized storage (and autonomy) as mentioned in Martin’s and Lewis’s article above or having monitoring and instrumentation that Hughes mention.

You should also keep in mind that while better and cheaper networks allow us to push the limits – the fallacies of distributed computing still exist. Furthermore, having a lot of small services that you need to manage along with the performance hits for serializations and deserializations, security, etc., may very well mean that you moved from valid smaller “micro” services into the realm of headache, which I called “Nano services.”

“Nanoservice is an antipattern where a service is too fine-grained. A nanoservice is a service whose overhead (communications, maintenance, and so on) outweighs its utility.”

So there we have it. For the most part, microservices is just another name for the principle of SOA; another name might have been appropriate in the hype days of SOA, but I think these days, most of that vapor has cleared, and people understand better what’s needed. Furthermore, if we do want to name proper SOA by a new name, I think microservices is a poor term as it leads toward the slippery slope into nano-services and ten lines of code, which are just your old web service method executed by a fancy chic host using a hot serialization format.

Micro or not, services should be more useful than the overhear they incur

illustration by Les Chatfield

Related posts:

The Saga pattern and that architecture vs. design thing Suprastructure – how come “Microservices” are getting small? SOA Patterns status update