This post is part of a series – 14 Business and Technology Trends to Look for in 2014.
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.
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.” 
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.
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).
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.
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?
More information about what is contained in this article can be found by following the links below.
- The Composable Enterprise 
- Armed with APIs, developers will drive the com posable enterprise
- Think Big: Composable Enterprises and the Need for Open Architecture
- Ben Kepes on Composable Enterprise, Multi-Cloud and Cloud IaaS Strategies 
- Is the Composable Enterprise About Business or Technology? Yes.
- Three Characteristics of Successful Composable Enterprises
William Klos is a Senior Architect and Centric’s National Cloud Services Lead. William’s career has spanned many aspects of computing and at times has architected solutions from the perspective of data, networking, enterprise, and security – but is primarily an application architect. Most recent experience has William providing solutions around Mobility, Cloud, and Big Data architectures as well as API design and development.
William Klos has been involved with technology since abandoning his desire to be an architect and stumbling into his first computer science class in 1985. Since then he has typically pushed companies into “what’s next.” Contact William to learn more.
Other Business and Technology Trends of 2014:
- Beginnings of a Gigantic Innovation Cycle
- The Growth of DIY Healthcare
- Data is the New Currency – Mining for Gold in the Internet of Things
- The Emergence of the Professional DIY Data Scientist
- Marketing and IT Sitting in the Tree
- Cloud Breaks Out of Infrastructure Groups and Into Strategic Imperatives
- Financial Companies Prepare to Advise Multi-Generational Homes
- The Re-Emerging Importance of Tech Careers
- Responsive Web Design Falls Victim to the Hype Cycle
- Data Scientist Sightings Will (Mostly) Be Proven a Hoax
- Non-Techies Grasp the Cloud
- Info Synthesis and Collaboration Create a Recipe for 2014 Breakthroughs
- Sensors Invade – Big Data Goes Mainstream