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,
In SOA, services are the mechanism by which needs and capabilities are brought together
- The capability to perform work for another
- The specification of the work offered for another
- The offer to perform work for another
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?
Seems like good old SOA to me
I think the realization that async messaging is important has really brought us back to traditional SOA with message bus / ESB (enterprise service bus) style of integration.
The granularity and protocols may be different but the concepts are still the same.
Re: Seems like good old SOA to me
Async messaging doesn't require a message bus. Async messaging is a pattern, a style, a design concept. It can be implemented with an ESB (a technology) but equally it can be done with TCP, UDP, HTTP, SPDY and many other technologies.
Thus SOA does not require ESB. Further SOA typically requires some number of communicating processes to be spread across a network. Once you do that, you must start applying some distributed systems theory.
In that body of theory is a recommendation to avoid concepts and technologies that embody the concept of a single principal. For example a bus that performs all communication across all services routing all traffic. There is also a recommendation to avoid concepts and technologies that promise to never fail. For example a bus that always deliver messages and is always available regardless of problems in its deployment environment.
So, should one use an ESB to underpin an SOA? Probably not. Certainly, given what it provides, it is not essential. Nor does the presence of an ESB in some environment imply one is doing SOA.
Re: Seems like good old SOA to me
...So, should one use an ESB to underpin an SOA? Probably not. Certainly, given what it provides, it is not essential. Nor does the presence of an ESB in some environment imply one is doing SOA.
Sorry for not being clear. I did not mean to imply that SOA or async communication cannot be done without ESBs (its just another useful piece of infrastructure along with registry; process, event-correlation and pub-sub engines; messaging appliances for security, transformation and routing; etc.). And yes all of these capabilities/protocols can be implemented by applications themselves, without the need for middleware.
My real point was that the rise of 'REST' has resulted in a de-emphasis of async communication but real-world needs have driven it squarely back into the picture. The popularity of AMQP (RabbitMQ) and now MQTT are a testament. And so SOA is still relevant - the right framework for building distributed applications.
Physical vs Logical, horizontal vs vertical
Most of the articles I read about microservices, contain ideas I learnt from Udi Dahan's SOA 2.0 model. Especially when it comes to thinking of services as logical components, covering the whole vertical model from DB to UI, which in term enables teams to take full responsibility over the functionality provided by these - preferably small - services.
For me, this is the big change: don't think of a service as a component between DB and UI. Those 2 are part of the service as well. You whole system gets split up vertically into services, which do not share data and each have their own specific responsibilities.
Unfortunate naming collission with OSGi
Re: Physical vs Logical, horizontal vs vertical
It's a bit like XP in the sense that it's a lot of good ideas from a lot of people that work in a pragmatic way in the real world and combined with programmable infrastructure and automation to get something that is (in my opinion) greater than the sum of the parts. It's fundamentally a community-driven set of better practice approaches to building software that at the moment has the term "microservices".
Re: Physical vs Logical, horizontal vs vertical
The OASIS SOA Reference Models covers all of the abstractions we need.
Would the proponents of Microservices come up with a different reference model? I don't think so.
If it looks like a duck and swims like a duck, then it is a duck
Re: If it looks like a duck and swims like a duck, then it is a duck
One difference between SOA and microservice arch