The Cloud Foundry Foundation is spearheading an effort to create APIs for connecting applications to cloud-platform services. This involves getting collaborators to work on a piece of not-so-special software that each of them would otherwise have to develop.
Its origins are in the service broker API that’s been in use since the Cloud Foundry platform-as-a-service (PaaS) was born inside VMware in 2010. It lets applications tap into various platform-level functions — a database, a message queue, or maybe Kubernetes cloud orchestration.
Part of the appeal to Cloud Foundry‘s API is that it provides options on how deeply integrated the service and the application should be. The service might be tightly integrated with the application, so that both would always be deployed together. Or the coupling might be loose — read-only access to a database, for instance.
So, why create an open service broker API now? The motivation was that recently, some vendors (especially Google) and platforms (especially Kubernetes) had begun eyeing the service broker API “as the way to solve their own services problems,” says Abby Kearns, executive director of the Cloud Foundry Foundation.
The Open Service Broker API would make Cloud Foundry’s API applicable to other companies and projects. This API isn’t a differentiating factor for anybody’s platform; it’s part of the nuts and bolts that customers don’t see.
An open API would benefit the application developers, too. They wouldn’t have to worry about adjusting their code to fit each platform.
“If you’re a software vendor, you don’t want to write code to every platform. You want to just write once and have it kick ass,” Kearns says.
Cloud Foundry spun out of Pivotal in 2015 as an open source project that has its own foundation but is also affiliated with the Linux Foundation. Pivotal itself is a spinoff of EMC and VMware, created in 2013 to house several projects related to big data and PaaS.