Kubernetes Operators and the Open Service Broker API: A Perfect Marriage
There are two popular mechanisms for attaching backing services to cloud native applications today: Operators and the Open Service Broker API. This post compares these technologies and explains how they can work together to address a wider range of development scenarios.
Application developers deliver value with three kinds of software:
- Bespoke software: Software that they create and run themselves (e.g. a mobile app they provide to their end users);
- Common off-the-shelf software: Software written by someone else that they run themselves (e.g. a MySQL release that they install, configure and run themselves). Kubernetes folks often refer to this type of software as White Box Software;
- Managed service: Software run and maintained by a third-party (e.g. AWS Relational Database Service or MySQL for PCF). Note that third-party does not necessarily mean a different company; it could be software that was built or is being run by a different team within your organization.
Throughout this post, we will refer to these types of software as bespoke software, common off-the-shelf software and managed services. However, this post is primarily focused on managed services.
One of the big benefits Cloud Foundry provides has been the ability for developers to get self-service access to the managed services their workloads require. The Cloud Foundry Services API specification was launched in 2012 to allow any service provider building a managed service to make that service available on any Cloud Foundry platform.
When Kubernetes was launched, service providers saw an opportunity to bring the thriving marketplace of managed services for Cloud Foundry to this ecosystem. After all, workloads running on Kubernetes clusters need access to many of these same sets of services. And so, the Cloud Foundry Services API specification became the Open Service Broker API (OSBAPI).
Folks in the Kubernetes community have built support for the OSBAPI specification and have created the Service Catalog project to provide a marketplace of services inside Kubernetes clusters.
However, we are seeing new technologies emerge in this problem space. The purpose of this post is to start a discussion around what these technologies are and how they compare to the mechanisms we have in place today. To start, let’s take a look at Operators, and how they compare to the OSBAPI.
What Are Operators and Why Do They Matter?
In the last few months, we have seen Operators soar in popularity. It’s easy to see why. Operators allow developers working with Kubernetes to consume managed services directly from Kubernetes clusters. Subsequently, the Operator pattern has often been brought up as an alternative to building OSBAPI-compliant service brokers.
There is some confusion around what an Operator is, and so to clarify:
- The Operator pattern is a set of Custom Resource Definitions (CRDs) with custom controllers to act on them;
- The Operator Framework is the Operator pattern plus:
-
- Tooling to manage deployments (auto updates and a registry).
- Metadata on CRDs to build help build user experiences.
For our discussion here, we focus on the Operator pattern. If you take a look operatorhub.io, you can see two distinct use cases for the Operator pattern:
- Where the Operator is an application-specific controller that extends the Kubernetes API to create, configure, and manage instances of complex stateful applications running on a Kubernetes cluster. The Operator is usually running on the same cluster as the workload in question. Examples of workloads for which Operators are available to include Couchbase and PostgreSQL;
- To consume a managed service, such as the AWS Service Operator. Here, any provisioned services are running in completely different infrastructure to the software that is consuming it.
The key difference between these two use cases is who is responsible for running the software. The first use case can be used for running and managing both bespoke software and common off-the-shelf software. This is a clear difference with the OSBAPI, as the Service Broker model does not meet this use case.
The second use case provides a user experience for consuming managed services, and can, therefore, be thought about as an alternative to OSBAPI.
Contrasting Operators with OSBAPI
The OSBAPI provides a prescriptive interface for interacting with managed services. It gives developers the ability to provision, update, deprovision, bind and unbind to them. Service providers need only build the “server” side (e.g. the service broker), and relies on the platform (e.g. Cloud Foundry or Kubernetes Service Catalog) to provide the user experience. Note that the Service Catalog project is still maturing. Consequently, the OSBAPI is not seen as a valid mechanism to provide managed services to Kubernetes developers.
The Operator pattern for consuming managed services provides a more flexible interface for this interaction. Many different things can be modeled as a custom resource; developers can therefore interact with a wider range of services.
Of course, this flexibility comes with complexity. Service providers need to build both the “client” side (the Operator for developers to install which provides the user experience) and the “server” side. Note that the “server” side in this scenario could be any API, including one that conforms to the OSBAPI specification.
Regardless of what software a service provider needs to write and where those things are run, this exercise boils down to two things:
- User experience: The OSBAPI provides a strong opinion on the lifecycle management exposed to developers. With Operators, there isn’t much of an opinion. Service providers may build whatever user experience they want. Even with the proposed Generic Extensions, the OSBAPI specification will never provide as much flexibility as a custom Operator. However, flexibility tends to lead to a less consistent user experience;
- Cost of development: With the OSBAPI, service providers only need to build and maintain the OSBAPI-compliant “server” (i.e. Service Broker), otherwise relying on the platform-provided user experience. For Operators, service providers have to build and maintain their “server” (and likely define their own API). They must also build their Operator to provide the user experience.
Now we know a bit about the differences between the OSBAPI and Operators. Let’s now explore the current state of Kubernetes development.
How are Developers Using Kubernetes today?
There are two main schools of thought around how developers should be using Kubernetes:
- Developers should deploy applications directly on top of Kubernetes. As described on https://kubernetes.io: “Kubernetes (K8s) is an open-source system for automating deployment, scaling and management of containerized applications”;
- ”Kubernetes is a platform for building platforms.” This is the Kelsey Hightower school of thought. Here, developers should be using an abstraction that is built on top of Kubernetes.
For the first case, it makes sense to use native Kubernetes constructs to give applications access to managed services. Projects like Service Catalog and Independent Services Marketplace do this today by making use of Kubernetes secrets to store the information applications need to consume managed services.
For the second case, there are many unknowns. The platforms being built on top of Kubernetes are emergent. We need more data before we can authoritatively say what a “good” user experience looks like for consuming managed services from higher abstractions like Knative.
What the Future Could Look Like
Understandably, many service providers want to understand what mechanisms they should use to provide managed services to Cloud Foundry and Kubernetes-based platforms in the future.
Here are three observations, considering the technologies we’ve discussed so far:
- Operators seem to be gaining a lot of traction for common off-the-shelf software, which developers need to both run and manage. For software built on top of Kubernetes, this model seems to be the dominant pattern and provides a lot of benefits;
- The community needs to build consensus on how managed services should be consumed by applications running atop Kubernetes. This impacts both service providers building managed services, and also those building platforms on top of Kubernetes. (Remember, we still need to learn what user experience should be provided by these platforms);
- There is no alternative to the Open Service Broker API today. There is no other standard which service providers can use to provide managed services to multiple platforms.
OSBAPI and Operators Can Work Together
Given this, it makes sense to find ways for these two technologies to work together. In our experience, there’s a way to embrace the respective strengths, investment, and traction of each project. Here’s what that might look like.
The OSBAPI does not have strong opinions about how management is done; it just asks that the service is managed somehow. That allows the OSBAPI to leverage the investment made in a mature and sophisticated Operator. The amount of automation encoded into Operators varies considerably. The Operator Framework places these operators on an Operator Maturity Model spectrum. The operators on the mature end of the spectrum are capable of achieving levels of management automation similar to a BOSH deployment.
This allows a platform engineer running Cloud Foundry and Kubernetes in their enterprise to offer such services to their developers. An OSBAPI-compliant service broker can sit in front of, and interact with, the Operator. Many of the open source Operators we’ve looked at have a subset of interactions that would map relatively cleanly onto the OSBAPI endpoints. More advanced interactions will be supported in the future once the upcoming Generic Extensions feature has made it into the OSBAPI specification. Note that the OSBAPI service broker itself can be deployed on Cloud Foundry, Kubernetes or elsewhere.
Bridging these two concepts with a Service Broker allows the platform engineer to curate and manage Kubernetes-based services. We often hear that Platform Engineers don’t want developers to just install any Helm chart or Operator. Responsible companies need better governance. (Just look at the latest security breaches for why a strong permissions model is a good idea.)
What mechanism balances security and governance with on-demand self-service access to add-on capabilities? A catalog of brokered services. Developers on platforms like Cloud Foundry can consume services without worrying about where those services are running. Platform Engineers can expose and manage the high-quality Operators which are gaining traction.
Pragmatically, Operator authors and platform engineers can leverage a generic broker like Kibosh to make their efforts available to platforms that integrate with the OSBAPI. In many situations, the OSBAPI and Operator technologies can complement one another quite well.
From the other direction, the community is refactoring the Service Catalog project to use custom resources. When complete, this new-and-improved version will provide access to managed services that live behind OSBAPI-compliant service brokers. This may allow a future avenue for managed service authors to easily offer their existing OSBAPI-based services to developers working with Kubernetes.
Conclusion: Watch this Space
At Pivotal, we have been exploring this space for quite a while. Over the past few years, we have helped hundreds of independent software vendors (ISVs) create high-quality services that can be easily offered to customers running any variant of Cloud Foundry. Kubernetes is opening up interesting new opportunities for these ISVs as well.
Pivotal is already embarking on new journeys in this space. Our goal is a mechanism that allows Platform Engineers to easily curate a marketplace of services which can be consumed by applications running across many Cloud Foundry and Kubernetes clusters. By building on top of the diverse ecosystem of services available today, and also integrating modern tools like Kibosh, we hope that this new mechanism will enable enterprises to curate large, thriving marketplaces of services for all of their workloads to consume, no matter what platform they’re running on.
Thanks to Aaron Meza, Jatin Naik, Sam Gunaratne and Ed King for their contributions to this article.
