The growing importance of Kubernetes in cloud native app development means that you now have many options for how to implement your orchestration platform. You can start with a standard Kubernetes environment or choose a cloud-hosted managed instance with offerings of Google, Amazon and Microsoft. Alternatively, you can choose from one of the growing managed Kubernetes platforms.
Red Hat OpenShift is perhaps the best known of these platforms, offering a suite of services that scale from edge deployments to working on virtual infrastructures running in public clouds. By simplifying the Kubernetes experience, it is more likely to be deployed in your own data center as part of a hybrid cloud strategy. There is support for OpenShift from major cloud providers, with local integration with virtual infrastructure tools like vSphere, Red Hat’s OpenStack tools, or directly on bare metal.
Also, don’t confuse Red Hat OpenShift with Red Hat OpenStack. The first is your managed Kubernetes; the second is its private cloud platform, often used to host OpenShift.
Like everything Kubernetes managed services, it can be difficult to determine what Red Hat brings to the table with OpenShift. After all, if you’re running certified Kubernetes, your containers and orchestration should be running no matter where you got them. That underlying neutrality is key to the success of Kubernetes, so any managed Kubernetes distribution must offer more than deploying your own Kubernetes environment.
With over 70 certified Kubernetes distributions, finding points of differentiation between them can be difficult. They all support the same set of APIs; they all work with the same container standards. What is perhaps most important, especially for managed Kubernetes environments like OpenShift, is the philosophy behind the distribution, as it affects how and where you use it. Some are designed for the edge, some for the cloud, and some for hybrid environments.
Managed Kubernetes for Platform Operations
A key feature that all Kubernetes distributions take advantage of is how it adds a new layer of abstraction to distributed application development and operations. Tools like Kubernetes allow us to break DevOps practices into three parts. Infrastructure operations manage servers and networks, the physical systems that host our virtual environments. Application operations teams manage the containers and code we deploy wherever it’s needed: in the cloud, on-premises, and at the edge. Between the two are platform operations, virtual infrastructure management, and container orchestration.
OpenShift is best thought of as a platform operations tool, wrapping management tools around a certified Kubernetes instance. Instead of having to configure multiple tools using multiple interfaces, they all come together in one place. So you don’t need to, say, use Calico to add network security sidecars to your Kubernetes infrastructure with your own management tools; instead, you’ll configure the OpenShift security providers through the same portal as the rest of your applications.
Red Hat calls it its “distributed application platform,” using Kubernetes as its kernel. It’s a philosophical approach that goes back to the early days of Kubernetes when it wasn’t the dominant platform and where competitors like Mesos described themselves as a “data center operating system.” There is certainly value in thinking about Kubernetes in this way, as it helps make sense of it from a platform operations standpoint, treating it as a way to simplify the concepts that underpin large-scale distributed application environments.
That model fits nicely with some of the prevailing development around Kubernetes APIs, where it’s seen as a way to manage deployments of packaged containers and WebAssembly applications. Offering a managed Kubernetes environment that runs as if it were a locally hosted Platform-as-a-Service environment removes much of the Kubernetes administration overhead and still supports Kubernetes APIs.
By offering its own management console, OpenShift manages to get around one of the most annoying aspects of Kubernetes, configuring web-based tools to work with the platform and then handling access to the service. Having a single user interface makes it easy to train operations and application development teams, with the same user interface managing nodes across your network, from edge to cloud.
Simplification comes with its own drawbacks; While OpenShift supports most of the core Kubernetes features, it does not support the latest services or key packaging and deployment tools. You will need to consider how to translate pure Kubernetes operations to OpenShift, although support for tools like Ansible and direct integration with CI/CD platforms can reduce friction considerably.
While Kubernetes will always have support for the latest technologies, being able to turn to CI/CD allows you to quickly integrate OpenShift into your build pipelines. This way, you can quickly implement cloud-native best practices, building and testing containers with tools like Jenkins or Tekton, before deploying OpenShift from a private container repository.
Red Hat now supports the Common Runtime Interface and OCI containers through CRI-O, as well as Docker, giving you flexibility in how you build your containers. This allows developers to work with a basic Kubernetes installation on workstations while deploying in an OpenShift environment. Since OpenShift is a certified Kubernetes environment, you can install the same base version across developer toolchains and keep licensing costs to a minimum.
There’s another aspect of OpenShift that’s often forgotten: it’s a single stack from host operating system to application, based on Red Hat’s Linux and DevOps tools. This approach may not be as flexible as building your own platform, picking and mixing from multiple options, but it does provide a single support contact for the entire stack. Support remains a key need for more enterprise deployments, and Red Hat’s expertise in supporting open source and free software can help integrate the OpenShift stack with the rest of your infrastructure.
It’s an approach that allows you to take advantage of built-in security tools. When protecting Kubernetes requires the use of a combination of technologies, from the service mesh to managing access controls through kubectl, OpenShift uses Red Hat’s proprietary security tools to manage key Kubernetes features, as well as offering additional real-time analysis to add dynamic threat detection. The same feature also adds vulnerability management and helps you understand the risks associated with your applications.
Red Hat provides automated installation and upgrades for the most common private and public clouds, allowing you to upgrade on your own schedule and without disrupting operations. This process is perhaps one of the biggest differences between OpenShift and the standard Kubernetes environment, as it provides a runbook for updates and uses it to prevent disruption. If you’re running a cluster of OpenShift servers, you’ll be able to upgrade while applications continue to run, with OpenShift orchestration tools moving nodes and containers around as needed.
When it comes to locally managed Kubernetes, OpenShift is perhaps better compared to Microsoft Azure Arc tools, which bring Azure managed Kubernetes to on-premises, using the Azure portal as a management tool, or VMware’s Tanzu. All of them are based on certified Kubernetes, adding their own access control and management tools.
OpenShift is more of a sign of the importance of Kubernetes for enterprise application development than anything else. Most organizations have a relatively limited operating environment and often don’t have the resources to build a full Kubernetes management team. Having a single dashboard for all Kubernetes operations reduces risk, leveraging automation and reducing the need for training.
if you want to use Kubernetes to bring cloud-native development to your data center, a managed Kubernetes like Red Hat OpenShift is by far the obvious choice. If you’re in the VMware ecosystem, you’ll likely use Tanzu, on Microsoft’s Azure Stack and Azure Arc, while OpenShift will appeal to Linux and IBM users. The fact that they are all based on certified Kubernetes makes it easier to adopt, knowing that you should be able to use it alongside cloud platforms and with the same containers and configurations.