Microservices and SOA

Over the last few years the term "microservice" has grown up to describe an architecture composed of a suite of smaller services. At QCon San Francisco 2012, Thoughworks' James Lewis presented on the concept as well as co-authoring an article with Martin Fowler on the same topic. Recently though Steve Jones has entered the debate by arguing that Microservices aren't new as some believe and are in fact another term for SOA. In order to do this he compares and contrasts the current definition of Microservice with the OASIS SOA Reference Model. Steve follows the breakdown that James and Martin take in their article:

Componentization via Services: The OASIS SOA RM states:

Service Oriented Architecture (SOA) is a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains.

As Steve points out:

OASIS then goes nicely into WTF actually is a service,

• The capability to perform work for another 
• The specification of the work offered for another 
• The offer to perform work for another

In SOA, services are the mechanism by which needs and capabilities are brought together

 And Steve draws a comparison with what Martin/James say on the subject:

services are out-of-process components who communicate explicit component interface

Organized around Business Capabilities: this is where Steve believes Martin gets it wrong and Microservices aren't new. The OASIS SOA RM defines a capability as

A real-world effect that a service provider is able to provide to a service consumer

Steve points out that it is important to differentiate between the capability (that which does the work) and the service (the organising construct).

What we found when doing SOA in the wild for over a decade, and all the people on the OASIS SOA RM had lots of experience doing this, was that the organising framework was separate from the actions themselves.  The reason this is crucially important is that people started often making services where service = capability so you ended up with lots and lots of services (ummm if I was being insulting I'd call them microservices)

He believes that whilst Martin's text on the subject is ok, it lacks important references to the past.

New?  Hell even I wrote a book which talked about how to model, manage and set up teams around this approach. The SOA Manifesto (2009) talks about key principles behind SOA (I still prefer the RM though) from a big group of practitioners.  The point here is that there are two problems, first the confusion of service and capabilities and secondly the lack of recognition of hierarchies importance in governance.

Products not Projects: Steve says that the article from Martin and James goes beyond the SOA RM on this topic, but again is not saying anything that is new.

A quick hit on Google just shows how many pieces there are in this space, some better than others and some products better than others but really this is not new.  I used to use the phrase 'Programs not projects' and always talked about assigning architects for the full lifecycle 'to make them accountable'.    Again its not that this statement is in anyway wrong, its just that its in no-way new.  We've known that this has helped for years but it has a significant issue: cost.

Smart endpoints and dumb pipes: Steve agrees with this principle wholeheartedly, but again does not believe it is anything new. He would also phrase it slightly differently as he explains:

In the OASIS SOA RM there is the concept of an 'execution context'.  Which is the bit that lets a service be called and its capability invoked.  Clearly the end-point is 'smart' as its what does the work, hence the phrase 'mechanism' used above.  The 'pipes' may or may not be dumb (the 'pipes' talking to those Rovers on Mars are pretty smart I think) but what they are is without value.  This was a crucial finding in SOA and is well documented in the SOA RM.    The execution context is where all of the internal plumbing is done but its the Service that provides the access to the capability and its the capability which delivers the value.

Decentralized Governance: Again something on which Steve agrees with Martin and James. However ...

I think its not bad advice its just that SOA gives so much more than Microservices in terms of governance.  SOA as described in the OASIS SOA RM allows these principles to be applied to all IT assets not just those implemented with a specific implementation style and indeed to just to IT assets meaning its an approach that business schools are teaching.

Microservices and SOA: It seems that initially the article from James and Martin did not reference SOA (enough or at all). Apparently as a result of recent interactions with Steve, a sidebar on the topic was added to the article. However, Steve thinks that not only is it insufficient, it's a red herring:

[...] its not a true definition of SOA instead rolling out the old 'big' ESB and WS-* trope that was so loved by the RESTafarians when explaining why their way was better.  The claim is that this article 'crisply' describes the Microservices style and thus is valid in comparison with SOA as 'SOA means so many things'.  This I fundamentally disagree with, firstly because Microservices would be better served as an implementation approach if it could explain how it fits with non-Microservices approaches, something that SOA does a great job of doing, and second that it can't even say what makes a service 'micro' with services ranging from decent sized (12 person) teams down to individuals.

In conclusion, Steve re-iterates that in his opinion Microservices is nothing new and is in fact just a Service Oriented Delivery approach. In his view an architect/developer would be better off using SOA, which is much better defined and with much more experience now. Instead of talking about Microservices as something new, we should be talking about SOA "today". And as Steve mentions:

Additionally the fact that one of the references that is used is that of Netflix who actually use the term 'fine-grained SOA' as recognised in the footnotes sort of underlines the fact and the fact that another (Amazon) also says its SOA.

So what do you think? Is this just SOA or do Microservices offer something fundamentally different?