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.

Recently there have been an array of talks that highlight the progress of the Open Service Broker API and the innovative service brokers and platform integrations the community is creating. In this post you will find some of the highlights from Cloud Foundry Summit and Cloud Native Con!

Cloud Foundry Summit Europe (October 2017)

The recent Cloud Foundry Summit European edition in Basel had a strong focus on the Open Service Broker API project with a mix of talks from developers, analysts and contributors.

Hell Freezes Over: The New Reality of Open Cloud Services and the OSBAPI

The first talk to highlight is from Josh McKenty and Colin Stevenson of Pivotal. With an entertaining format and style, Josh and Colin discuss the impact of the Open Service Broker API in the cloud-native space to enable portability of cloud services across industries and vendors.

Dualing Platforms: Build Services for Cloud Foundry and Kubernetes Using the Open Service Broker API

Alex Ley and Matt McNeeney of Pivotal gave a demo of how you can leverage a service broker from both Cloud Foundry and Kuberenetes. The demo highlights how far the Kubernetes Service Catalog project has come and that the multi-cloud, multi-platform future is quickly becoming a reality with the use of the Open Service Broker API.

Getting a Handle on Your Microservices: Istio and the Open Service Broker API

Morgan Bauer and Christopher Luciano from IBM talked about the recently open-sourced services mesh project, Istio. This talk gives an introduction to Istio and how the project can be used in concert with the Open Service Broker API. The demo starts with two applications bound to the same service (provided by the same service broker) and shows how to leverage Istio to direct traffic between the applications from the web. It also shows how Istio can provide value without any modifications to an application.

Cloud Native Con Europe (Febuary 2017)

The Open Service Broker API and the Kubernetes Service Catalog

Earlier this year at Cloud Native Con in Berlin, Chip Childers of the Cloud Foundry Foundation and Paul Morie from RedHat gave an introduction to the Kubernetes Service Catalog incubator project. In this talk, you’ll learn exactly what the Open Service Broker API specification is, its history, how the cross-ecosystem collaboration on the API specification is happening and how the Kubernetes ecosystem is building integrations with the specification. The talk also covers how to get involved in the Kubernetes Special Interest Group (SIG) and includes a project demo!

Panel: Leveraging the Open Service Broker API in Cloud Native Platforms

This panel discussion contains representatives from IBM, Pivotal, Fujitsu, RedHat and Orange who discuss where they want the project to go and why the initiative is important to their companies. Expect to learn more about the Open Service Broker API working group, the future of the project and insights into how leading technology companies are applying this specification to real-world use cases.

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.

An example of how JSON schemas can be used to automatically generate intuitive user interfaces

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.

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.

By Abby Kearns

Since becoming the Executive Director for Cloud Foundry, I have been eagerly awaiting today’s launch of the Open Service Broker API project. This collaborative project with Fujitsu, Google, IBM, Pivotal, Red Hat and SAP enables developers, ISVs and SaaS vendors to deliver services to applications running within cloud-native offerings — including Cloud Foundry, OpenShift and Kubernetes — in the most straightforward, effective way possible.

Part of what I love so fiercely about the open source world is the ability to shed ego, come together to collaborate and to envision a radically open future. This type of collaborative project with Cloud Native Computing Foundation and our good friends at Fujitsu, Google, IBM, Pivotal, Red Hat and SAP is born from a shared vision of the best possible world for developers, ISVs and SaaS vendors. We are able to work together to grow our ecosystem.

The Open Service Broker API is the latest example of Cloud Foundry practicing what we preach: open source is a positive sum game. By sharing this technology more broadly, we help to standardize a critical component of cloud-native applications — services. The mission of the Open Service Broker API project is to collaboratively advance the development of a standardized approach to connecting services to platforms. This benefits absolutely everyone.

By standardizing the industry on the Open Service Broker API, we can build a foundation for an ecosystem that transcends a single community. While the Service Broker API was initially developed specifically for the Cloud Foundry platform, and is an API specification hosted at the Foundation, this specification is notably distinct from the Cloud Foundry platform. The purpose of governing the API specification as a distinct effort is to ensure an open process of collaboration and evolution of the API, as well as to support implementations of the API by other platforms and services.

The Open Service Broker API is designed to simplify service interactions for developers. As my colleague Cloud Foundry CTO Chip Childers recently explained in an article on The New Stack: “[The Open Service Broker API is] a clean abstraction that allows ‘services’ to expose a catalog of capabilities, as well as the ability to create, use and delete those services. For this to make sense, the word ‘services’ needs a bit more of a definition. We consider services to be any software or system that applications depend on for various capabilities, either as external dependencies or platform-level capabilities provided to the application.”

Since being rewritten in 2013, the v2 API solved for many of the original implementation issues and grew its capabilities. Naturally, the Cloud Foundry community began to create service broker implementations for a wide variety of applications. Even large cloud providers like Google and Microsoft began to expose their native platform capabilities via the API, making other organizations interested in Cloud Foundry or a similar platform see the potential in this rapidly proliferating ecosystem of service providers.

Meanwhile, at the Foundation, we began to understand the massive potential to help the entire industry. Multiple other projects had expressed interest in adopting the Service Broker API and integrating with Cloud Foundry. In the spirit of open source collaboration, the Cloud Foundry Foundation and Cloud Native Computing Foundation founded a working group comprised of members from Google, Engine Yard, Fujitsu, IBM, Pivotal and Red Hat, with engineers who work across projects for both foundations.

Our shared vision was to develop an industry-standard service broker that allows developers, ISVs and SaaS vendors a single, simple and elegant way to produce, sell, buy and consume software on public and private clouds. The Open Service Broker API accelerates the expansion of the global cloud ecosystem by providing a single path add services to applications. Now developers can write and configure against a single API and reach many developers across multiple platforms. As a result of this remarkable initiative, we have witnessed Kubernetes’ adoption of the Service Broker API.

There is no doubt in my mind there will be continued collaboration across the ecosystem as we embrace the industry-standard API. The open source world continues to be a meeting of the minds for a community committed to bettering its options, broadening the ecosystem and strengthening the message of open.

Today, Cloud Foundry Foundation excitedly announced the launch of the Open Service Broker API project, in partnership with individuals representing Fujitsu, Google, IBM, Pivotal and Red Hat. The Open Service Broker API project provides developers, ISVs and SaaS vendors a single, simple and elegant way to deliver services to applications running within cloud native offerings, including Cloud Foundry and Kubernetes.

Many large companies are already in the process of implementing service brokers, including Google, Red Hat and Microsoft. Cloud Native Computing Foundation’s Kubernetes service catalog special interest group (SIG) is incubating integration of the Open Service Broker API.

Join us today, December 13 at 11am PST/2pm EST for a Twitter chat to discuss the Service Broker API — and the cloud services integral to developers and the industry as a whole. Cloud Foundry Foundation’s Executive Director Abby Kearns will be there along with RedMonk analyst, Stephen O’Grady. Be sure to join the conversation by following the hashtag #Appserviceschat when you join our crowdchat: www.crowdchat.net/appserviceschat!

If you have specific questions that you would like to ask, please tweet at @CloudFoundry. We encourage you to participate in the chat by including the hashtag #Appserviceschat in your tweets and responses.

Happy tweeting!