Assess container hosting, management options based on these criteria

Identify essential container hosting tools

The container hosting software space has diminished, as attention focuses on orchestration and beyond. Today, almost all Kubernetes packages include basic container hosting software -- and that's the best way for enterprises to access it. Read the next section only if you don't plan to run Kubernetes.

Container hosting software. There are two container hosting software paths: one for users with typical application security needs, and one for those who require significantly more. For basic application security needs, organizations should plan for Docker unless they find a clear reason otherwise.

Stringent security was, at one time, the primary reason to pick a Docker alternative, specifically CoreOS' rkt, pronounced "rocket," the second-most-popular container software package. Red Hat, which purchased CoreOS (and later itself was purchased by IBM), has integrated CoreOS functionaltiy into its OpenShift architecture. However, rkt is now an archived project at the CNCF. For organizations that don't already use rkt, this is probably not a good time to start.

Plan to use Docker alone, with no external orchestration, if your company:

• is an SMB;
• has limited technical support personnel;
• has technical staff inexperienced with open source software; or
• will likely rely on third-party help to deploy containerized applications.

It's hard to set a statistical boundary on the Docker-only user, but single data centers with fewer than 50 servers, no more than a dozen applications, and more reliance on third-party applications than on internal software development probably don't need to go beyond Docker. If you think you need more functionality, such as cluster support, then you aren't a Docker user; you're a Kubernetes user.

Eventually, most Docker users look to use resource pools and public cloud. The transition to large-scale container use, including with hybrid cloud, multi-cloud and microservices, is easier when planned from the beginning. Look first at container orchestration software, which, in today's container market, means Kubernetes.

Container orchestration software. Virtually all container users will need more than container hosting, and should start their container management deliberations with orchestration. Orchestration was once the preferred process to deploy containers on clusters, and the industry has settled on Kubernetes for this mission. The scope of container orchestration has also expanded to include scalability features and support for other application operations lifecycle stages.

Kubernetes is an open source software tool designed to automate routine container application lifecycle processes. It offers special facilities to define pools of resources, known as clusters, which allow users to assign hosting resources by class. Clusters also help Kubernetes simplify hybrid and multi-cloud application hosting. Kubernetes is available from diverse sources, so review all options to see which one best fits your company's plans.

Docker and Kubernetes are the core of managed Kubernetes services from all the major cloud providers, and also the Kubernetes ecosystems available from Google, IBM and Red Hat, VMware and Cloud Foundry. All of these services bundle support with container software and orchestration, and the combination suits companies that are just starting with containers and fit the Docker or Docker-plus-Kubernetes profile for a container management system. VMware offers a Docker-only option with vSphere Integrated Containers, but unless the container deployment will remain static, a Docker-and-Kubernetes combination is the best option. Businesses that already use VMware or Red Hat should stay with their current vendors, and others should pick the tool with the most favorable license terms.

The basic model of a container product suite has expanded with additional tools that create a Kubernetes ecosystem. The additional products in these ecosystems extend beyond container management, and they're essential as container use expands outside data centers into hybrid and multi-cloud deployments, and eventually to an open microservices-based application model. A container user or prospect's position on this evolutionary path determines how it should select a container management software package.

Choose the right container management package

As discussed in the second article in this guide, buyers should select container tools based on their current and future container hosting and management needs.

Public cloud users. Companies that plan to use only public cloud services with no data center container hosting are typically SMBs with no data centers and no technical resources for in-house container support. In that case, plan on a managed Kubernetes service from a public cloud provider. Amazon, Google and Microsoft all provide container hosting and Kubernetes-based orchestration through managed Kubernetes services. The selection of a specific public cloud provider will likely be based on price considerations out of the scope of this guide.

Some users have a data center that runs only third-party applications, and they may use container-based applications in the public cloud to front-end or supplement their current application inventory. Companies in this category should still plan to use a managed Kubernetes service in the cloud, or consider a third-party provider to integrate cloud applications and current data center applications. Third-party application providers also may provide some guidance or professional services.

Companies that run in-house VMs or bare-metal servers and don't plan to migrate to containers, but want to add containers as a part of a cloud application front-end strategy, should consider a simple container system from a cloud provider.

Data center container users. Most current and prospective container users have one or more corporate data centers and an in-house technical staff to support container management software. They'll look to containerize applications using both public cloud and data center hosting resources, and the right path will depend on the nature and extent of their use of public cloud(s).

A small number of data center users has no public cloud needs or plans, although most of them will change their mind fairly quickly. Take a careful look at your company's future IT needs -- if there's any chance of at least limited public cloud use, do not take this path. Future container needs will eventually force selection of a Kubernetes ecosystem product, so it's best to plan for that from the start.

Limited hybrid cloud users. The majority of enterprises today are hybrid cloud prospects that run most of their applications in the data center, with some public cloud hosting. As long as there's a significant chance they'll need data center container hosting, this group of users should select a Kubernetes ecosystem that's strongly centered on the data center, but also supports public cloud Kubernetes hosting.

Prospects for limited hybrid cloud use must again be certain not to underestimate the role the cloud will play in their future. Not all Kubernetes ecosystems have equal capabilities in all areas -- in particular, some focus more on multi-cloud use. Broad use of public cloud resources greatly increases the likelihood that a company will eventually be a multi-cloud user, so pay more attention to multi-cloud features if your organization expects significant growth in cloud usage overall. Also, consider multi-cloud features to facilitate portability and prevent cloud provider lock-in.

Multi-cloud users. As multi-cloud use increases, companies are more likely to embark on a track that ends either in an on-premises-based Kubernetes ecosystem or a public cloud managed Kubernetes service that supports data center hosting. The latter option distinguishes this path from others. Generally, a company with significant container commitment in its data center applications should use on-premises-hosted Kubernetes. If a company has no plans to containerize most data center applications and expects to use multiple public clouds, consider a cloud provider's managed Kubernetes service.

Users with a complete microservices framework. The most extreme pathway to elect container deployment tools is a company that plans extensive use of microservices to rebuild applications in a more cloud-native form. These container prospects commit to the cloud at the application design level, and that means a Kubernetes ecosystem that likely involves both data center and multiple cloud providers as an elastic pool of resources. This class of user should expect to use service mesh technology for microservice communications, and consider serverless cloud services. Organizations that want to preserve the concept of a single elastic resource pool will require serverless support for the data center. Look for a Kubernetes ecosystem with all these features.