SOA is coming back. Quite a funny story for me!
Welcome the fabric of services on the Cloud platforms
Opinion piece by Pierre Bonnet, October 27, 2018
In the 2000’s I worked much on the Service Oriented Architecture (SOA). At that time, companies were attracted by the idea to reshape their existing Information System through services, or even rebuild ones from scratch. We established a methodological framework to identify the perimeters of such business services, then their internal architecture around secondary level services. All was based on UML notation mainly. Sadly, the way we implemented the services was stuck at the semantic and logical levels. For the physical level, the centralized RDBMS was unavoidable. No way to let the services layer operates the data joins since the database was (is) intrinsically able to do. No way to split the persistence layer into many blocks due to security and integrity reasons: how to enforce the ACID transaction over two or more physical persistence blocks? Once again, the centralized RDBMS was the best solution to keep safe the data.
All our effort to educate the market with the SOA methodology was questioned because of the difficulty to get the full ROI when facing the deployment at the physical layer. The SOA was stuck into a monolithic physical infrastructure: hard to scale, hard to create self-sufficient block encompassing a service with its own data, no standard protocol to facilitate the communication between the services.
Nowadays, with the fabric of services promoted on the cloud platforms, we are facing a huge coming back of the Service Oriented Architecture. Actually, the “microservice” term is a very bad naming of the idea providing with this cloud architecture. Indeed, a microservice is not a secondary or atomic technical service. This is totally the opposite.
A microservice is a “business service” in the SOA terminology. It is clear that the perimeter of a microservice, in particular in case it is stateful, includes its own database. It becomes a building block with a perfect autonomy of execution, versioning, governance, etc. A good microservice, is the one who can be managed in an autonomous way without any impacts and dependencies against the other microservices.
To make this architecture possible, it is quite sensitive at the physical layer for two main reasons, that made the SOA deployment quite annoying in the past:
Now I must raise a warning about the current situation. It is very good to see the maturity of the services fabrics on the cloud platforms, but watching on conference videos, sharing with some IT experts in this field, I really feel a big missing knowledge in term of methodology. This is time for SOA to come back! Honestly, if the microservices are designed without a systemic view of the target, then nothing will prevent the microservices to duplicate their data structure in a bad way, then at the time you need to adapt a microservice you could face too many bad dependencies who will entail a possible collapsing of your systems.
Don’t miss this point: docker, containers, microservices are beautiful IT concepts, but they are tools we have to use in a good way to sustain our systems. If you don’t know how to identify your business services from your organisational processes, if the concept of “Business object” still unclear, if the orchestration level of services is not designed then the sustainability of your cloud fabric services is maybe not sustainable. The growth of your services will entail a possible collapsing of your entire new systems.
As a findings, this is a call to IT experts of containers and microservices, take time to come back to the past and read again the SOA methodology legacy. Surely it exists some good traces from the past on the web. See! I am still alive! I can say I am one of these traces from the past. Don’t forget the SOA methodology.
COO – Orchestra Networks