The Open Service Broker API project allows independent software vendors, SaaS providers and developers to easily provide backing services to workloads running on cloud native platforms such as Cloud Foundry and Kubernetes. The specification, which has been adopted by many platforms and thousands of service providers, describes a simple set of API endpoints which can be used to provision, gain access to and managing service offerings.

The project has contributors from Google, IBM, Pivotal, Red Hat, SAP and many other leading cloud companies.

We welcome participation in the Open Service Broker API community, and anyone is welcome to join the community call which takes place regularly as part of the CFF Service Management Working Group Community Meeting.

OSBAPI Compliant Products

Chat with us on Slack

Join the Google Group

Get involved on Github

Service brokers manage the lifecycle of services, and platforms interact with service brokers to provision, get access to and manage the services they offer. The Open Service Broker API defines these interactions, and therefore allows software providers to offer their services to anyone, regardless of the technology or infrastructure those software providers wish to utilise.

Each service broker built to the Open Service Broker API specification has the same intuitive set of lifecycle commands. These commands do useful things such as:

• Fetching the catalog of backing services that a service broker offers
  The catalog describes all of the services that can be provisioned through a service broker, and each service is made up of plans. Plans typically represent the costs and benefits for a given variant of the service. Many services use plans to ‘T-Shirt size’ the service offering (such as “small”, “medium”, and “large”).
• Provisioning new service instances
  A service instance is a provisioned instance of a service and plan as described in the service broker’s catalog.
• Connecting and disconnecting applications and containers from those service instances
  Once a service instance is provisioned, you’ll want your application or container to start communicating with that instance. From a service broker’s perspective, this is called a service binding.
• Deprovisioning service instances
  This action simply deletes all the resources created upon the initial provisioning of the service instance.

This model provides significant benefits for both development and operations teams:

• Developers can connect their applications and containers to the backing services they need. The operation is the same, regardless of the backing service.
• Operators no longer have to manually provision and delegate access to services. Instead, they simply configure a marketplace of services and service plans. From there, developers can self-serve, reducing the administrative overhead many enterprises face today.

Service brokers compliant with the Open Service Broker API specification allow platforms to provision a new instance of a service. And the service broker provides all the information that your application or container needs to connect to the service instance. Then, you simply connect to the service instance, regardless of how or where the service is running.

Provisioning a new service instance doesn’t necessarily mean that the service broker has to spin up a new virtual machine. For example, provisioning could also mean reserving some space in database which has previously been created. The specification purposefully provides a high-level abstraction, and is not opinionated on what should happen behind the API.

Getting started guide

Video: What is the Open Service Broker API?

Video: Building services for Cloud Foundry and Kubernetes using the Open Service Broker API

Blog: Open Service Broker API Launches as Industry Standard

Blog: Kubernetes And The Open Service Broker Make Multi-Cloud A Reality

Whitepaper: An Inside Look at the Open Service Broker API

1.

Define and evolve the Open Service Broker API as a specification, using a clear release process to support any downstream implementations

2.

Provide conformance test suites to verify compliance with the specification

3.

Advocate broad industry adoption in support of the end user community