Microservices is SOA done right!

If you google the title of this blog you will find several hits...and after I publish this, you will find it.  That is why I gave this blog that title....not because it is true but because it is false.  You see I want to present the truth and eliminate this false narrative.

First of all let's look at the definitions of the terms.

Wikipedia

A service-oriented architecture (SOA) is a style of software design where services are provided to the other components by application components, through a communication protocol over a network. The basic principles of service oriented architecture are independent of vendors, products and technologies.^[1] A service is a discrete unit of functionality that can be accessed remotely and acted upon and updated independently, such as retrieving a credit card statement online.

A service has four properties according to one of many definitions of SOA:^[2]

1. It logically represents a business activity with a specified outcome.
2. It is self-contained.
3. It is a black box for its consumers.
4. It may consist of other underlying services.^[3]

Microservices is a variant of the service-oriented architecture (SOA) architectural style that structures an application as a collection of loosely coupled services. In a microservices architecture, services should be fine-grained and the protocols should be lightweight. The benefit of decomposing an application into different smaller services is that it improves modularity and makes the application easier to understand, develop and test. It also parallelizes development by enabling small autonomous teams to develop, deploy and scale their respective services independently.^[1] It also allows the architecture of an individual service to emerge through continuous refactoring.^[2] Microservices-based architectures enable continuous delivery and deployment.^[3]

Micro-services are pare of a Service Oriented Architecture.  But that doesn't seen to sway the proponents of the "done right" theory.

A further distinction is that Micro-services are a Service Oriented Computing paradigm for development of Solutions, whereas the Service Oriented Architecture is a Strategic concept for the organization of an Enterprise Architecture using a Service Oriented Computing paradigm.  So Micro-services are about building solutions and SOA is about Enterprise Strategy.

Another distinction, Micro-services are typically loosely coupled, like services in SOA but Microscopes tend not to be agnostic, or autonomous, composable and reusable.  Micro-services Frameworks are all about building solutions.  They do not put a priority on the fundamental priorities and concepts of SOA.  

An Enterprise SOA can integrate applications that are built with Micro-services and that typically involves adapting those micro-services APIs into reusable and composable services either by modifying those services to accept a domain canonical schema and standardized service contract or through a legacy wrapper.

New Solutions in an Enterprise SOA will benefit by making their Micro-services compatible with and interoperable with the SOA Standardized Service Contract while also accommodating the Solution architecture.  This can be done with either a legacy wrapper or through multiple endpoints for the micro-service, one for the solution and one for SOA.

Solution Architects will decry this as over-complicating things, but Enterprise Architects will appreciate bringing the benefits of SOA.  

Why does Service Oriented Architecture improve business agility

I get this question quite often. I remember trying to explain it to a Solution Architect and his manager.  I tried to use the concept of reuse.  I said that SOA based APIs were reusable...hmmm their response was that all APIs are reusable already.  Their reasoning is that the APIs can be accessed as often as needed.  That is true, but what they miss is that with SOA and each service that wraps an API is intrinsically reusable.  Their way, you write code each time one application accesses an API from another.  With SOA you write ONE standardized interface/service and then you need not write even one more line of code to access that service.  You can thereafter use that service by simply including its endpoint in a routing map.  That is reusability.

There is an Engineering Principle called "Don't Repeat Yourself" and that is very much part of SOA.  Write something ONCE and do it right and you never have to touch it again.

So how does reusability result in Business Agility?  Here is a couple of scenarios to demonstrate.

Scenario One - Conventional Development of two solutions that each access 8 APIs in existing Legacy systems.

Once the sequence diagram is done we can see the flow and we begin coding a controller to access those APIs in that sequence.  We write 8 pieces of code to access the legacy systems and we finish by writing more code to process that data.

The second solution accesses the same 8 legacy systems but with different arguments.  So we need to develop all the same things with the slight differences, essentially 100% new code, no reuse whatsoever.

Scenario Two - Same Solutions just SOA Based.

The first solution we develop a Domain Canonical Schema for all data elements.  Then we write 8 service adapters using a standardized service contract including that canonical schema.  We write a service controller and a solution processing module.  Much the same effort of the conventional way.

The second solution and all solutions after will simply write a controller (possible to make a reusable controller but I digress) and reuse all 8 legacy services with no code changes, and the processing module.  This could save typically 40-60% in code development and testing of the reusable services.

The savings you get with SOA are clear,  The agility comes from better ROI on IT and the reduced workload allows for faster time to market of solutions creation and even more efficient changes and maintenance.