Category

Blog

Open Service Broker v2.14 Released

By | Blog

Last month the Open Service Broker API working group released the latest version of the specification, v2.14. This version collects new features, bug fixes and miscellaneous improvements collected over the last 10 months since v2.13. As always, details can be found in the release notes, but you can read about some of the most interesting changes below:

Fetching Service Instances and Bindings
The specification now supports fetching information for previously created Service Instances and Bindings. This presents a range of possibilities for platforms, including fetching credentials (e.g. if they’ve rotated), extended health check information, or previous configuration parameters. Consider a Service Broker that can provision a Redis cluster, where the number of nodes is configurable:

At some later point in time, the operator may determine a need to increase or reduce capacity, but how do they know the current allocation, in order to make a relative adjustment?

The new supported endpoints allow this kind of information for Service Instances and Bindings to be fetched from a Service Broker.

Asynchronous Service Bindings
For some time now, the Open Service Broker API has supported asynchronous flows for Service Instances. This has existed in order to support long running operations, for example, creating or destroying virtual machines. Broker authors now have the ability to support similar operations as part of the Service Binding lifecycle with the familiar Last Operation pattern.

Non-Basic Authentication Methods
Up to this point, the specification only supported Basic Authentication between Platforms and Service Brokers; for some use cases, this may not provide adequate security characteristics, and others already have support for differing authentication schemes. In order to provide the flexibility necessary, we have now extended the Platform to Service Broker Authentication section such that an out of band agreement can be made outside the specification. Details on these can be found in the Platform Features wiki.

OpenAPI 2.0
We now have an OpenAPI document describing the specification!

Compatibility Matrix
We now have a Platform Compatibility document describing which sections of the specification are supported by particular platforms!

Upcoming
You can stay up to date with what the community is working on by checking out the Roadmap & Release Planning project on GitHub.

New Open Service Broker API Videos from Cloud Foundry Summit Europe & Cloud Native Con Europe 2017

By | Blog

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.

Open Service Broker v2.13 has landed

By | Blog

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.

Open Service Broker API: August Face to Face Recap

By | Blog

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.

Announcing the Open Service Broker API v2.12

By | Blog

The first release of the API specification independent from the Cloud Foundry platform

Today, the Open Service Broker API working group is pleased to announce the v2.12 release of the specification. This is the first release of the API specification independent from the Cloud Foundry platform, developed under the guidance of the new working group.

The focus of this release is to enable multiple platforms to leverage the API through deprecating platform specific terminology. This clears a path for more platforms integrating with the OSBAPI.  Additionally, the specification now leverages RFC2119 keywords, meaning consuming service broker authors and platforms can clearly understand the intent of the specification.

Introducing Platform Profiles

To enable platforms to provide platform specific information, for use cases such as billing, we are introducing an additional context field to request body for provisioning a service instance and updating a service instance. To allow for discovery of these platform specific fields, we are providing Platform Profiles. These describe recommended usage patterns for environment-specific extensions and variations. If you are a broker author, please beware that context will replace the organization_guid and space_guid request fields in future versions of the specification. In the interim, you should use both fields to ensure interoperability with old and new platform implementations.

How can I get started?

You can view the updated specification here and get started creating a service broker or platform today. Support for the context field is available today in Kubernetes Service Catalog, and will be coming to a Cloud Foundry release soon.

Why Cloud Foundry is Making the Open Service Broker API Even More Open

By | Blog

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.

service

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.

Twitter Chat: Open Service Broker API & App Services – Join Us Today!

By | Blog

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!

Open Service Broker API Launches as Industry Standard

By | Blog

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