Cloud Foundry Advisory Board Call, Mar 2022: Open Service Broker API

by Carlo GutierrezMarch 17, 2022

The call discussed the possibility of an in-person CF summit this year and how Rijkswaterstaat uses the Open Service Broker API to deploy external services.

Table of Contents

Brief agenda

Ram Iyengar

The Cloud Foundry Community Advisory Board (CAB) meeting in March featured a presentation around how Rijkswaterstaat leverages the Open Service Broker API (OSBAPI) to deploy SharePoint, Concourse CI, and PostgreSQL on Kubernetes and CF. (Previously, we covered how the Dutch government had built an alert system on Cloud Foundry in 7 months.)

The call was moderated by Ram Iyengar from the CF Foundation, and he along with Chris Clark also shared a number of community updates, such as a one-day colocated summit event.

How Rijkswaterstaat uses service brokers

Announced back in 2016, the OSBAPI provides developers with a simple way to deliver services to applications running within cloud-native offerings, such as Cloud Foundry and Kubernetes. In a nutshell, service brokers compliant with the OSBAPI specification allow platforms to provision a new instance of a service. This way, service brokers supply all the information that an application or a container needs to connect to the service instance. Then, developers can connect to the service instance, regardless of how or where the service is running.

During the call, Onno Brouwer of Rijkswaterstaat shared insights gained from an OSBAPI workshop he had organized for his organization’s cloud-native application team. He and the team were able to build and deploy service brokers on Cloud Foundry and Kubernetes. Most notably, Rijkswaterstaat was able to deploy service brokers for SharePoint, Concourse CI, and PostgreSQL.

Deploying a service broker on Cloud Foundry

However, the team faced some problems and limitations. For instance, with Concourse CI, the default permission is an owner, which enabled any member to modify team permissions or even delete the team entirely. Despite this, Onno noted that deploying service brokers on Cloud Foundry and Kubernetes were fairly straightforward.

Onno Brouwer

“Making a service broker work on Kubernetes was the easy part. Once you know how to write YAML and how to build the app using Cloud Native Buildpacks, it becomes relatively easy. Implementing the correct business logic—deciding what a broker should do and how to make it work for all use cases—took most of our time to get correct. Ideally, ownership of the broker should rely with the service team, since they know best how to implement business logic.”
—Onno Brouwer, Rijkswaterstaat

Deploying a service broker on Kubernetes

To conclude the presentation, Onno shared some challenges that may hinder the growth of OSBAPI:

Platforms take ownership of service instances, and there is no clear method for granting multiple platforms access to the same instance.
There is no clear method for migrating service implementations.
The OSBAPI and service catalog projects are no longer as active as before, and are lacking contribution.

OSBAPI’s GitHub

Foundation updates

Chris Clark

Ram and Chris Clark provided the following community updates:

The CF Foundation is considering resuming in-person events this year.
The Technical Oversight Committee continues to make progress with the working groups initiative.
There is an increasing interest in community outreach for various projects, including Paketo and service brokers.

“Before the pandemic hit, we decided to go from a standalone two-day Cloud Foundry summit to a one-day colocated event. We’re discussing that for this year.”
—Chris Clark, Cloud Foundry Foundation

The next CAB call is tentatively scheduled for April 20, 2022, at 11 a.m. ET / 8 a.m. PT. Anyone interested in participating can join the Cloud Foundry’s CAB Slack channel.