Cloud Foundry’s Service Broker API Role in Kubernetes and Open Source Platforms
Those that have been following the work of the Kubernetes community closely may have noticed that a new special interest group (SIG) was created to bring support of the Cloud Foundry Service Broker capabilities into that platform.
What you may not know is that the Cloud Foundry community has been working hard to help make this a reality.
Yes, you read that correctly.
So what exactly is the Cloud Foundry Service Broker API? Think of it as 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.
Cloud Foundry’s Service Broker API
The idea was first introduced when Cloud Foundry was open sourced by VMware in 2011. At that time, there were five “fixed” services offered to developers deploying into Cloud Foundry: MySQL, PostgreSQL, RabbitMQ, MongoDB and Redis. The developer experience was kept to a simple set of operations: create, bind, unbind and delete. This straightforward abstraction proved to work exceptionally well for developers deploying applications to Cloud Foundry, but the internal implementation was not as clean as the team would have liked.
In 2013, the service broker API implementation within Cloud Foundry was completely re-written. Version 2.0 of the API solved many of the implementation issues observed with the initial approach, shifting to a clear “client/server” model. From this point forward, the Cloud Foundry Cloud Controller (the brains of the Cloud Foundry control plane) was a client of the API. Individual services became server-side implementations. This allowed services to be implemented either entirely independent from the Cloud Foundry platform, or within it.
As the v2 API evolved over time, one of the largest jumps in capability was the addition of an asynchronous service provisioning workflow. Prior to the addition of the asynchronous capability, service brokers were expected to complete provisioning of a new service instance within a short window or risk the user receiving a timeout error.
While the initial use case for a service in Cloud Foundry was constrained to providing applications with access to database and message queue instances, the introduction and rapid evolution of the v2 API has brought about a slew of new real-world use cases. The Cloud Foundry community quickly started creating service broker implementations for everything from cloud-based services (orchestrate.io as an example), to legacy system API bridges.
The service broker API also proved useful for adding platform-layer capabilities to an application, with the best example being the addition of Route Services to Cloud Foundry. We have even begun to see large cloud providers like Google and Microsoft expose their native platform capabilities via the API. This growing ecosystem of service providers has quickly become one of the major attractions for organizations considering adopting a platform like Cloud Foundry.
How Does This Relate to the CNCF and Kubernetes?
Earlier this year, we noticed something interesting. Projects like Deis were beginning to consider adopting the Cloud Foundry Service Broker API openly. We found ourselves in multiple informal conversations around how other platforms might be able to integrate with Cloud Foundry more effectively. We knew there was an emerging opportunity to help the whole industry.
Over the last six months, the Cloud Foundry Foundation and Cloud Foundry project leads from Pivotal have been working closely with a team from organizations like Google, Engine Yard and Red Hat, as well as several organizations with engineers working on projects in both the Cloud Native Computing Foundation and the Cloud Foundry Foundation. Companies like IBM, Fujitsu and others are actively involved. These efforts have been under the guise of an informal “working group” between the two foundations. What you see within the Kubernetes community is that effort beginning to bear fruit in a material way.
Within the Cloud Foundry community, we believe that we are playing a positive sum game in the open source platform space. What helps one, helps all. Our sincere desire is that, by offering the Cloud Foundry Service Broker API up as an industry standard, we help to dramatically increase the integration opportunities for everyone. In the end, our collective mission is to move the state of industry forward through the creation of software and platforms that make delivering applications faster and better.
Cloud Native Computing Foundation and the Cloud Foundry Foundation are sponsors of The New Stack.
Feature Image via Pixabay.
