Published on December 22, 2018
For the last couple of years, people were debating whether Microservices realise SOA. With my experience in Services of 22 years, I can confirm that Microservices do realise SOA at a “teenager” maturity level, while Web Services and REST were at the kindergarten SOA maturity level. How am I count this level? Simply – I try to match the technology capabilities against the OASIS Reference Model (RM) and Reference Architecture Foundation (RAF) for SOA standards, which have been accepted by The Open Group and OMG Standard Bodies as foundational for SOA.
What prevents Microservices to become “adults” in SOA? Why are they not fully-grown Services yet?
This is the reason – the SOA RAF states that SO Ecosystem covers both business and technology and does not belong any one of them exclusively. While Microservices adhere to this fundamental statement by referring to the business values they provide to their consumers, they still do not meet the major requirement that guarantees (if implemented) mentioned statement.
Particularly, the SOA RAF requires that each Service should be accompanied by Service Description, which defines not only programmatic interfaces (Services may have more than one interfaces), but also business functionality and outcomes (not only returns) provided as well as the context policies, under which SLA for particular interface and outcomes will be delivered. If the Service provider opens Service interface for anyone interested, the Service Description plays a technical and legal role as an implicit Service Contract. If there is a special agreement between the Service provider and consumer with additional agreements, we have an explicit Service Contract. In both cases, the Service provider is legally obliged to the Service consumer for the Service availability, accessibility and quality.
This theoretical preamble is needed because Microservices do not have such legal functional descriptions and all Microservice consumers use the Microservices on their own menace and create an uncontrolled dependency. This is a way too risky from the business perspectives, especially if Microservices, owned by other legal entities (companies), represented as public API. The logic here is simple – since the Microservice provider does not have any obligations to the Microservice consumers, it can change functionality, interface and outcomes of the API or even discontinue it at any time with no warnings to the consumers.
I call Microservice-based API an open-ended Service – the consumer never knows and cannot be sure whether the Microservice has no “side-effects” that can harm the consumer. For example, a Microservice with no business contract is not limited to servicing the consumer and can sell the consumer data to its competitor. If you do not believe me, try to figure out any economic or political reason why this could not be done.
Cloud and containers have helped a lot in fixing the open-ended service – containers disallow hidden sharing of Service/Microservice code across container boundaries. All interactions inter-containers should be explicit. Unfortunately, there are no restrictions (supporting the design of Service/Microservice based on Principles of Service Orientation rather than Object Orientation) enforced over the Service/Microservice code. For the last 18 years, the industry has found and proved many times that the concept and real business values of Service Orientation require Services to be decoupled from the resources and environment such that they cannot control their relationships with. In a contrast, Object Orientation does not have such principle and, in a contrary, couples objects and used resources for the ease of management.
The Spring Framework, frequently used for the Service/Microservice implementation, is a classic example of the described methodological gap. I will illustrate this conclusion using two examples based on the Spring’s injection technology.
Example 1. One of the Principles of Service Orientation is Service Composability. Since only a few people have read the actual Principle’s description, many interpret it like ‘a service may be composed of other services’. This is totally wrong and contradicts several fundamental Principles of Service Orientation at once. Actually, the Principle of Service Composability states that any Service can participate in as many Service Compositions (relatively stable aggregation of Services gathered for the collective work for solving a particular task) it wants as well as organise as many Service Compositions as it wants. However, if a code of one Service/Microservice injects the code of another Service/Microservice, we can easily get 1) a conflict between objectives (Service Descriptions – interfaces, policies, contexts) of both Services; 2) violation of the mentioned and a few other Principles of Service Orientation; and 3) coupling between independent Services/Microservices. Yes, Principles of Service Orientation are quite different from the Principles of Object Orientation.
Example 2. The same Principle of Service Composability leads to the requirement that a Service/Microservice should be decoupled from its resources as much as possible. This is the principle requirement because a Service/Microservice does not care who and how provides the resources if they can be delivered via a predefined interface and on time. As a result, the Service practice has introduced two basic categories of Services: Business/Utility Services and Data Access Services. The former do not know about the data source, only about the data model they need. The latter is physically linked with the data storages and aware of both data schemas – used by the Services and used in the data store. The problem here is that Spring Framework offers each object (in the body of the Service) ability to link to the data stores coupling objects with the data store.
If a developer uses datastore links for each object within the Service/Microservice (provided by Spring Framework), s/he couples the Service/Microservice with the resource/environment. This is wrong because it violates many Principles of Service Orientation. However, this is very convenient and tempting for developers but results in implementing not Services (and not Microservices), but the old (2001) objects with Web interfaces. Such constructs do not possess capabilities promised by Service/Microservice in the delivery of business values (as it was back in 2009 when such “services” were pronounced dead by the experts). For instance, a prompt recomposition of Services/Microservices for solving new business tasks and addressing changes with minimal time to marker becomes impossible because the direct links to data stores anchor Services/Microservices and limit their use in different compositions.
This observation can be summarised in three major governing rules for the Service/Microservice implementation regardless object development technology used:
1. Only Data Access Services/Microservices may access data storages and other resources across the Service/Microservice and container boundaries
2. The Business and Utility Services/Microservices that need particular data may obtain them only by engaging Data Access Services/Microservices
3. The Business and Utility Services/Microservices do not own data and do not care where and how the data are obtained for them; they maintain the meta-data (business semantics) only.
Any violation of listed rules in the Service/Microservice implementation abuses destroys the values that Service Orientation adds on the top of Object Orientation.
HOW to ARCHITECT for DEVELOPERS 