At the end of 2016, the Cloud Foundry Services API became the Open Service Broker API, an open source project under the guidance of the Cloud Foundry Foundation. A new project management committee was formed and the community began to grow immediately, bringing in contributors from VMware, Google, IBM, RedHat, SAP and many other cloud-native companies.
The Open Service Broker API is what ISVs and SaaS vendors use to deliver services to applications and containers running in cloud-native platforms such as Cloud Foundry, OpenShift and Kubernetes.
If you’re heading to Basel, Switzerland in October for the Cloud Foundry Summit Europe, you can learn more about the project in this talk at Open Service Broker API and Cloud Foundry Services API office hours.
The recently formed Services API project (under the Application Runtime PMC) aims to enhance the developer workflow on Cloud Foundry provisioning and managing services. Contributors from VMware and SUSE are already working on many new features in the Cloud Controller and Open Service Broker API. By improving both these workflows in the platform and the Open Service Broker API specification, the team hopes to encourage a diverse ecosystem of services that can be consumed by cloud-native platforms like Cloud Foundry and Kubernetes.
This week marked the second update to the Open Service Broker API specification under the guidance of the working group: v2.13. This new version comes three months after the last version and includes a diverse range of new features, bug fixes and improvements. Many of these features were discussed at the recent community meetup at Google’s offices in Fremont, Seattle.
Some of the features in this release that are most exciting to the community are detailed below. More information on this release can be found in the release notes, and you can stay up to date with what the community is working on by checking out the Roadmap & Release Planning project on GitHub.
Schemas for Configuration Parameters
Many service brokers accept configuration parameters that application developers can use when provisioning service instances, updating service instances and creating service bindings. Until now, developers have had to find documentation for a specific service to understand the arbitrary key-value pairs that can be provided and the allowed values that can be provided for each parameter. From this version onwards, service brokers can now include JSON Schemas in their catalog data that describe the parameters application developers can provide. This allows command-line and other user interfaces to perform up-front validation of parameters, and can even be used to dynamically generate forms with dropdowns, ranges and other UI elements. The example below shows how this can help provide a much better developer user experience.
Improved Authentication Mechanisms
Platform to service broker communication currently uses Basic access authentication, but many people in the community have expressed a desire to investigate more secure and extensible mechanisms like OAuth. A change has been made to the specification in v2.13 that allows platforms to start investigating how other authentication mechanisms could be implemented and how new features could be allowed, such as providing role-based access control for application developers to use features of the underlying service.
New ‘Getting Started’ Page
A new page has been added to the Open Service Broker API repository that contains a number of sample service brokers and libraries that the community has been working hard on. This should make it much easier for service authors to see what others are working on in the community, and provide new service authors with an easy way to get started and quickly provide their services to cloud-native platforms.
