For those who have been using Cloud Foundry (CF) for while you’re probably pretty familiar with the service management side of their platform. It provides application developers with a Marketplace of services to choose from (e.g. a database). They can then ask for an instance of that service to be created and then connected up to their applications. This relatively simple concept is actually quite a big deal.

First, for the developer, this means they can focus on the business logic of their app and not have to worry about the details involved with deploying and managing a critical service they need. This will all be handled for them – either by their cloud provider or by a 3rd party service provider. This also includes not having to worry about where its hosted, how its backed-up, etc… To the developers its “just there” and ready to be used.

Additionally, for the service provider this gives them an on-ramp to new customers. People are much more likely to try something out if the pain of installing it and managing it is removed from the picture. Many of the CF services that are offering in publicly hosted CF offerings (such as Bluemix) offer a “free tier”. This means that with minimal effort people can provision and “kick the tires” a large variety of services. If they like them and want more than what the free tier offers then money will be involved. The service provider has just increased the changes of a potential new customer.

Behind the scenes of all of this are the CF to Service APIs. In other words, the CF Service Broker APIs. These are the very simple, and straightforward, APIs that CF expects each service owner (broker) to support in order to be available in their Marketplace.

So, why mention all of this “old news”? The Service Brokers APIs have been a part of CF forever. Well, recently CF donated the Service Broker APIs, to the Open Service Broker API project. The goal of this project is to broaden the scope of this API definition so that other Cloud platforms (such as Kubernetes) can support it as well. This means that service providers can now make their services available (ideally w/o any code changes) to both a CF and Kubernetes platform. This also means that app developers will get a similar user experience in both platforms with respect to connecting up to these services. While the exact user-interaction model will be slightly different between CF and Kubernetes (after all they are different platforms), the high-level concepts will the same between them. So, the learning curve (or migration between the two) is minimal.

During next month’s CF Summit in Santa Clara I, along with Shannon Coen from Pivotal, will be presenting on this exciting new development and what you can expect from the Open Service Broker API in the future. We’ll also briefly talk about how Kubernetes is adopting this technology and how it is exposing it to their users as well.

Hope to see you there!

1 comment on"CF’s Service Broker API’s Next Round…"

  1. […] Additionally, for the service provider this gives them an on-ramp to new customers. People are much more likely to try something out if the pain of installing it and managing it is removed from the picture. Many of the CF services that are offering in publicly hosted CF offerings (such as Bluemix) offer a “free tier”. This means that with minimal effort people can provision and “kick the tires” a large variety of services. If they like them and want more than what the free tier offers then money will be involved. The service provider has just increased the changes of a potential new customer. [IBM.com] […]

Join The Discussion

Your email address will not be published. Required fields are marked *