It’s almost a trick question, but Red Hat’s managed Kubernetes platform does things a little differently.
The increasing importance of Kubernetes in cloud native application development means you now have a lot of choices about how you deploy your orchestration platform. You can start with a standard Kubernetes environment or choose a cloud-hosted managed instance with offerings from Google, Amazon, and Microsoft. Alternatively, you can choose from one of a growing number of managed Kubernetes platforms.
Red Hat’s OpenShift is perhaps the best-known of these platforms, offering a set of services that scale from edge deployments to working in virtual infrastructures running on public clouds. By simplifying the Kubernetes experience, it’s most likely to be deployed in your own data center as part of a hybrid cloud strategy. There’s support for OpenShift from the main cloud vendors, with on-premises integration with virtual infrastructure tooling like vSphere, Red Hat’s OpenStack tooling, or directly on bare metal.
As an aside, don’t confuse Red Hat OpenShift with Red Hat OpenStack. The first is its managed Kubernetes; the second is its private cloud platform, often used to host OpenShift.
Like all managed Kubernetes services, it can be hard to determine what Red Hat brings to the table with OpenShift. After all, if you’re running a certified Kubernetes, your containers and orchestration should run no matter where you sourced it. That underlying neutrality is key to the success of Kubernetes, so any managed Kubernetes distribution needs to offer more than rolling your own Kubernetes environment.
With over 70 certified Kubernetes distributions, finding points of differentiation between them can be hard. They all support the same set of APIs; they all work with the same container standards. What’s perhaps most important, especially for managed Kubernetes environments like OpenShift, is the philosophy behind the distribution, as it affects how you and where you use it. Some are designed for edge, some for cloud, and some for hybrid environments.
Managed Kubernetes for Platform Operations
One key feature that all Kubernetes distributions take advantage of is how it adds a new layer of abstraction to distributed application development and operations. Tooling like Kubernetes allows us to split out DevOps practices into three parts. Infrastructure ops handle servers and networks, the physical systems that host our virtual environments. Application ops teams manage the containers and code that we deploy where needed: in the cloud, on-premises, and at the edge. Between the two sits platform ops, managing virtual infrastructures and container orchestration.
OpenShift is best thought of as a platform ops tool, wrapping management tooling around a certified Kubernetes instance. Instead of having to configure multiple tools using multiple interfaces, they’re all brought into one place. So, you don’t need to, say, use Calico to add network security sidecars to your Kubernetes infrastructure with their own management tooling; instead, you’ll configure OpenShift’s security providers through the same portal as the rest of your applications.
Red Hat calls it its “distributed application platform,” using Kubernetes as a 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 were describing themselves as a “data center operating system”. There’s certainly value in thinking about Kubernetes this way, as it helps make sense of it from a platform ops point of view, treating it as a way of simplifying the concepts that underpin large-scale distributed application environments.
That model fits nicely with some of the prevailing developments around the Kubernetes APIs, where it’s seen as a way of managing the deployments of packaged containers and WebAssembly applications. Offering a managed Kubernetes environment that runs as if it was a locally hosted platform-as-a-service environment removes much of the Kubernetes management overhead while still supporting the Kubernetes APIs.
Simplified Management
By offering its own management console, OpenShift manages to get around one of the more annoying aspects of Kubernetes, configuring web-based tooling to work with the platform and then handling access to the service. Having a single user interface makes it easier to train operations and application development teams, with the same UI managing nodes across your network, from edge to cloud.
Simplification comes with its own downsides; while OpenShift supports most core Kubernetes features, it doesn’t support the latest services or key packaging and deployment tools. You will need to consider how to translate pure-Kubernetes operations to OpenShift, though 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 fall back on CI/CD allows you to quickly integrate OpenShift into build pipelines. This way, you can quickly implement cloud native best practices, building and testing containers using tools like Jenkins or Tekton, before deploying to OpenShift from a private container repository.
Red Hat now supports Common Runtime Interface and OCI containers through CRI-O, as well as Docker, giving you flexibility for how you build your containers. This allows developers to work with a basic Kubernetes install on workstations while deploying to an OpenShift environment. As OpenShift is a certified Kubernetes environment, you can install the same base version in developer toolchains and keep your licensing costs to a minimum.
A Single Stack
There’s another aspect to OpenShift that’s often forgotten: it’s a single stack from host OS to application, building on Red Hat’s Linux and DevOps tooling. This approach may not be as flexible as rolling your own platform, picking and mixing from various options, but it does offer a single support contact for the entire stack. Support remains a key need for more enterprise deployments, and Red Hat’s experience in supporting open source and free software can help integrate OpenShift’s stack with the rest of your infrastructure.
It’s an approach that lets you benefit from built-in security tooling. Where securing Kubernetes requires using a mix of technologies, from service mesh to managing access controls through kubectl, OpenShift uses Red Hat’s own security tools to manage key Kubernetes features, as well offering additional real-time scanning to add dynamic threat detection. The same feature also adds vulnerability management and helps you understand risks associated with your applications.
Red Hat provides automated installation and upgrades for most common public and private clouds, allowing you to update on your own schedule and without disrupting operations. This process is perhaps one of the biggest differentiations between OpenShift and the standard Kubernetes environment, as it provides a runbook for updates and uses this to avoid disruption. If you’re running a cluster of OpenShift servers, you will be able to upgrade while applications continue to run, with OpenShift’s orchestration tools moving nodes and containers as required.
When it comes to managed on-premises Kubernetes OpenShift is perhaps best compared with Microsoft’s Azure Arc tooling, which brings Azure’s managed Kubernetes to on-premises, using the Azure Portal as a management tool, or VMware’s Tanzu. They are all based on certified Kubernetes, adding their own management tooling and access control.
OpenShift is more a sign of Kubernetes’ importance to enterprise application development than anything else. Most organizations have a relatively constrained operations environment and often don’t have the resources necessary to build out a complete Kubernetes management team. Having a single pane of glass for all Kubernetes operations reduces risk, taking advantage of automation and reducing the need for training.
If you want to use Kubernetes to bring cloud-native development into your data center, a managed Kubernetes like Red Hat OpenShift is by far the obvious choice. If you’re in the VMware ecosystem, then you’re likely to use Tanzu, in Microsoft’s Azure Stack and Azure Arc, while OpenShift will be attractive to Linux and IBM users. The fact that they all build 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.
Comments