Earlier this year we posted an article about the recent rise in discussions around the term Microservices and whether this represents a new approach to architecture or, as some like Steve Jones suggest, it is simply SOA by another name. Given the comments in the article, it seems that the majority of readers (or the majority of those who commented) believed Microservices is really just SOA and a new term is probably not needed. After that article Steve posted another entry, where he discusses how Microservices is really just Service Oriented Delivery and how attempts to distance it from SOA do not make sense:
[...] Microservices lays down some nice rules for implementing certain parts of an enterprise but those are best served by an honesty that its an implementation choice within a broader Service Oriented Architecture. That doesn't devalue it in any way, just places it in the right context.
Arnon Rotem-Gal-Oz has also entered the debate:
He also believes that Microservices, as defined by Fowler and James, is nothing more than SOA, perhaps without some of the "bad misconception" that meant some associated SOA with a hard requirement on WS-* and ESBs. He then asks precisely what is a Microservice and quotes James Hughes (the link he uses is not valid at the time of writing):
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.
According to Arnon, James does admit later in the same article that lines of code are a very bad way to compare service implementations (something which Jan wrote about too in his article on usage being more important than size), but Arnon wants to focus on the consensus aspect to which James refers:
So how can you have 100 LOC services? you can get there if you rely on frameworks (like Finagle or Sinatra James mention) generate serialization/deserialization code (protobuff, thrift, avro etc.) - this is essentially building on a smart service host. Another example for this would be developing in Erlang with its supervisor hierarchies which also brings us to another way to reduce LOC by use languages that are less verbose (like the aforementioned Erlang, python or scala vs. say, Java).
Arnon's point is that services with 10 to 100 lines are likely to be exposing functions rather than being a "real service". He also believes that the the smaller the service gets (towards what he calls "Nano services") the more mangement overhead you have to worry about, serialization/deserialization costs, security etc. Essentially the smaller these services become, the more glue you need to pull them together into a useful "whole". As Arnon says:
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.
Like Steve and others, Arnon concludes that Microservices is just another name for SOA. He does believe that years ago, early in the hype of SOA, perhaps another name might not have been such a bad thing, but today with the concepts behind SOA fairly well established and understood a rename is not helpful.
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 10 lines of code which are just your old web-service method executed by a fancy chic host using a hot serialization format.
Despite the fact that many people seem to agree that the term Microservice is neither new nor needed, we are seeing a rise in frameworks that are being sold on their ability to support Microservice. So perhaps this is a term that the industry will have to accept, even if the majority understand it as another name for SOA?