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.

Service Oriented Architecture and Security

So what does Security, Cyber Crimes, Denial of Service, and other Security Concerns have to do with a Service Oriented Architecture?

Does having a Service Oriented Architecture translate into having a more secure enterprise?  Maybe yes and maybe no.

Certainly having an Enterprise Architecture can translate into better security and I will explain why further down.  And since arguably a Service Oriented Architecture is a Strategic decision, then it might also mean your Strategic Plans that include a Service Oriented Architecture MAY translate directly into better security.  BUT just having a Service Oriented Architecture DOES NOT mean you have better security.

What do you need to consider?  For one, it should be obvious that not having an Enterprise Architecture that includes:  Standards, Practices, Policies and GOVERNANCE leaves gaps that could be exploited and reduce security.

Let me give an example.  Let's say you realize a threat, maybe because of an attack or attempt to penetrate your defenses.  You employ a security vendor and they do a scan and fix and give you a secure enterprise from the Firewall into your internal systems.  Ok great, probably money well spent and you now can sleep at night.  But without an Enterprise Architecture there would be no governance to enforce the Standards, Practices and Policies that were the result of the scan and fix.  Then the same factors that were responsible for your previous gaps in security will exist and being ungoverned could lead to the same vulnerability.  Perhaps it is simply the addition of a new service may open a small seemingly insignificant hole in your defenses.

A Service Oriented Architecture when part of an Enterprise Architecture will make the task of implementing Standards, Practices and Policies but also Governance.  A security service domain that can interact with your integration layer and your OSS service domain, will be far more agile and efficient in preventing, detecting and predicting attacks and in responding to unforeseen attacks.

Being able to modify in flight processes automatically might just save your enterprise when a trial and error attack is detected and your OSS is notified and your Security Operations Center is notified and that process vulnerability can be corrected rapidly.  If your systems are large monolithic applications, (i.e. Non SOA) then such agility is NOT POSSIBLE.

Be safe, be agile.

EAG2

via IFTTT

EAG2

The goal of any Enterprise Architecture is to communication standards, practices, policies and the Governance needed to ensure that the entire Enterprise is agile, efficient and standardized.  This presentation explains one possible Service Oriented Architecture as part of an Enterprise Architecture.

soaFundamentalsAgility

via IFTTT

SOA Fundamental Agnostic Service

via IFTTT