At the recently concluded Kubecon in Austin, TX, attended by over 4000 engineers, Kubernetes was front, left and center.
InfoQ caught up with Brian Gracely, director product strategy for Red Hat Openshift, about how Kubernetes has helped shape the product direction and how it's relevant to developers and architects.
InfoQ: Attendance at Kubecon was unprecedented. However, Red Hat’s choice of layering OpenShift on top of Kubernetes is not recent. Can you walk through a brief history of OpenShift and how it leverages Kubernetes?
Brian Gracely: Prior to 2015, OpenShift was like most other PaaS platforms (Apprenda, dotCloud, Cloud Foundry, Heroku, etc.) - built on homegrown, non-standard container orchestration. Red Hat knows from experience that it’s very difficult to both innovate and maintain that type of technology without broad community support. So when Google approached Red Hat in 2014 about the Kubernetes project, we were excited about the prospect of helping to build out that project and community. We were already heavily involved in the docker project since 2013, so this was the next logical step to moving away from the homegrown container technologies in OpenShift v1 and v2, to fully supporting docker and Kubernetes in OpenShift v3.0. Red Hat OpenShift was the first Enterprise platform to support those standards, and Red Hat has been the 2nd largest contributor to both of those projects. Since then, we’ve been heavily involved in the Kubernetes leadership/steering groups, as well as Chair or Co-Chair of 12 of the Kubernetes SIGs. We’re also the largest contributor to the OCI projects that are standardizing the container format and runtime.
InfoQ: Can you describe the overall synergy between OpenShift and Kubernetes in terms of the implementation?
Gracely: Everything that Red Hat does for OpenShift (the platform) starts in the Kubernetes project(s), so the overall synergy is 100%. OpenShift is Kubernetes certified. From the upstream work in Kubernetes, we take that work and broadly integrate it with other technologies (SDN networking, storage, monitoring, container registry, container-requirements (e.g. security, HW-support) in Linux), CI/CD integration, etc. and it becomes the OpenShift Origin project. OpenShift Origin is analogous to the Fedora project with Linux. And then the commercial version of OpenShift Origin is available as either software (OpenShift Container Platform, OCP) or managed services (OpenShift Dedicated or OpenShift Online).
InfoQ: Kubernetes is often characterized as a platform for building platforms. Helm charts, Istio, KubeFlow are many examples of this. Does OpenShift take a similar approach in leveraging other open source products or the philosophy for OpenShift is different?
Gracely: OpenShift is a modular, composable platform. It ships with default capabilities, but also allows customers or technology partners to substitute alternative choices (e.g. SDN networking, storage, monitoring, etc.). There are over 300 OpenShift partners that provide 100s of tested integrations. Given OpenShift’s history as a platform, it has often implemented features prior to them being available via Kubernetes or another open source project. For example, RBAC was available in OpenShift, and then ported to Kubernetes. OpenShift had application templates before the Helm project. In some cases the OpenShift implementation will be ported to Kubernetes (e.g. RBAC), and in other cases it will add the newer functionality (e.g. Helm or Prometheus) as an option for OpenShift. In addition, Red Hat is actively involved in helping to evolve and integrate new projects like Istio or serverless projects like OpenWhisk, as well as new focus areas like performance sensitive applications.
InfoQ: If I am developer or architect in an enterprise working on a legacy application that mostly works, is OpenShift relevant to me at all?
Gracely: Probably at least half of OpenShift customers have modernized an existing application or lift-and-shifted an application to OpenShift. Examples include: Barclays Bank, Deutsche Bank, Disney/Pixar, Inmarsat, Keybank, Optum / United Health Group, SKY TV, Volvo, Verizon, Telus, and many more. The analyst firm IDC validated that the ROI of these migrations can add significant value to the business.
Containers and Kubernetes provide a number of valuable concepts for any application. Containers can provide a consistent way to package applications to run in Dev, Test, Q/A, Staging and Production. They provide immutability, which can simplify how security updates are handled by operations teams. They can provide a level of portability between cloud environments. Kubernetes and platforms like OpenShift can provide a consistent, automated, scalable environment across any cloud environment (e.g. multi-cloud).
InfoQ: The pioneer in the PaaS space was Heroku. Most of the PaaSes are great for stateless applications. Can you provide some in-depth technical information on how OpenShift strives to include Stateful applications as well which is the nature of the real life?
Gracely: The limitation of only supporting stateless applications was one of the biggest complaints from customers of early PaaS systems, especially Enterprise companies. 12 factor apps were just a collection of 12 opinions for why your apps can’t run on Heroku or Cloud Foundry platforms. When OpenShift migrated to standard containers and Kubernetes, it didn’t have the same 12-factor opinions built in, so the platform could be more flexible. Red Hat engineers contributed much of the storage work to Kubernetes, and we’ve supported many types of persistent storage since v3.0. In subsequent releases, that has been enhanced with dynamic provisioning of storage volumes, as well as multiple storage classes. In addition to Kubernetes storage work, Red Hat has been heavily involved with StatefulSets.
One of the biggest misperceptions of containers is that they can only be used for short-lived applications or stateless applications.
InfoQ: Can you talk about the ecosystem, different offerings and the roadmap for OpenShift?
Gracely: To start with, we see the OpenShift ecosystem being the Kubernetes ecosystem. That core technology allows the ecosystem to be very flexible, and the community has standardized on APIs and interfaces that have allowed consistent integration of new ideas. It also allows us to deploy OpenShift on any cloud platform (AWS, Azure, GCP, OpenStack, VMware, RHV, and bare metal). For both technology partners, ISVs and customers that come to us with requests to integrate, we have the OpenShift Commons community and the OpenShift Primed program. Red Hat has announced major partnerships with AWS and Azure to extend their technologies to OpenShift (e.g. Service Broker, Windows Containers, MS SQL), we host OpenShift Dedicated on AWS and GCP (and soon Azure) and obviously we’ve worked extremely close with the Google engineering team since the earliest days of Kubernetes. OpenShift is also used as the back-end platform technology to power cloud service providers around the world. OpenShift is commercially available in multiple consumption models:
- OpenShift Container Platform - Consumed as a software platform that can be deployed across any cloud (AWS, Azure, GCP, OpenStack, VMware, RHV, and bare metal).
- OpenShift Dedicated - Consumed as a managed service (operated by Red Hat), providing a “private” cloud environment. OpenShift Dedicated can be deployed in any region of AWS or GCP (with Azure coming in 2018).
- OpenShift Online - Consumed as an on-demand environment for developers, managed by Red Hat. OpenShift Online provides both a Starter Tier (free) and Pro Tier (paid).
Regarding the roadmap and what’s next, here’s a public session we did at Red Hat Summit as well as a follow-up at OpenShift Commons in Austin before KubeCon. The priorities for the roadmap fall into these areas:
- Continue to integrate updates from the Kubernetes community and CNCF projects.
- Continue to expand the breadth of applications that can run on the OpenShift platform (12-factor, Stateful, Machine Learning / AI, Databases, Serverless, High-performance computing, etc.). The recently launched RHOAR (Red Hat OpenShift Application Runtimes) is helping to lead this expansion.
- Continue to enable a multi-cloud experience and simplify the integration with public cloud services (e.g. Service Broker).
- Continue to deliver robust, multi-layered security to the platform, as well as continuing to simplify the delivery of a secure environment in a rapidly-changing software context.
- Continue to deliver a robust developer experience, both in terms of UI (CLI, GUI, API) and CI/CD integration. OpenShift.io will be one of the options to deliver a simpler, more integrated experience for developers.
Keynote sessions and other session recordings are available via the schedule for Kubecon.
