Open Service Broker API and Platform Evolution

At Cloud Native Day in Toronto in August, a presentation was given about a proof-of-concept project that would provide a consistent API for platforms to be able to access 3rd-party services. The news of that presentation went mostly under the radar, but it had the potentially to have a significant impact on the future of container-based, cloud-native platforms (such as Red Hat OpenShift). Fast forward 4 months and that significant impact has become a reality, with the formal announcement of the Open Service Broker API [code on GitHub].

The Basics

[From the Press Release] "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’sKubernetes community has a special interest group defining a service catalog that will integrate with the Open Service Broker API."

The true power of open source software is the ability for anyone (individual or group) to engage with the best ideas and work with that software in ways that are beneficial to open communities as well as the commercial markets. The model allows great ideas to come from anywhere, and evolve in new ways over time.

The Open Service Broker API project will take the API framework that has been developed within the Cloud Foundry Foundation and create the necessary adaptations to allow it to work with Kubernetes and other frameworks - all while maintaining API consistency. The project will follow a well-defined and open governance model for contributors and contributions.

What does this mean for Kubernetes and OpenShift? 

Over the last 7+ years, we have seen the "Platform" market evolve a number of times, as the creators of platform technologies began to better understand the needs of the market. In the early days, we saw platforms that were limited by where they could run, or which languages/frameworks they supported, or proprietary implementations. Over time, many platforms become more open, supported a broader set of languages and frameworks, and are being built in more community-centric ways.

It's fair to say that nearly every platform has reached a point in its architecture where it needs to question a core architectural element - whether that's a scheduler/orchestrator, adding polyglot support, replacing homegrown functionality with open community functionality, or something else - the evolution of platforms is fluid and changing as market demands evolve.

From a Red Hat OpenShift, we made a strategic bet on Kubernetes and container standards a few years ago. We could have easily stuck with the internal container scheduling and orchestration technology in v1 and v2 that was being used by many customers, but we saw the benefit to working with a broader community on an important architectural element of the platform. Red Hat OpenShift does this with many other open source projects to deliver the complete functionality of OpenShift - e.g. docker, etcd, ElasticSearch, Fluentd, Kibana, Ceph, Gluster, Open vSwitch, SELinux, etc.

Working closely with the Open Service Broker API project is just another example of where Red Hat is able to contribute to bringing new value to the marketplace. With more and more OpenShift customers deploying with a hybrid cloud architecture and wanting to leverage additional services outside the platform, we believed it was the right time to make those 3rd-party integrations be consistent and based on a common, open standard.

We are excited that the Cloud Foundry Foundation felt that this technology should be more widely deployed, and we're looking forward to the opportunity to bring an open, multi-platform standard for Service Brokerage to the market in 2017.

What does the Open Service Broker API project mean for the marketplace?

Q: Does this announcement mean that Red Hat is now formally joining the Cloud Foundry Foundation (CFF)?

A: No. This announcement and agreement creates a new open source project that is specifically focused on the Open Service Broker API. This project is taking the Cloud Foundry Service Broker API out to a new project (still broadly under Cloud Foundry Foundation (CFF), but branded and managed as its own project under CFF). Participation in this new project does not require any company or contributor to join the CFF or pay any CFF dues. Red Hat’s participation will require contributors to sign a CLA (Contributor License Agreement) with the CFF.

In this New Stack podcast, Abby Kearns (CFF Executive Director) explains the logistics of contributors’ participation in the project http://thenewstack.io/whats-next-for-cloud-foundry-foundation-abby-kearns/ - around the 6min mark in the show. Contributors are NOT required to be part of the CFF or have the dedicated committers like they would normally have with a CFF project. "You don't have to be a member of the CFF, or an employee of a company that's a member of the CFF."

Q: Does this announcement change Red Hat’s product strategy with OpenShift?

A: No. This project will help to build on the success and momentum that Red Hat OpenShift currently has in the marketplace. Red Hat OpenShift has been committed to working with open source projects, communities and standards since the beginning. The Open Service Broker API project will allow Red Hat to expand the existing capabilities of OpenShift to deliver Service Catalog services, as well as deeper integration with 3rd-party services.

Q: Does this announcement change Red Hat’s focus and commitment to the Kubernetes project or the activities of the Cloud Native Computing Foundation (CNCF)?

A: No. Red Hat OpenShift is completely committed to Kubernetes, the continued growth of that project, and delivering the best Enterprise-Ready Kubernetes in the market. The integration between Kubernetes and the Open Service Broker API project will only expand the breadth of capabilities that will be available with Kubernetes and OpenShift.

Q: How will this project improve the functionality of Red Hat OpenShift?

A: The Open Service Broker API project will allow Red Hat to expand the existing capabilities of OpenShift to deliver Service Catalog services, as well as deeper integration with 3rd-party services.

Q: How will customers benefit from this technology being integrated into Red Hat OpenShift or other Kubernetes projects?

A: Red Hat OpenShift has always been focused on delivering an integrated, fully-supported container and cloud native application platform for customers. Red Hat OpenShift will tightly integrate Open Service Broker API capabilities into a seamless experience, to deliver a simplified experience for access services with a Service Catalog and 3rd-party APIs.

Q: What are some common use-cases for this technology?

A: The Open Service Broker API will provide a standard way for cloud native applications running on Kubernetes platforms (e.g. Red Hat OpenShift) to interact with external, 3rd-party services. This should make it easier to integrate applications with public cloud providers (e.g. Database Services, Big Data, Machine Learning, AI, etc.).