Containers without Compromise

Containers, containers, containers!

The IT industry is fascinated with container technology. It has the potential to unify application development and operations teams, as well as provide a consistent application packaging element which can be the foundation for Hybrid Cloud and application mobility.

While the core container technologies (c-groups, namespaces, etc.) have been in the Linux kernel for more than a decade, containers needed the simplicity of the docker project in 2013 to spark widespread adoption by developers.

But as we all know, success in IT comes when powerful application technology can be operated consistently, securely and at scale.

Containers for the Developers Experience

Developers have quite a bit on their plates. They must know the nuances of their favorite languages and frameworks. They have to think about databases, application security, and scalability. And of course, they have to be able to translate business requirements into usable technology that can be maintained for many years.

While containers can be a powerful tool to help simplify the setup of a consistent laptop environment, not every developer wants to be burdened with learning the nuances and syntax of building a layered dockerfile. They may want their Continuous Integration (CI) system to deal with that step after code has been updated and tested, or just push code to their application platform and allow technology such as s2i (source-to-image) to natively build the containers. However your developers want to push their applications into test or production, as code or as containers, the underlying platform should be able to handle it without forcing developers to change their behaviors and processes.

Containers for the Operators Experience

While containers can deliver a simplified packaging experience for developers, they create a large number of requirements for the operations team. Packaging the application is just the tip of the iceberg.

Operations teams must manage several critical areas:

• Selecting the underlying cloud environment.
• Managing the Linux OS on the cloud platform.
• Managing Networking, Storage, Monitoring, and Logging for the Containers.
• Managing the Container Registry and associated Container Security (Scanning, Signing).
• Operating the Container Orchestration and Scheduling system.
• Integrating with CI/CD systems
• Integrating with Middleware, New Applications and Existing Applications.

Operations teams are being asked to deliver all of these capabilities in a seamless, self-service model to their application development teams, so the developers can stay focused on creating business differentiation and agility.

Avoiding Container Compromises

The choices for developers are fairly simple. Select a language or framework that best fits your applications needs and develop your applications. Whether they decide to natively push code into production or package that application as a container, the choice becomes a matter of personal preference, with their focus being on improving code velocity and code quality.

But the platform level choices for operations are more complicated. The market is crowded with new possibilities, and operations teams are looking for options that will give them flexibility and stability for many years to come. With all of these choices, operators should be cautious not to make several common compromises that will likely impact their ability to make their application developers success in the long-run.

1. Avoid platforms that discount the market momentum of developers using containers, or that impose limitations on containers that impact performance, security, portability or registry usage. Containers should be a 1st-class citizen of any platform.
2. Avoid platforms that mandate DevOps operational models that your organization may not be prepared to use in your current environment. Most developers do not want to be forced to manage day-to-day orchestration, networking, storage and security for their applications.
3. Avoid platforms that mandate unexpected, unnecessary or unsupported upgrade cycles that may leave your organization unprepared, or not align to the priorities of your business calendar.
4. Unless your organization is a startup, with no existing application portfolio, avoid platforms that restrict the languages and frameworks that can be used, or are overly opinionated about how applications must be deployed. This is extremely important when integrating with stateful applications (e.g. persistent data) and when migrating existing applications to the platform.
5. Strongly consider the size and velocity of the open source communities developing the platform you choose (Kubernetes/OpenShift, Docker Swarm, Cloud Foundry).

Containers are a Multi-Functional Choice

It is important to remember that a focus on improving developer productivity is a business decision that will impact many functional areas. If done correctly, the right combination of container packaging and container platform can deliver very significant business results, in a relatively short period of time.

Containers are a technology that will continue to innovate and evolve over the next few years, so it is important to not only consider the initial impact they will have for new application development, but also the longer-term value they can deliver for a broad set of applications in your portfolio.