Co-authored by Nima Kaviani
One of the integral design choices in Cloud Foundry (CF) has been to treat services as first-class citizens of the environment. Cloud Foundry spearheaded an effort to provide a common interface layer between applications and services so that applications can easily create and integrate with services through a common service API layer. Last year, the work done in CF was extracted and turned into a new standard, the Open Service Broker API (OSBAPI). The idea of OSBAPI is to decouple applications from the services they use in such a way that services can be maintained and managed independently from the applications. Yet, applications can easily bind, rebind, and use services through the exposed APIs. The creation of OSBAPI is in line with the industry direction of hybrid cloud and giving developers choices through the decoupling of services and applications.
To highlight the capabilities of the Service Broker API, Nima Kaviani and Swetha Repakula of IBM’s open source cloud team recently spoke at the IBM Dev Meetup in New York City. The first half of the presentation was focused on understanding the basic architecture of Cloud Foundry and the steps that the platform was taking in order to deploy an app. Nima started by giving an overview of the Cloud Foundry architecture and how it can help by allowing developers to focus solely on the primary job of deploying and managing their applications while Cloud Foundry takes care of the heavy lifting of managing the infrastructure. He took a sample CF app from the IBM Cloud Foundry application catalog and showed how easily the app could be deployed through the UI. Nima then introduced the sample-http-app developed by the Diego team that showcased the correct implementation of the termination behavior for a cloud web application upon receiving a termination signal from the platform. Taking the same app, he highlighted the important aspects of deploying such as the choice of buildpack, memory, disk size, etc, and how to specify environment variables that would be accessible in the application container. Finally, in the last part of his presentation, Nima showed how easily services can be created and used by applications on the IBM cloud. Through the UI, Nima created a sample cloudant database, found the credentials through a few clicks and manually passed them to a modified version of the sample-http-app to communicate with the database to store and retrieve data. IBM Cloud has made creating, managing, and manipulating services easy for users by providing UIs to simplify the process.
The next half of the presentation offered an overview of the Open Service Broker API itself and how easily CF users can attach services to their applications. Swetha took a simple voting app that needed a database to store results and showed how to search for offerings through the CF CLI. After deciding on a database, she outlined the environment variable that CF app developers can use to interact with services in general. Using the CLI, she connected the same database to a separate app that would publish the results illustrating the ease in binding multiple applications to the same service. However, not all CF environments have the services a developer needs, or a developer may already have provisioned services they want to bring the platform. For those use cases, CF created user-provided services, which is not part of the OSBAPI. Through the CLI, Swetha demonstrated how to create user-provided services and how easily they are integrated into the CF environment. Finally, she ended the presentation with the last part of the OSBAPI standard, registration. Swetha demonstrated how service brokers could be registered in a CF environment and the process to make those services available to the platforms’ developers.
The attendees at the meetup were highly engaged and were particularly interested in how easily these services and processes could work in other platforms, namely Kubernetes.Would you like to learn more? Watch the recording of this tech talk to see it all in action.