Containers and the Composable Enterprise

In order to compete at the ever-quickening speed of business, IT shops need to discard the legacy ways of thinking about system design and architecture, and instead support their business with an architecture that is malleable, handles scalability in all directions and can accept new technology shifts both upstream and downstream.

6 min readFeb 4, 2016

Many enterprises have this problem today. This problem may have been inherited or it may be of their own making, but in any event, it is suffocating that company’s ability to be nimble, to innovate, and possibly even compete in their current marketplace.

For years, this challenge could remain hidden within the confines of corporate walls simply because the limitations of internal IT systems very rarely impacted the day-to-day operations of the company. Workarounds and supplemental processes allowed the necessary jobs to get done regardless of the pain.

Back-office systems can no longer hide in the corner. These days, established businesses are being forced to remake themselves continually in response to new challenges and threats from startups, corporate mashups and an accelerating technology curve, along with increasingly sophisticated demands from customers, business partners and even internal users.

“It is a reality of business today that supplier relationships, logistics networks, product and service design and customer service all survives in a state of permanent flux. Any path to sustainable competitive advantage will require a high degree of operational adaptability. Business functions, processes, organizations, supplier relationships and technology need to be seen as building blocks that can be reconfigured as needed to address changing competitive landscape.” [1]

But the problem that first needs to be addressed in order to ensure business adaptability and speed is “Big Code” legacy systems.

Big Code and The Composable Enterprise

Big Code is a system (or set of systems) that are sufficiently closed to outside interaction or inter-program accessibility primarily due to age. Essentially, any system that is simply too big to fail, retire, enhance, replace, maintain, support or even understand. The “antidote” to Big Code is the Composable Enterprise.

The Composable Enterprise is a cloud architecture pattern that builds on dozens of smaller cloud architecture sub-patterns, where large systems are built in a matrix of loosely connected, distributed systems — each with its own set of APIs or web services that govern the behavior of a small part of the business landscape. Individually, each component adheres to a set of specific business rules for anything as granular as a particular transaction type — e.g.,“Transfers from Internal Accounts to External Accounts,” to something as coarse as “Deposits.”

The goal is to build parts that are individually scalable, individually upgradeable and individually maintainable so that when the business decides to build a mobile application that allows customers to view the history of all their internal to external transfers over the last 12 months, the efforts around modification and testing are limited to that module. If more customers than expected decide to take advantage of this new feature and utilization spikes, that module can replicate itself to handle the increased traffic and automatically scale down when the spike abates. Conversely, if the business decides that feature is a bust or wants to spin it off to a different organization, that module can simply be eliminated or moved to another system. This allows the overall system to ebb and flow, always matching the business model of the day.

Now, component-based architectures are nothing new. This idea was discussed in client/server days (probably earlier) and was one of the promises of object-oriented languages. But now it is now possible to distribute processing, data and queries across wide areas and specialized systems with the promise of acceptable response times, “always on” guarantees and easily built compatible interfaces. In other words, in the cloud.

So the cloud makes component-based architectures possible, but what makes the Composable Enterprise a reality is the container.

The Container

You can visualize a container as a small, portable, virtual box that typically runs one main process. That one main process can be a website, a queue, an API, or anything that needs to receive and send data. If the process of that container needs to run faster, you can make the container bigger (more disk space, more processor allocation, more memory — aka vertical scaling), or, in more of a Composable Enterprise spirit, you can launch an identical container comprising a clone of that process that helps consume the workload (aka horizontal scaling).

Containers have been around for a few years now, most notably Heroku, Amazon AWS’ Elastic Beanstalk and Cloud Foundry, but the biggest story of 2014 for containers is going to be Docker.

Docker, the Enterprise Container System

In cloud vernacular, a container is used in Platform-as-a-Service (PaaS) environments and can be used to build Software-as-a-Service (SaaS) applications, APIs or just about any type of app you want. One of the things that makes Docker different is that it allows anyone, from an individual to an enterprise, to build cloud applications on anything from a Raspberry Pi or a laptop, to full blown corporate environments. This means you can have the complete autonomy and scalability of a fully realized cloud platform, right in your own enterprise data center.

Also, with Heroku, Elastic Beanstalk or Cloud Foundry — what can be put in a container is somewhat limited to custom applications written in a handful of supported languages. But with Docker, just about any type of application can be made into a container. This includes databases and queuing systems, which means that essentially any component in your environment can be placed in a container, thus useful in building part of your Composable Enterprise.

A side effect of building enterprise applications using Docker is being able to easily and cheaply have multiple environments for managing the full development lifecycle and testing scalability for rapid deployment to remote branch offices. Docker truly is a self-contained operating environment on a jump drive.

Required Skill Sets

The technologies discussed here are not trivial, but neither are they so far afield of your staff’s existing knowledge that you would need to hire a specialized team. However, there are a few skill sets required that you might not currently have:

An architect that understands cloud applications. How to design them, how to build them, and how to scale them horizontally.
If you want to run a container-based operation in your own data center, you will need a good VM platform on which your company runs. These are pretty much commonplace now so if you don’t have one, you should seriously consider getting one. Or you can run your business in the cloud, which is perfectly OK, too.

And that’s probably it. Once you design the system, the architect leads the charge in whatever platform of choice you currently use, although now would be a good time to re-evaluate your core technology stack. If you choose to stick with your platform, your staff will just need to understand how to build and test smaller, more self-contained but interoperable blocks of functionality.

Summary

By itself, neither Docker nor any of the other aforementioned container systems will transform your enterprise. Your architects will need to rethink their approach to building systems as copious amounts of queues and a solid API plan need to be included in order fully realize the Composable Enterprise vision.

But holding on to the systems that were designed for your pre–2006 business model is as advisable as holding on to the pre–2006 business model itself. The world is changing, as are the demands of that new world.

When you build your next system, give some thought to the type of bricks that will make up the applications. Will they be made of Lego blocks for building a modular structure that can be re-arranged as necessary, or will they be made of limestone like the Great Pyramids so they can stand the test time — whether you want them to or not?

References

More information about what is contained in this article can be found by following the links below.

Composable Enterprise

Containers

Originally published at centricconsulting.com on January 29, 2014.