Matt McNeeney

In the last few years, many service providers have adopted the Open Service Broker, building hundreds of publicly available service brokers for many cloud-native platforms. However, it has been hard to truly show the vibrancy of this ever-growing ecosystem as developers have had to scour the web to find the brokered service offerings that meet their use case.

To help these developers moving forward, we’re excited to launch the community-driven catalog showing some of the publicly available service brokers today!

You can now search through the list of service offerings that have been built using the Open Service Broker API standard, find out more information about each offering, and easily submit your own product for developers to find.

If you’re a developer, we really hope that this makes it easier to find the services you need for your workloads. If you’re a service vendor, then make sure you submit your offerings today for the world to find.

Thanks to Brie and the rest of the Cloud Foundry Foundation team for all of their hard work building this! If you have any questions or feature requests, please get in touch with us on Slack.

It’s been 10 months since v2.14 of the Open Service Broker API was released, and so we are happy to announce a long list of new features that are available today for service providers to start using (make sure you check the compatibility file to see which platforms support each feature).

Our focus for this release was on making changes to the specification which would allow platforms (including Cloud Foundry and Kubernetes) to provide improved user experiences for a wide range of marketplace services. The full list of features can be found in the release notes, and we have highlighted some of the more noteworthy ones below.

Service bindings can now contain a list of endpoints

When an application is bound to a service instance, the application will usually need to know how to start talking to that service instance. Service bindings usually contain information like URLs, usernames and passwords, but until now it has been non-trivial for platforms to understand how to use that information.

As of this release, service bindings can now contain a list of endpoints, which provides a structure around information such as hostnames, ports and protocols. This will enable platforms to automatically set up any network connectivity between applications running on the platform and service instances running on any other infrastructure.

Service instance upgrades

There are situations in which a developer may want to upgrade a service instance, but that upgrade cannot be represented by either a plan change or through a configuration parameter. An example of this is upgrading the underlying operating system that a service instance is running on. This will often cause downtime for the service instance, so platform operators do not want to trigger this themselves or for it to happen automatically.

Service plans can now contain a maintenance_info field, which can be used to provide further information to developers about what version of the software is running and what version a service instance can be upgraded to.

Enable and disable upgrades of specific plans

The plan_updateable field can now be added to service plans, providing more control to service providers over which plans can be upgraded/downgraded/sidegraded to another version.

Clarified orphan mitigation scenarios

A number of scenarios can lead to orphaned service instances and service bindings being created on a service broker, and so the community spent some time understanding how these situations could arise and putting in tighter rules to help service providers know what they are expected to do in each situation.

Improved asynchronous operations

Service providers can now specify a timeout for asynchronous operations for each service they offer, and can also give platforms a hint as to when they should next poll for the status of an ongoing asynchronous operation.

This can be used to give developers a better idea of how long an operation is going to take and reduce the number of redundant calls made between platforms and service brokers.

---

We hope you are excited about the long list of new features in this release and look forward to seeing how these features are adopted in the community. As always, if you have any feedback we would love to hear it!

 

If you’re passing over the East Coast of the US this April, be sure to pop into Philadelphia (where it’s always sunny, apparently) to learn more about Service Brokers and how they are helping companies all over the world get access to the cloud-native services their applications need.

Registration is open now, and the schedule went live today. We’ve compiled a list of the best Open Service Broker API talks for you to bookmark before the conference kicks off on April 2nd:

 

Wednesday

11:20am: The Subtle Art of Keeping your Broker Multi-platform Compatible – Georgi Lozev, SAP

This talk will provide an overview of the different types of broker – based on their deployment model like hosted brokers, ones deployed alongside the platform and ones deployed on top of it. Then we will show you some pitfalls we came across while working on CF as a platform implementations and, last but not least, we will go over good practices and future improvements that should keep our brokers multi-platform compatible.

 

2:55pm: Testing Production Environments and Verifying Open Service Broker API Compliance – Oliver Wolf & Robert Gogolok, anynines

This talk shows how a generic test suite that verifies production platform environments and OSBAPI compliance can be used for different kind of data services.

Thursday

11:45am: Accessing Cloud Foundry Marketplace from your Kubernetes Cluster – Dr Nic Williams, Stark & Wayne

In this talk, we introduce the Kubernetes Service Catalog, the Open Service Broker API, and a special new service broker that bridges a CF user’s marketplace access into their own Kubernetes cluster.

 

2:00pm: One Marketplace to Rule Them All – Matt McNeeney & Sam Gunaratne, Pivotal

Come and learn how the open source Independent Services Marketplace team are building the future by inverting the relationship between platforms and backing services, and how this can drastically improve the lives of developers and operators running cloud-native platforms at scale.

 

3:20pm: Open Service Broker 101: That Extra Something – Christian Brinker, evoila

In his talk, Christian Brinker takes the audience on the journey from the reasons for the usage of service brokers via their inner structure and effects to complex production setups. He presents common pitfalls and best practices as well as giving a deep insight into the open source service broker framework of his team.

This week the Open Service Broker API working group released the latest version of the specification, v2.13.

This new version comes three months after the last version and includes a diverse range of new features, bug fixes and improvements. Some of the features the community are most excited about 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 have 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 an easy way to get started and quickly provide their services to cloud-native platforms.