« Back to home

Introduction to the Open Service Broker API - Simplify stateful application deployments to Kubernetes

....by keeping the state outside of your cluster

This is the first in a series of posts about the Open Service Broker API and how it can used to provision services external to your cluster as part of your Kubernetes deployments.

Although not strictly necessary for this post, if you are new to Kubernetes I would recommend reading up on the basics, the Kubernetes documentation is a good place to start.

The Open Service Broker API

The Open Service Broker API (OSB) is a project to standardise the way in which cloud native applications on a variety of plaforms can provision and consume services [1] without having detailed knowledge of their implementation. For the service vendors it opens up their services to be consumed on a variety of platforms with relative ease.
The aim of the project is to simplify the consumption of these services without having to leave the context of your platform and without having to write custom scripts to deal with creating the resources and retrieving connection details and secrets.
Although this blog post focuses on Kubernetes the OSB is available on a variety of platforms including Cloud Foundry and OpenShift.
To take advantage of this API you need to have a service provider implementation for your platform. For example if you wanted to use AWS services on Kubernetes you need an implementation of the OSB for AWS that works for Kubernetes, at the time of writing there is an AWS implementation but I believe it only works on OpenShift (thanks Adnan for the details on that!).
The subject of the next post is the Open Service Broker for Azure which works on Kubernetes along with Cloud Foundry and allows you to consume Azure Services such as Azure SQL DB or CosmosDB.

It's worth mentioning that the OSB isn't limited to provisioning datastores, it can be used for any service.

Challenges of managing stateful applications

Applications may be comprised of a number of services, many of these may be stateless but almost all applications eventually need to store state somewhere; this might be stored in a file on a disk, in a database or a queue.

Compared to stateless services, deploying stateful applications to Kubernetes brings with it some additional overhead. When you first start working with Kubernetes you often want to create everything within the cluster including your datastores. This especially the case now that we can get databases in containers so spinning these up on K8s can be pretty straightforward. However for production scenarios you'll need to consider a number of factors, for example you need to ensure you have high availability of your database, reliable persistent & fast data storage, etc and all of these add complexity to the deployments.

I want to be clear here, these are not insurmountable challenges, stateful applications are supported on Kubernetes through the use of volumes, statefulsets etc, however you may decide you don't want to deal with the additional overhead and instead opt for a datastore external to your cluster (or you may already have a data platform you're happy using).
This isn't really a failing of Kubernetes per se but rather a recognition that hosting production quality datastores is non-trivial even if a platform like Kuberenetes takes care of alot of the low level details.
Google's Kelsey Hightower summed it up perfectly I think

k8sstateful

Taking the database out of the cluster

If you're running a Kubernetes cluster in the cloud you may well opt for a cloud managed service to store your state (most offer a number of additional compelling features you don't have to run and manage yourself), although this applies equally well if you're running on-prem or hybrid too. To make use of these cloud services you face a different set of challenges, less about day to day operational concerns and more about deployment/devops concerns.

Let's say you want to deploy an application to Kubernetes that uses a SQL Azure database, there are a number of steps that need to be followed in a specific order:

  1. Provision and configure the Azure SQL database (specifying subscription, sku etc.)
  2. Retrieve the connection string information (contains sensitive information)
  3. Update your kubernetes deployment with the relevant secrets/config maps to access the database
  4. Deploy the application (which may also deploy the schema & data).

We could perform these steps manually but more likely (hopefully!) we would automate these steps and therefore we'd end up with a custom script/templates to do this work.
For a different datastore or for a different cloud provider we'd need different specific scripts for that and all the time we are potentially passing around secrets during this process.

These kinds of problems aren't new or unique to Kubernetes, infact the folks over at Pivotal had similar challenges with their Cloud Foundry platform and introduced the concept of service brokers, this approach has now been adopted as the industry standard and formalised into the Open Service Broker API

Service Catalog

In the context of Kubernetes, the Service Catalog, forms a key component which enables OSB implementations.
The service catalog sits between the Kubernetes API server and the OSB implementation(s) which ultimate communicate with specific service providers to provision services. Using the service catalog cluster operators can list available services, provision these services and make them available to applications in a consistent way.
Once the service has been provisioned the relevant credentials and connection details are returned as a binding instance which is used to update the application deployment.
Using the service catalog and service broker api implementations it should be possible to provision multiple services across more than one cloud if you so desire and use these services within your Kubernetes application.

Summary

The Open Service Broker API allows you to provision and connect to external services without having to leave the context of your particular cloud native platform. It standardises the approach across a number of platforms and vendors and will great simplify the process of deploying stateful applications without having to take complete responsibility for managing those stateful services within your cluster.

In the next part we'll talk more specifically about the implementation of the API for Azure with the catchily named Open Service Broker for Azure (OSBA) and how we can use this to deploy our Kubernetes application that uses Azure services for its state.


  1. Service is a very overloaded term, throughout this post I'm referring to the general concept of a service as a dependency external to your application that you may consume via a communication protocol, not to be confused with a Kubernetes Service ↩︎