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.  

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.