What’s in a Container Platform?
Choice and FlexibilityA 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.
High-Velocity InnovationTo 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.