Cloud Foundry CAB, Dec 2016: Open Service Broker API and Diego 1.0
Word has been going around for a few months of members of the Cloud Foundry community working with the Kubernetes loyalists on some sort of a strategic initiative. This became real this week, and it turns out that the conversation centered around the Cloud Foundry Service Broker API, and that there’s much more than Kubernetes involved.
The public announcement of the Open Service Broker API, replete with an eponymous website and logo, came on Tuesday. The discussion of it highlighted this month’s Cloud Foundry Foundation Community Advisory Board (CAB) call. Pivotal’s Shannon Coen chairs the initiative’s eight-person project management committee (PMC), which also includes representatives from Fujitsu, Google, IBM, SAP, and Red Hat.
Yes, Red Hat. (By the way, former CF Foundation exec Stormy Peters recently took a new position with Red Hat, so maybe we’ll see her back in the Cloud Foundry community soon.)
Shannon explained that everyone involved realizes this initiative has the potential to expand the marketplaces for competing technologies, but that it’s viewed as an “everybody wins” collaboration rather than a zero-sum game. He said the announcement was a culmination of about six months of working together.
Why they did it
“The Kubernetes community wanted to provide a marketplace of services for Kubernetes and other platforms,” according to Shannon. “Since then, we have largely been in agreement about the next features we’d like to add to the service broker API, and during that time the Kubernetes community has been building a marketplace of services that would leverage the broker API.”
He added that the respective teams have been collaborating on enhancements (though none have been completed yet) and working to “genericize” specifications for the open broker API from the Cloud Foundry documentation. He said there’s a document rewrite underway, with “the first milestone of removing generic content for the broker spec to another repo, while maintaining a good documentation experience for the Cloud Foundry community.”
“We view this as an ‘everybody wins’ collaboration.” —Shannon Coen, Pivotal
There are two versions of the API in development. “Version 2.11 has been made for CAPI to support brokers declaring plans as bindable,” Shannon said, with a second one known as 2.12 “to include brokers to declare the schema for a parameters field to allow platform clients like the CLI to provide a better experience for custom options for provisioning and updating services and other features. This is (part of) an effort to remove ‘CF-ism’ from the broker API.”
Looks like “game on” with Amazon and Microsoft
The Cloud Foundry community’s tendrils now extend to Google as well, with former CF Foundation head Sam Ramji recently moving there as a VP of product management. He wasn’t mentioned during the call, but Shannon noted that there are discussions about how “Google wants to provision services from marketplaces with which you don’t have a business relationship. Give your credit card to a Google marketplace and use a token you get from them to provision services from other marketplaces. This is sort of a federated model.”
So, Google management no doubt remains fond of its progeny Kubernetes, and looks to be intensifying its efforts to win public-cloud business against market leader Amazon and strong competitor Microsoft. The Open Service Broker API initiative, centered around Cloud Foundry and Red Hat OpenShift, also breathes new life into the idea of platform (PaaS) as a key, separate component of cloud computing, rather than being subsumed into infrastructure (IaaS). Huzzah!
Meanwhile, Diego 1.0 arrives
Eric said the team got Diego to manage 250,000 containers (again, as projected last month) and went ahead with the release.
“This formally starts the end-of-life timeline for DEA architecture.”
—Eric Malm, Pivotal
“We expect to start removing it officially from cf-release and related systems in mid-May,” he added.
Guillaume Berche of Orange asked about moving off of etcd and Consul, noting that the question wasn’t directly related to the Diego announcement. “Consul is hard to orchestrate with BOSH, and so has resulted in increased fragility,” he said.”The dependency is a little too heavyweight, so we’re hoping to improve by getting off of it.”
In acknowledging the issue, Eric referred to a document that addresses current thinking. He also referred to a recent work on a relevant CLI tool called cf-dot that interacts with Diego, and said community involvement is encouraged!
And it’s time for CF-Extensions
Then it was time to talk about Cloud Foundry extensions.
IBM’s affable Dr. Max (Michael Maximilien), who leads the CAB calls, devoted a separate meeting to extensions last week, and would have had the main CAB storyline in some months. He didn’t seem the last perturbed as he led the extensions discussion, noting that “for example, if someone wants to know about the buildpacks we have, they’re very hard to find. So, we’re going to create the CF-Extensions hub, which will contain these extension points.”
During both meetings, Dr. Max noted that “extensions are becoming more important as Cloud Foundry matures and companies wish to differentiate their offerings. Different companies are (now) making real money from this platform.” In addition to buildpacks, extensions include APIs, plugins, and components.
He stressed that the website for the new hub “is not intended to keep the extension points themselves but just catalog them. So, if you have a buildpack, we’ll have a pointer to where it exists. This is a place to go and find to where to go.”
A recap of the Extensions meeting is available.
SAP proposes an Abacus service broker
Dr. Max also made mention of a proposed Abacus service broker. The proposal comes from SAP’s Hristo Iliev, a prolific contributor to the Cloud Foundry community.
Abacus is a Cloud Foundry metering and aggregation service. The project “aims to create a service broker that automates the tasks connected with operating and integrating new resource providers with Abacus,” according to the proposal. “The MVP broker will create a UAA client (for securely reporting usage) and enable upload of a resource provider plan. Future targets are service dashboard to upload, edit, validate, and activate Abacus plans, as well as integration of business processes for review and approval of metering and pricing plans.”
Another key focus of the proposal is to integrate it with CRM systems (a key SAP business). The entire proposal is available here.
Special project: Sawmill
The idea of taking a look at independent Cloud Foundry projects was raised during October’s CAB call, and this month saw the presentation of such a thing from Stark & Wayne. The company’s Geoff Franks outlined a log aggregation service that “puts all the logs in the same stream (so to speak). If I’m an operator with x-number of nodes in a BOSH deployment and I want to troubleshoot, then I want to look at them live.”
Geoff described the project as “a lightweight thing that doesn’t require a lot of infrastructure—such as (for example) Elastic Search would require.” He also noted that it doesn’t buffer anything, but just delivers its information in a live stream.
Dr. Max said he’s seen “10 to 15 projects from Stark and Wayne (alone), so you’ll start to see new projects every month.”
Dr. Max closed by saying “it’s been an exciting year,” and that it was good to see a recent uptick in CAB call attendance, to around 30 people. “For next year, everyone brings a friend to the call, so we can grow to 60, and then take over the world.”
The quest for world domination will pick up again next year, on Wednesday, January 11 at 8 a.m. Pacific Time. As always, a good way to keep up is to follow the Slack channel.
P.S. Today, the Cloud Foundry Foundation has announced call for papers for the Silicon Valley Summit 2017.
To stay tuned with the latest updates, subscribe to our blog or follow @altoros.