Author Archive

Megan Murawski

Megan Murawski

Megan Murawski

Latest posts by Megan Murawski (see all)

Creating a Cloud Foundry Service Broker

12-factor apps are cool and Cloud Foundry is cool but, we don’t just have to worry about 12 factor apps.  We have legacy apps that we also need to pay attention to.  We believe there should be a way for all of your apps to enjoy the benefits of Cloud Foundry.  We have enabled this by implementing a Service Broker that binds an external storage service.  Before we talk about the creation of the Service Broker we will describe the role of a Service Broker in Cloud Foundry.

Services are integrated with Cloud Foundry by implementing a documented API for which the cloud controller is the client; we call this the Service Broker API.  Service brokers advertise a catalog of service offerings and service plans, as well as interpreting calls for provision (create), bind, unbind, and deprovision (delete).  By externalizing the backend services from the application in a PaaS provides a clear separation that can improve application development. Dev only needs to be able to connect to an external service to consume its APIs. In Cloud Foundry, this interface is “brokered” by the Service Broker.  Some examples of services which are essential to the 12 Factor app are: MySql, Redis, RabbitMQ, and now ScaleIO!

Screen Shot 2016-05-23 at 1.28.26 PM

A service broker sits in between the Cloud Foundry Runtime and the service itself. To create a service broker, you only need to implement the 5 Service Broker APIs: catalog, provision, deprovision, bind and unbind. The service broker essentially translates between the Cloud Controller API and the service’s own API to orchestrate creating a service instance (maybe provisioning a new database or creating a new user), providing the credentials to connect to the service, and disconnecting and deleting the service instance.

The APIs

Catalog is used to fetch the service catalog. This describes the service plans that are available with the backend and any cost.

Provision is used to create the service in the backend. Based on a chosen service plan, this call will actually create the service. In the case of persistence, this is provisioning storage to be used by your applications.

Bind will provide Cloud Foundry runtime with the credentials and configuration to access the service. This allows the application to connect to the service.

Unbind will remove the access credentials from the application’s environment.

Deprovision is used to delete the service on the backend. This could remove an account, delete a database, or in the case of persistence, delete the volume created on provision.

 

Creating the Broker

To create the ScaleIO service broker, we made use of the EMC open source tool Libstorage for communicating with the ScaleIO backend. Libstorage is capable of managing many different storage backends including ScaleIO, XtremIO, Isilon and VMAX in a client/server model.  By adding an API layer on top of Libstorage, we were able to quickly translate between Cloud Foundry API calls and storage APIs on the backend to provide persistence as a service within CF. Like much of the work we do at the EMC Dojo we have open sourced the Service Broker.  If you’d like to download it or get involved, check it out on github!

Follow Us on Twitter

Subscribe to Blog via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.