Many large organizations deploy Cloud Foundry atop the public cloud to deliver superior business outcomes. The app platform has proven to be a terrific way to adopt public cloud in an efficient, expedient, and secure fashion.
There’s another benefit to deploying atop the public cloud—easy access to innovative, first-party services. Indeed, application developers building microservices to run on Cloud Foundry are keen to mix and match backing services from the public cloud to best suit a given use case.
Now, Cloud Foundry adopters have a new way to access services from the top clouds: Cloud Service Broker.
The basics of Cloud Service Broker
The broker is an open source project; find it on GitHub. Check out the readme to get started.
In the meantime, some things you need to know about the Cloud Service Broker include:
-
It’s a common service broker for multiple public clouds – Cloud Service Broker decouples the service broker functionality from the catalog of services that it exposes. So instead of using multiple brokers, you can just use one!
-
It’s easily extensible – Don’t see the public cloud service you want? Quickly and easily add it yourself!
-
It reduces risk, with unified credential management – CredHub encrypts and manages all the secrets associated with your use of cloud services.
-
It’s easy and safe to migrate – Use a simple workflow to move service instances from your incumbent brokers onto the Cloud Service Broker.
Cloud Service Broker features two technologies that deliver this slick user experience: Terraform and brokerpaks.
Thanks to the power of Terraform, the community can now rally around a single broker. The broker can manage any service exposed by Terraform providers for each public cloud ecosystem. When unique attributes of public cloud services are simply configuration details—rather than an entirely different code base—you enjoy lower operational complexity.
With brokerpaks (courtesy of Google), anyone can add a new cloud service to Cloud Service Broker. According to the project homepage, “a brokerpak is a zip package that contains bundled versions of Terraform, service definitions (as Terraform modules), Terraform providers, and source code for regulatory compliance.” These Terraform templates are then packaged as brokerpaks to be consumed by the broker.
Cloud Service Broker currently supports the following services:
|
GCP |
Azure |
AWS |
Now that you know what Cloud Service Broker is (and why you should use it in your Cloud Foundry environments, including cf-for-k8s), let's examine how it works.
A look inside Cloud Service Broker
Cloud Service Broker is an extension of the GCP Service Broker, which adheres to the Open Service Broker API (OSBAPI). (For those unfamiliar with the functionality of a service broker, see the architecture diagram in the Cloud Foundry docs.)
Cloud Service Broker overcomes some of the complexity in working with different cloud brokers for different clouds. In addition to reviewing the diagram that shows how it all works, note three things about the broker:
-
It manages state using a dedicated MySQL database.
-
It is cloud-agnostic. As long as your target public cloud has a Terraform provider, services can be provisioned via a common interface using standard cf CLI commands.
-
It can be configured to support custom brokerpaks stored in any blob store. The services offered, and how they are configured, are largely self-serve.
How to add a new service to the broker
Don’t see your favorite cloud service as part of the broker yet? Follow the relatively straightforward process of extending Cloud Service Broker on your own with locally stored brokerpaks. Or better yet, submit a feature request to our Github repository. Once a brokerpak is created, it can be contributed back to the Github repo, where it can be leveraged and modified by others.
CredHub for secrets management
Storing sensitive data such as certificates and passwords is critical for any deployment, and CredHub has proved to be a working solution for open source and commercial Cloud Foundry deployments alike. CredHub can store encrypted data and provide it to services, apps, and end users.
With that in mind, Cloud Service Broker leverages CredHub for credentials management by default. Which means platform operators can limit access to sensitive account credentials and secrets. To find out more about CredHub, check out the docs.
Bind-time credentials
With security in mind, we’ve also configured the broker to provide unique credentials to each application at bind time. This increases auditability for platform operators and gives developers more granular access to services. Most importantly, Cloud Service Broker blends these security enhancements with a developer self-service.
Showback and chargeback
For platform teams that use a service account to support Cloud Foundry deployments at scale, tracking which service instances belong to which teams can be frustrating. To that end, each and every service you instantiate with Cloud Service Broker gets automatically tagged with the org and space that correspond to it. You can also add custom tags to your deployed service instances.
Install Cloud Service Broker today!
Cloud Service Broker is now a public beta live on Github. We’re working to build a strong open source community around the broker by being as responsive and accessible as possible!
Join the project on GitHub; doing so is also the best way to request a feature or report a bug. You can find us in the #cloudservicebroker-beta channel of the Cloud Foundry Slack instance. (Tag me in your channel message @Omer Bensaadon.) Our team is busy building out a catalog of our customers’ most requested services and features. You can see what we’ve built and what we’re working on now in our Public Roadmap Trello board.
We look forward to hearing from you!
*Note that there is no commitment or obligation that beta features will become generally available.
This article may contain hyperlinks to non-VMware websites that are created and maintained by third parties who are solely responsible for the content on such websites.
