Dan's Take

Containers: SOA in Disguise

Once again, the past proves to be prologue.

• By Dan Kusnetzky
• 12/22/2016

Recently, I've had conversations with several supplier representatives who are proponents of recreating applications or creating new applications using "microservices" that are developed and deployed within containers, a form of OS virtualization and partitioning.

They often point out that this approach can simplify the creation of complex applications, reduce or eliminate errors and make it possible to build new applications more quickly in the future. They seldom, of course, discuss the time it will take to build, test and document all of the necessary microservices. These conversations remind me of similar conversations with vendor representatives who were pushing the service-oriented architecture (SOA) more than a decade ago.

What Is SOA?
SOA can be described as a structured development style in which applications are decomposed into individual, stand-alone services that can be developed, tested and documented separately. Typically, these services represent a single business function that's self-contained, and can be considered a "black box" once it's finished.

These business functions were developed using well-defined inputs and outputs that could be delivered across the network in a vendor- and platform-neutral way.

What was often forgotten was that network-oriented communications architectures were nearly always slower than inter-process communications architectures used to communicate from one function to another within a monolithic application that executed on a single host.

While the promise was most certainly there, many enterprises gave up on this approach because they couldn't get the performance or reliability that they were seeking. They also discovered, much to their chagrin, that SOA was inherently more complex to monitor and manage than the monolithic application it was meant to replace.

Dan's Take: Back to the Future
The industry has a rather short memory, and it forgets what worked before and why. Similar language is being used, but with a new name. It's been changed to microservices, and the underlying architecture has been changed to the use of either virtual machines (VMs) or OS virtualization and partitioning, aka "containers."

Once again, the goal is making it possible for developers to easily stand up a function in a neutral, platform-independent fashion and then deploy it on a single host, multiple hosts or hosts in multiple datacenters. As one might expect, cloud services providers are very happy to promote this approach because it will make it much simpler in the end for enterprises to re-host all or part of a workload onto a system in one of their datacenters.

This time, however, some remember the challenges imposed by SOA and have worked to address the challenges. I just heard an interesting presentation by Big Switch Networks on how their networking tools can make it possible for developers and administrators to monitor what's going on at the container level, and also see how the entire network is running. I've heard presentations by Red Hat about how its version, OpenShift, can make it easier for developers to put together and manage application components based on Docker containers and the Kubernetes container cluster manager.

Only time will tell if microservices -- that is, containers -- will work better than SOA on top of Windows, Unix and so on, as was tried in the past.