Containers in the Enterprise – Not so fast

Containerisation of workloads and the associated orchestration technologies have been around for quite a while in ‘big tech’ (Google, etc), but they have only recently become a hot topic for enterprises.

For those new to containers, it is best to think of them as a sort of light-weight virtualisation technology that allows you to package an application and its dependencies (minus the whole underlying OS as is the case with traditional virtualisation) into an image and deploy that via an orchestration layer.

Containers are brilliant for some scenarios:

• Bespoke applications: If you’re building your own application using modern DevOps tool chains, containers provide a tidy way for you to package up your application for deployment. In this scenario, you’re already wearing the cost of software engineers and a DevOps development practice and these skills naturally lend themselves to dealing with the complexity of the containerisation tool chain.
• Scale: If you’re a huge tech behemoth that deploys hundreds of instances of the same thing to a farm of servers, then containers are a great choice. You can easily push the work related to understanding the dependencies and run state to the development team and they can hand this off to your operations or site reliability engineers in a simple and standardised fashion.

We use containers extensively at Codify. Our automation platform, which scales out across all our customers, runs tens of thousands of jobs per day. We have a lot of technology dependencies in our application stack using frameworks from Microsoft, third parties, NPM modules, and so on. It makes sense for us to containerise a platform like this because it is a very similar use case to those used by ‘big tech’ (and because we’re a specialised technology company with in house software engineers).

Enterprises are Different

You might be surprised, then, to find out that Codify almost always recommends that our customers stay away from containers.

That’s because our customers are typically SMCs or enterprise organisations where IT is a supporting activity, not their core business. These organisations have a whole series of different concerns. Typically, our customers (with a couple of exceptions):

1. Have a preference for chasing the best value on modern software architectures and prefer software-as-a-service wherever possible. If you’re preferencing SaaS as more valuable than PaaS, and PaaS as more valuable than IaaS, then the last thing on your mind is writing custom software.
2. Deploy commercial-off-the-shelf applications almost exclusively.
3. Do not have internal software engineering capabilities; if they do, they are typically focused on building integrations between commercial-off-the-shelf software packages.

Even large enterprise applications that typically scale horizontally have a low number of servers in the scheme of things, which may make containerisation a poor choice.

Containers without DevOps is a Recipe for Ops and Security Disasters

In our view, the most important drawback for containers in the enterprise level is the lack of operationalised support. The moment you package a container and include a dependency, then the management of the operational and security lifecycle of that dependency are made a function of packaging and deployment, rather than operational support.

Imagine you’re an enterprise with a dozen small departmental applications. Consider the following two scenarios:

1. An nginx stack running in a PaaS or IaaS environment, where you deploy your applications via xcopy or a modern DevOps process
2. A dozen different containers built, one for each application

You arrive at work on Monday to find that a log4j type vulnerability affects nginx and is being exploited in the wild. Time is of the essence, and you need to secure your infrastructure.

In the first scenario, if you’re running a PaaS environment, you lean on Microsoft to ensure that they have a mitigation in place. If you’re running IaaS, your operations team downloads the latest patch for the relevant binaries and installs it on the server once without recourse to the development team.

In the second scenario, you’ll need to re-build 12 container images and deploy all 12 of those. This is manageable if you have a team in-house and slick, well-oiled DevOps processes, but enterprises rarely do.

Operational Immaturity

When ‘big tech’ style organisations use containers, they will typically have a heavily micro serviced architecture with clear lines of demarcation on what is volatile and what is not. We have been appalled to see our customers given containerised architectures from third parties where the DBMS is bundled with the containerised application.

What happens when you get a new release of the container? You have a backup and restore nightmare on your hands. In fact, one master data management solution that one of our customers deployed had this issue. The vendor’s statement on business continuity was that the entire container infrastructure needs to be stopped, backed up, and started again when needed – hardly living the cloud/scale dream. Containerisation can make it a challenge to make application consistent backups and to meet existing organisatlional RTO/RPO numbers.

What is Codify’s Advice?

Generally speaking, we don’t believe that the designed use case for containers aligns with the workloads typically encountered in enterprises. In our view, it’s better to:

1. Always follow the SaaS over PaaS over IaaS value chain.
2. If you need to deploy a simple web app, just drop it in Azure App Service. If it has a technical issue that means App Service isn’t suitable, then drop it in IaaS.
3. If you’re deploying commercial-off-the-shelf software, follow the vendor’s deployment advice (but make sure you have a spirited discussion with them on supporting Azure SQL Database, etc – they’re often lazy and want to put everything on IaaS without thinking).
4. If you have a sophisticated internal software development capability and use a lot of third-party dependencies, then look at containers.
5. If you need to fan out hundreds of instances of an application and have a good handle on data volatility, then look at containers.

I’d love to know what you think. How are you using containers in your SMC/enterprise scale business? Reach out and let me know – david@codify.com.