Recently, browsing on YouTube, I re-watched the lecture given by Martin Fowler in 2014 on the microservices. As usual, Martin was a wonderful speaker, clear and concise. But in the middle of the lecture when he talked about differences between Microservices and SOA, I found his speech a bit more confusing and his conclusion on that topic was unclear and vague.
If you pay attention to his speech, before saying his conclusion on that chapter, he reported two witness statements: the first was from SOA people who developed successful SOA projects, surprised by the lack of innovation and freshness in the microservices definition and practices, and the second, from microservices people, mainly coming from big companies, fed up with SOA, who see SOA as 'Enterprise Services Bus' and 'committee that wants to lay down standards'.
Then, Martin concludes by an evasive definition that Microservices is a subset of the SOA.
However, he did not give any border line between the two domains, but said that the term, SOA, is a too broad and the microservices is a useful subset of SOA.
With all my respect, I think that if Martin presented good arguments in his
Before going forward, it is interesting to notice, that concept of microservices had a prompt success in large companies first. Surprisingly, from its inception, the microservices have been used to deprecate the 'SOA' concepts, even if the gap between both techniques was very thin or in many cases, null.
Here
Martin provided in his lecture, many trails to reply to the questions, but I came to a different conclusion. If we can understand this antagonism which is not based on technical differences, maybe we will understand the differences between SOA and microservices.
To understand this antagonism, the SOA Manifesto, the abstract of the SOA philosophy, must be read once again. In the manifesto's introduction, it is written:
Through our work, we have come to prioritize:
Business value over technical strategy
Strategic goals over project-specific benefits
Intrinsic interoperability over custom integration
Shared services over specific-purpose implementations
Flexibility over optimization
Evolutionary refinement over pursuit of initial perfection
That is, while we value the items on the right, we value the items on the left more.
In this introduction, the first priorities were not technical challenges, but the Business value and the Strategic goals.
When you are concerned about Business value and Strategic goals in your project, it is in your interest to involve the most capable to define what the Business values and the Strategic goals are. This means that the SOA philosophy requires the business to collaborate and more annoyingly for IT teams, it needs a kind of leadership from the business, because Business
For years, business and IT lived in two different worlds. The communication between them was focused on budget, cost, business specifications and nothing else. It was OUT OF QUESTION that the business interfered in the IT works and the later in the business prerogatives. This antagonism between the two entities lasted for decades.
However, 10 years ago, for the first time in
Unfortunately, especially on larger projects, consulting companies found in this opportunity a way to impose expensive business consultants and management, to IT teams. I remember taking part in numerous meetings with high-rate business consultants who didn't have a concrete idea of what a service is, but could explain through wonderful PowerPoints, how SOA could help us to design and develop them. Pushed by the C level management and the consulting companies, a useless business predominance replaced a required and fruitful collaboration between both parties. A reaction, from the IT, to stop this predominance occurred and has been named 'Microservices'.
It is interesting to analyze, why this reaction took the name of 'Microservices' and not 'Light Services', 'Agile Services' or 'Reactive Services'?
The prefix 'micro' before 'services' that suggests services with fine granularity, does not make sense since neither SOA nor Microservices define a standard granularity for a service. Often services defined by microservices developer have a coarser granularity than the ones developed by SOA developers
Wise men explained that a name, often contains the finality of the named entity or concept.
As noticed above, one of the SOA aims, was to promote Business Value and Strategic Goal. Consequently, this aim was to define services comprehensible by the business and coarse enough to be useful for business process definition.
In reaction, IT people created the concept of 'Microservices'. The objective was to define small services where the granularity was too fine to be in the business scope. So, with microservices, the business cannot interfere in the IT work anymore. That is the opposite of the SOA initial philosophy.
Actually, there are no technical differences between SOA and microservices, but their fundamental difference is the interest in a relationship between business and IT
In reaction to the business predominance created by the bad use of SOA philosophy, business concerns and strategic goals have been erased from the microservices manifesto and developer objectives.
Microservices SOA Collaboration with the business Yes, please No, thank please
The border line between SOA and microservices is simple to understand and is defined by the IT wishes to work with the business. Through this dimension, Microservices is not a subset of SOA but a different domain.
Of course, the real life is not black and white and many microservices people collaborate with the business and some SOA people don't. Here, I'm not talking about
This said, everyone knows that the future of IT is to work in harmony with the business and allows it to be involved in service and process definition. We could wait for a few years, the next swing of the pendulum and then be thrilled by a new buzz name that promotes a collaboration between IT and business.
Or simply, whatever