chrisclark

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.

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.

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!

Cloud Foundry Foundation opens up governance of Service Broker API, new group aims to incubate the standardization of service delivery across cloud offerings  

San Francisco, December 13, 2016 — Cloud Foundry Foundation, in collaboration with individuals representing Fujitsu, Google, IBM, Pivotal, Red Hat and SAP, today announced the launch of the Open Service Broker API project. The Open Service Broker API project allows developers, ISVs and SaaS vendors a single, simple, and elegant way to deliver services to applications running within cloud native offerings including Cloud Foundry, OpenShift 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 community has a special interest group defining a service catalog that will integrate with the Open Service Broker API.

“Enterprise architectures remain complex,” said Abby Kearns, Executive Director, Cloud Foundry Foundation. “A consistent model for exposing capabilities to developers across the architecture ensures these organizations focus on developing and deploying applications that truly differentiate their business. We are excited to work with key leaders across multiple organizations to continue to develop this capability.”

“As everything from applications to infrastructure is increasingly built from services — services that are importantly run across a variety of environments — integration becomes a critical consideration,” said Stephen O’Grady, Principal Analyst, RedMonk. “Standardized interfaces such as the Open Service Broker API represent a solution to this problem, as reflected in the broad cross-community support it has attracted to date.”

“With the industry move from infrastructure level management to service level management, there’s demand for an open API for service control,” said Jay Judkowitz, Senior Product Manager, Google. “The availability of Cloud Foundry Foundation’s multi-platform, multi-marketplace API is exactly what our customers need and will be a key building block for successful multi-cloud adoption.”

“We consistently hear from cloud developers and ISVs that integration and portability of cloud-native application across platforms is critical to their speed and innovation. The new Open Service Broker API project means that developers will be able to leverage the same services across platforms,” said Todd Moore, VP Open Technology, IBM Cloud. “At IBM, we look forward to our continued work in partnership with Cloud Foundry, Cloud Native Computing Foundation and their ecosystem members to drive integration and portability of cloud-native applications with the new Open Service Broker API.”

“In a digital world, widely adopted and easy-to-use interfaces are the cornerstone of collaboration and interoperability,” said Wolfgang Ries, CMO, Fujitsu Enabling Software Technology. “The Open Service Broker API is an industry-driven, customer-centric, standardization effort aiming to reach these goals. It is a step towards filling the gap that currently exists in the cloud native landscape.”

“Cloud-native applications are built as compositions of services. A key value to this modern design is the ability to focus on the core business-differentiating value of your application while reusing common services, whether internal, platform provided, or third party provided,” said Chris Wright, Vice President and Chief Technologist, Office of Technology, Red Hat. “An open, collaborative incubation effort can provide an Open Service Broker API that gives the industry a standardized way for service providers to make their services available and gives developers an easy way to consume them.”

“Developers build great cloud-native apps thanks to platforms like Cloud Foundry and our rich ecosystem of software partners,” said James Bayer, VP of Product, Cloud Foundry at Pivotal. “The Service Broker API greatly simplifies service interactions for developers, and by having other platforms use this innovation, our customers will benefit from an even larger ecosystem of marketplace providers.”

“As a platinum member of the Cloud Foundry Foundation, we are excited about the launch of the Open Service Broker API project,” said Björn Goerke, President SAP HANA Cloud Platform at SAP SE. “With this industry-wide standardization, we can provide our customers and partners our extensive portfolio of business services through an open API in any supporting cloud platform.”

“By standardizing the industry on the Open Service Broker API, end users of cloud-native application platforms will have the benefits of service catalog interoperability across platforms and an increased growth in adoption by the ISV and cloud provider industry,” said Chip Childers, CTO, Cloud Foundry Foundation. “We have already seen the Kubernetes community begin to adopt the existing Cloud Foundry version of the API, and we look forward to this cross ecosystem collaboration move toward the shared standard.”

The Service Broker API accelerates the expansion of the global cloud ecosystem by providing a single path for developers to add services to applications. Now developers can write and configure against a single API and reach many developers across multiple platforms. For more information on the Open Service Broker API initiative, visit: https://openservicebrokerapi.org//. You can also join the Twitter chat on December 13 at 2pm ET: https://www.crowdchat.net/appserviceschat

About Cloud Foundry Foundation
The Cloud Foundry Foundation is an independent non-profit organization formed to sustain the development, promotion and adoption of Cloud Foundry as the industry standard platform for cloud applications. Cloud Foundry makes it faster and easier to build, test, deploy and scale applications. Cloud Foundry is an Apache 2.0 licensed project available on Github: https://github.com/cloudfoundry. To learn more, visit: http://www.cloudfoundry.org.

###

Red Hat is a trademark of Red Hat, Inc. in the U.S. and other countries.

Contact:
Jessica Rampen
Cloud Foundry Foundation
pr@cloudfoundryfoundation.org
650-787-3548