carloscastilla - Fotolia
Compare 3 distinct types of Kubernetes platforms
There are three types of Kubernetes deployment options, each with its own benefits and challenges. Use this in-depth comparison to choose the best fit for your organization.
Kubernetes has become the de facto management platform for container and cloud application deployments. However, market convergence around Kubernetes has led to a wide variety of options to run and operate the tool -- which makes choosing the right one complex.
Let's explore the benefits and risks of three types of Kubernetes platforms: the native open source tool, managed cloud services and integrated ecosystems. We'll examine the technical features each option offers, the extent to which it supports enterprise container and cloud environments, and ease of use.
Native Kubernetes
Kubernetes is an open source package maintained by the Cloud Native Computing Foundation, which offers documentation, case studies and a certified, stable version of the Kubernetes source code. Enterprises that use this source code will always have the latest Kubernetes version and the flexibility to customize the software to meet their specific needs. By creating their own builds from the source code, IT teams can fine-tune their Kubernetes deployment and freely select ancillary components, including those for virtual networking, load balancing, monitoring, service discovery and registration and service mesh to suit their container and cloud deployment.
The downside is that once an IT organization decides to build its own tools from source code, it's likely to be committed to that approach for all tools. To reduce this risk, ensure your organization's OS and other middleware are from standard distributions -- but be prepared to build what you need from source code as the foundation.
The use of native Kubernetes also requires deep technical knowledge of open source software in source-code form, and, as a result, is far too challenging for some enterprises. As the Kubernetes landscape continues to expand and more packages are drawn into it, building Kubernetes from source code will only become more difficult.
Bottom line: Native Kubernetes offers users the greatest selection of, and control over, cloud and container tools and features. This flexibility also means that pure open source Kubernetes has the best chance -- compared to the other two types of Kubernetes platforms detailed below -- to meet its users' future requirements. However, this comes at a high price: The learning curve and ongoing effort required to support native Kubernetes is exceptionally high, making it an impractical option for most enterprises.
Cloud providers' managed Kubernetes services
In many ways, managed Kubernetes services from cloud providers are the opposite of the native, open source Kubernetes model. While the latter requires considerable technical skill to deploy and maintain, the former does the heavy lifting for you. If you want Kubernetes with as little technical effort as possible, this is the path.
Managed Kubernetes services are available from all the major cloud providers: Amazon, Google, IBM, Microsoft and Oracle. These services make Kubernetes more accessible to IT organizations, as they eliminate the need to configure and maintain the underlying infrastructure. The cloud provider typically manages the Kubernetes control plane, including provisioning, version updates, load balancing, scaling, patching and monitoring. Technical support for these services is also strong.
Competition in the managed Kubernetes market
In comparisons of managed Kubernetes services from major cloud providers, many technical experts consider Google's Kubernetes Engine to be the most complete, up-to-date and easiest to integrate with hybrid cloud deployments.
Amazon Elastic Kubernetes Service and Microsoft Azure Kubernetes Service are both strong in hybrid cloud, while IBM advances its own managed Kubernetes service through the integration of Red Hat OpenShift elements. Despite some key differences, cloud providers' managed Kubernetes offerings should see greater feature parity by the end of 2020.
However, because these services are specific to each provider, they often pose vendor lock-in risks. Cloud providers integrate these managed services with additional tools on their platforms, and as enterprises adopt those other tools and features, their dependence on that one provider grows. Organizations that have, or plan to have, container deployments within their own data center for hybrid cloud, or to deploy containers as part of a multi-cloud model, could find these services problematic.
Bottom line: Cloud-hosted Kubernetes services are the best choice for ease of adoption and ongoing technical support. On the downside, they offer limited support for cloud and container tools that reside outside their respective platform and won't offer enterprises everything they need to build container applications for their own data centers or in a multi-cloud deployment.
Integrated Kubernetes ecosystems
Our third category -- Kubernetes ecosystems -- is the leading edge of Kubernetes today. The foundation of this category is the belief that Kubernetes is a fundamental component of a broader market trend toward cloud application development. As such, these ecosystems offer core Kubernetes functionality, and integrate that functionality with other features and tools -- a formidable task even for enterprises with strong cloud and IT skills.
These Kubernetes platforms include Red Hat OpenShift; VMware Cloud Foundry, Tanzu and Enterprise Pivotal Container Service; IBM Kabanero; and Google Anthos. Some suppliers of Kubernetes ecosystems offer multiple Kubernetes-centered products designed to fit specific enterprise goals -- VMware, in particular, through a combination of acquisition and evolution, has several products that could be called Kubernetes ecosystems. Over time, it's likely that these will converge to avoid buyer confusion and provide users with capabilities beyond the boundaries of specific products.
Some vendors have a clear vision of how the Kubernetes ecosystem will develop, and an enterprise that buys into that vision will facilitate integration and gain a complete toolkit to build cloud-native applications and modernize traditional applications for the cloud. These ecosystem tools aren't as simple to deploy and use as a cloud provider's managed Kubernetes service, but they're the most powerful option for Kubernetes available at time of publication.
Generally, a Kubernetes ecosystem platform includes basic tools for container deployment and operation in a hybrid and multi-cloud environment. This includes everything in a cloud provider's managed Kubernetes services, plus features for federation or common policy control of multiple Kubernetes systems and service-mesh connectivity among application components. Competition in this market is new -- but fierce already -- as vendors rapidly expand their capabilities.
The Kubernetes ecosystem model is the future for any enterprise that expects to deploy hybrid cloud applications, develop cloud-native applications or adopt multi-cloud applications. It's the most feature-rich of all the methods to adopt Kubernetes, and the one most likely to mirror the rapid evolution of containers and cloud-native development. It's also a single-vendor strategy: The key components of a Kubernetes ecosystem are all open source, but the actual integrations, down to the software versions, are quite specific to the provider.
Bottom line: For Kubernetes features, Kubernetes ecosystem offerings are almost as up-to-the-minute as a Kubernetes-centered toolkit from source code. Vendors augment their offerings almost daily, and competition will force them to continue to do so. These Kubernetes ecosystems are also likely to align with future container and cloud requirements in the enterprise. For ease of use, learning curve and ongoing support, the ecosystem approach is a solid choice -- but like managed Kubernetes services, one that comes with lock-in risks.
Which of these Kubernetes platforms is right for your organization?
Generally speaking, the native Kubernetes approach is best for enterprises with a major data center commitment to containers and a desire to do their own cloud and container software development, rather than use third-party applications. They should have strong in-house open source skills; if an organization doesn't maintain its own Linux environment and middleware tools, it probably shouldn't consider this option.
Managed Kubernetes services are best for users who plan to mostly deploy containers in the cloud, and can commit to a cloud provider long term. They can also be a good choice for enterprises that require modern front-end elements for cloud-hosted applications to speed up their development. If cloud provider lock-in is a concern, however, avoid this option.
Most enterprises will find Kubernetes ecosystems to be the best approach. As container deployment evolves from simple hosting to cloud-native, microservices-based, componentized applications, it's critical to integrate component deployment with service discovery and inter-process communications -- a bewildering task, as all the pieces of the puzzle rapidly evolve. The downside of this approach is that these Kubernetes platforms marry the container management tool with specific discovery and communications services, so, again, enterprises need to pick a supplier for the long run.