In August, many members of the Open Service Broker API community spent two days at Google’s offices in Seattle discussing the future of the specification. We had participants in person and joining remotely from Red Hat, IBM, Pivotal, Google, SAP, Dell EMC, Microsoft, and Fujitsu representing the Cloud Foundry and Kubernetes communities. The group discussed a wide range of topics and behaviours with a key focus on ensuring that service authors are able to create platform agnostic service brokers in order to grow a diverse ecosystem of cloud-native services.
Open Service Broker API working group at the Fremont Troll in Seattle
A key challenge the group faces as the specification evolves is how to allow for innovation whilst maintaining backward compatibility. As more and more platforms and brokers begin to consume and comply with the specification, the feedback the community is receiving shows the incredible range of services that are being built across the world. Some existing behaviours and clauses are now seeming to be too restrictive, and so the group is putting deprecation strategies in place that will be resolved in the next major version of the specification.
A number of important API behaviours were discussed in detail, including improved authentication using OAuth, supporting the asynchronous creation of service bindings, updating of service bindings and allowing brokers to expose the actions their services’ provide to application developers. These features are incredibly important to all modern platforms including Cloud Foundry and Kubernetes, and the group was excited to make progress on these features and move many into the validation through implementation phase (where teams begin working on these features and ensure the proposed specification changes are fit for purpose).
The next specification feature that is being validated by Cloud Foundry and Kubernetes platforms is the ability for service brokers to advertise the configuration parameters they accept for the provisioning of service instances, updating of service instances and creation of service bindings. By using the powerful JSON Schema specification, platform tools (CLIs and UIs) will be able to provide a much-improved developer experience creating and managing services compatible with the specification.
In deep discussion at Google’s Seattle office
The working group is thrilled to see how quickly the community and ecosystem are growing, thanks to the rapid adoption of the specification by service broker authors and the Kubernetes Service Catalog project. We are always looking to welcome new members into the community, so if you work on platforms, service brokers or have any feedback at all, please join our weekly call where the group dedicates time every week to welcome new faces and discuss community interests.
And keep an eye out for the next version of the specification, 2.13 – the second version being launched under the guidance of the Open Service Broker API project committee.
Thanks to Matt McNeeney from Pivotal for the detailed write up.