Many enterprises are using container technology with existing applications as well as new ones. Containers for web servers and databases are extremely popular, as are containers for complex operating environments such as Java-based applications. Any application that has multiple tiers is a candidate for container technology to both help maintenance and scalability. Some software vendors are also delivering their applications in containers as an alternative to hardware or virtual appliances.
A Closer Look at Orchestration Options for Containers
If a business had only one server running a single container, it wouldn’t have much use for container management. But, as with virtual machines, managing containers is a critical task for those past the baby steps.
Container management tools have a long list of tasks they manage, including making sure that containers are actually up and running (and handling failures), spreading the containers around the hosts for load balancing and performance management, linking containers to persistent storage such as storage area networks and databases, and handling sensitive information such as passwords and private keys.
The best-known container management tool is Kubernetes. Google, one of the leaders in the shift to containerized applications, developed Kubernetes and released it to the open-source world in 2014. Because it is based on open-source code, most organizations starting out with containers start with Kubernetes in one form or another. Each of the major public cloud providers also has their own version of Kubernetes: Google Kubernetes Engine (GKE), Amazon Elastic Kubernetes Service (EKS) and Azure Kubernetes Service (AKS).
However, Kubernetes isn’t the only game in town for container management. For example, Docker has its own container management tool, Docker Swarm, as does the Apache Software Foundation with Apache Mesos. Even so, the popularity of the Kubernetes toolkit means that almost any container management system you select will be based on Kubernetes in some way.
That’s true of VMware’s Tanzu Kubernetes Grid Integrated Edition, as well as of IBM’s Red Hat OpenShift and HPE’s Ezmeral.
Is Open Source Enough for a Business?
If Kubernetes is open source, should a business run anything else? It depends. There are really two reasons why you might not immediately start with Kubernetes: a lack of internal skills, or anticipated complexity.
Let’s start with skill sets. Kubernetes and containers are part of a very fast-moving ecosystem of new products and ideas in software development, and while there are some large open-source projects, there are lots other components that thrive in this ecosystem. The terminology and vocabulary are all new — and foreign to many IT managers. At the same time, the same DevOps model that puts developers in the driver’s seat when it comes to the deployment and provisioning of applications also means there are many more voices at the table when it comes to choosing toolsets and operations models. The result is that it’s seldom enough to say, “OK, let’s install Kubernetes and some Docker engines.” Instead, you’ll discover a whole world of bits and pieces that developers are asking for in order to optimize their workflow.
IT groups that don’t have direct experience with integrating all of these tools together may find it easier to lean on a commercial product with full support rather than dive into the world of open-source container management with a difficult learning curve and a fast pace of upgrades and updates.
The other reason to consider commercial container management is that complex enterprises require a full application deployment solution, and Kubernetes is just one part. It doesn’t do anything, for example, when it comes to actually building applications for deployment. It doesn’t handle the management of the underlying Docker engines. It doesn’t have an overall monitoring and alerting system. It doesn’t help secure the communications between different containers.
While it may be possible to assemble pieces from open-source projects and commercial products into a larger solution, starting with a supported commercial product that meets the needs of a complex enterprise from day one can ensure that the focus of the development and operations teams is on applications, and not on the mechanics of keeping the infrastructure running.
