Fresh off the heels of DockerCon and the announcement of Docker Enterprise 3.0, an end-to-end and dev-to-cloud container platform, I wanted to share some thoughts on what we mean when we say “complete container platform”.
Choice and Flexibility
A complete solution has to meet the needs of different kinds of applications and users – not just cloud native projects but legacy and brownfield applications on both Linux and Windows, too. At a high level, one of the goals of modernization – the leading reason organizations are adopting container platforms – is to rid ourselves of technical debt. Organizations want the freedom to create their apps based on the “right” stack and running in the “right” place, even though what’s “right” may vary from app to app. So the container platform running those applications should be flexible and open to support those needs, rather than rigidly tying application teams to a single OS or virtualization and cloud model.
To deliver high velocity innovation your developers are a key constituent for the container platform. That means the container platform should extend to their environment, so that developers are building and testing on the same APIs that will be used in production environments.
Your platform of choice should have tools that integrate into your developers’ preferred workflow, rather than forcing a new or different tool or completely new workflow on them that only works for one deployment pattern. Developers are hired for their creative ability to solve problems with code so adopting a platform that requires your teams to abandon their intuition and prior knowledge in favor of tools that only work with one prescriptive methodology not only slows down innovation, it also increases the risk of developers going outside the IT-approved processes to get the job done.
Operations teams also want to run a platform that enables applications to be deployed faster. That means making complex tasks simpler from day one with the assurance that the platform will work as expected, while still allowing them to grow their skills over time. The number true Kubernetes experts is relatively small, so if your platform of choice requires admins and operators to know Kubernetes on day one, in addition to learning the ins and outs of the container platform itself, you’re easily looking at 12 months or more of training, services, and proof of concept trials and errors before your container platform is ready for its first “real” workload.
In addition, Kubernetes is a trusted orchestrator and the Docker Engine, built on the CNCF-graduated containerd project, is a trusted and widely used container runtime. Your container platform should be built on these fundamental components because this will give you the most flexibility in the future. Docker Enterprise and all the major public clouds use Kubernetes and the Docker engine (in some cases containerd) because they are open and mature. If your container platform vendor says they’ve built their own projects which are “mostly compatible” with one or both of these then you might want to take note.
Operations teams are also interested in stability. Container platforms will get frequent updates but that does not mean you should be required to rip and replace your container platform every two years, and along with it all the skills, scripts, and other tooling your operations teams built up around the platform over time. When we added Kubernetes in Docker Enterprise 2.0 it was a major upgrade, but we made that upgrade as simple as possible, including continuing to provide and develop Docker Swarm. If you are evaluating container platforms, look at their history. It’s a relatively new market. If you see three major platform architecture redesigns which all forced a major operations shift, you might be in for a bumpy ride in the future.
Last, but absolutely not least, security has to be built-in at all layers of the platform. With the push for more frequent and faster software releases, security has to be part of both the developer’s experience and the operator’s experience. But security cannot be so restrictive or obtrusive that nobody wants to use the platform. You should have guardrails that help developers get started quickly from known good foundations, shifting left in your security process instead of finding out later that something is broken. And your platform should give you visibility into every application you ship: Windows or Linux, Edge or data centers. Security must be a fundamental building block of your container platform and that includes security for your running applications, too.
We were proud that Docker was named a Leader in The Forrester New Wave™ for Enterprise Container Platform Software Suites in Q4 2018. We believe that our 3.0 platform adds even greater capabilities in a non-disruptive fashion and is the only end-to-end platform for building, sharing and running container-based applications, from the developer’s desktop to the cloud and managing the entire application lifecycle at every stage without dependencies based on a particular OS version, virtualization platform, or public cloud stack.
For more information:
- Learn more about Docker Enterprise 3.0
- Download The Forrester New Wave™ for Enterprise Container Platform Software Suites
0 thoughts on "What’s in a Container Platform?"