Published at 16.07.2021
Launched in 2013 as a project by Cloud Foundry and officially released in 2016, the Open Service Broker API (OSB API) is an API definition that specifies an interface for provisioning and managing services on cloud-native platforms.
As a provider of tailored Cloud Platform Solutions, which also includes Data Services for Cloud Foundry and Kubernetes, we want to present to you how we currently use the OSB API and what potential it offers for making data services consumable across or even outside of popular cloud-native platforms such as Cloud Foundry and Kubernetes. Moreover, we want to also share some important decisions we made during the process of developing our Data Services for Kubernetes.
The OSB API, developed with the input of the leading cloud companies like IBM, Google, and many more, defines the interface for a so-called “Service Broker”. These Brokers offer service catalogs, a list of services they can provide along with Service Plans for each service, which represents different configuration options of a service instance. For example, in our a9s PostgreSQL Data Service, you can choose between big, small and medium instances and whether or not you want to have replication setup. When requested through the Open Service Broker API, the Service Broker is then responsible for provisioning and managing a service instance. Thereby it is important to mention that the OSB API specification doesn’t make any assumption about how the Service Broker is actually implemented nor where and how it is provisioned. The same holds in particular true for the actual service instances that are life-cycle managed by the broker.
The usage of the standard API enables the creation of marketplaces offered by platforms like Cloud Foundry, they are a central place where you register Brokers and then the marketplace will provide the user with a combined catalog of all available services. Wrapped in a CLI, you can use it to create an entire database cluster with a single command, for example, a9s PostgreSQL Data Service Broker will deploy a PostgreSQL Cluster with Streaming Replication, Backups, Logging, and Metrics fully setup. If you want to learn more about how easy and convenient it can be to life-cycle manage a PostgreSQL cluster in the cloud, check out our new video series on youtube.
Managed Services on Cloud Foundry
This is how all of our Data Services can easily be used in the Cloud Foundry Application Development Platform. Our Service Broker offers the Data Services in the Cloud Foundry Marketplace and when the user requests an instance through the OSB API, our broker will take care of deploying the services with the help of BOSH. BOSH is part of Cloud Foundry and is a tool to deploy and manage virtual machines (VMs). These will then for example run a 3-node PostgreSQL Cluster consisting of 3 self-sufficient VMs.
But even though the API was created by the Cloud Foundry Foundation, its usage is not limited to that platform. The Service Catalog brought it, along with the idea of easy provisioning of services through a marketplace, to Kubernetes. Kubernetes (k8s) is an open-source container orchestrator, originally developed by Google, that allows the automated deployment, scaling, and management of container-based applications. Its popularity is increasing with the rise of the container movement and it is the current number one used orchestrator. We won’t go into the details of what a container is here, for more check out for example this explanation on the Docker website, but you can think of it as a lightweight, mini VM without an actual operating system.
The Service Catalog opens up the possibility to offer our existing VM-based Data Services on another platform, since the interface is the same you only have to register the broker. Great – so we can offer the same services on two platforms! Well, the answer is yes and no.
Kubernetes – A quick introduction
Let’s first take a closer look at Kubernetes. The main reason for its popularity and the popularity of containers is that they come with a much smaller overhead compared to the traditional VM-based solutions. This leads to much more efficient usage of the available resources.
Kubernetes also comes with a different concept on how you interact with the platform, namely a declarative approach is used. This means the user specifies the state in which he wants the cluster to be in (rather than how to get there) and Kubernetes is responsible for getting and keeping the cluster at that state.
This approach is responsible for another major advantage, the “self-healing” behavior of the Kubernetes cluster, say for example your deployed application and its Pod (the smallest deployment unit of Kubernetes) fail, it will be destroyed, a new Pod will be created and your application will be back up and running. To be fair, automated replication and failover of containerized database clusters involve more complexity than just letting the Kubernetes Control Plane reschedule a new container. Those are the challenges the a9s Data Services Team is taking care of.
This functionality along with many other features like easy scaling, make Kubernetes a perfect solution for managing cloud applications.
anynines Data Services on Kubernetes
Now back to our data services, technically it would be possible to use our VM-based data services on Kubernetes via the Service Catalog. But it would require us to run the VMs alongside the cluster as a completely separate infrastructure layer. Besides the obvious administrative overhead of such a solution, we would lose all of the advantages of a Kubernetes-native solution, like increased efficiency. Furthermore, it would contradict the intention behind Kubernetes to provide one platform for declarative management of all workloads in k8s clusters and thus wouldn’t allow us to offer our data services in a way which we consider a good and native user experience.
Moreover, there are some limitations of the OSB API specification which we want to overcome. The OSB API doesn’t cover some important 2nd-day life-cycle operations like Backup & Restore. While we currently support such operations in a9s Data Service on VMs, we have to make them available via separate APIs that are unrelated to the OSB API. For the upcoming a9s Data Services on Kubernetes, we will support such 2nd-day operations through k8s API extensions to provide a harmonized user experience across a wide range of different data services.
We consider it important to provide a natural experience, driven by the best practices of the Kubernetes community. That’s why we decided to transform our a9s Data Services on VMs to be Kubernetes native. They are running on containers within Kubernetes Clusters using best practices and also offer the same full life-cycle automation we offer on BOSH-managed VMs. We currently develop them as so-called Operators (using the Operator SDK), which are essentially an extension of the Kubernetes API by means of Custom Resource Definitions (CRD).
In addition to this k8-native interface, we’ll also offer an OSB API interface, for the same easy provisioning in a Cloud Foundry Environment. How are we going to do that? For a detailed explanation check out this video. Essentially we want to use a containerized Broker that implements the OSB API to deploy custom resources for the Operators.
In summary, Service Brokers offer a convenient possibility for using data services on different platforms that support the OSB API, for example via the Kubernetes Service Catalogue or the Cloud Foundry Services Marketplace.
However, on Kubernetes we want to follow a more native approach that leverages the full potential of Kubernetes like declarative management of workloads. At the same time, we want to give our customers the flexibility to use our container-based data services that are running on Kubernetes also from OSB-based catalogs, like Cloud Foundry Marketplace. So stay tuned for updates on our new line of products and for more posts about the challenges of bringing data services to Kubernetes and a tech demo on how to use anynines Data Services for Kubernetes on our Public Platform-as-a-Service solution.
In the meantime, you can read more about why we think Kubernetes is becoming the new infrastructure layer in this blog post or if you want to learn more about the challenges of constructing highly available data services, check out this article.
Check out this video that explains anynines Data Services