In the previous post I wrote about what reusable services in Cloud Foundry are, why we should take advantage of them. I also discussed how reusable services can be discovered in service marketplace, what are service instances and how to create them and use them for your application hosted in the Cloud Foundry. In this post we
will go one level deep and understand how such a reusable service can be created and published in the service marketplace, what are service brokers and how the Cloud Foundry platform communicates with the service broker and the service instances. For that we need to know what is a Cloud Controller and What are Service Brokers.
What is a Cloud Controller?
It is a central component in the cloud foundry platform that handles every call to the Cloud Foundry platform. When a user issues commands to the Cloud Foundry platform the command reaches to the Cloud Controller as API calls and the Cloud Controller responds with proper action as necessary.
What is a Service Broker?
In Cloud Foundry, services are communicated and integrated through API calls. There should be an application that can accept some predefined API calls and act on the requests. Whenever an end user issues commands to the platform the Cloud Controller receives the calls then it needs to dispatch the requests to the application known to it. Therefore the application needs to be registered to the platform so that the Cloud Controller Knows it and the application should offer the standard APIs for the Cloud Controller to be called. These applications that are registered and known to the Cloud Controller are known as Service Brokers. For each reusable service there should be one Service Broker registered.
A service broker needs to be created to be able to create a reusable service. The service broker implements the ServiceBroker API and are responsible for
1. Advertising a catalog of service offerings to the platform through service marketplace
2. Advertising a catalog of service plans to the platform through service marketplace
3. Acting on the requests that come from the platform for provisioning (creating), binding, unbinding, and deprovisioning(deleting) service instances.
For a service broker The cloud platform is the client. Whenever a command is issued by the end user for creating, deleting, binding and unbinding a service instance of a reusable service the cloud platform identifies the corresponding service broker from its database and calls the corresponding APIs of the service broker.
When provisioning is done on a reusable service, the service broker reserves a resource on the reusable service. This is called a service instance. What is a service instance depends on the kind of the service. As an example, it can be a database or an account on a web application. At the same time an entry is made with the service instance name for the user. This service instance name is a reference for the user. The user can delete the service instance, bind the service instance to or unbind the service instance from the application. The cloud controller creates an ID for each service instance, and saves it against the service broker in its database. That's how the cloud controller knows which service broker to contact when delete, update, bind, rebind is performed on the service instance by the end user.
This interaction between the Cloud Controller and the Service Broker is depicted in the picture. This picture is taken from the Cloud Foundry documentation. While registering a Service Broker the credentials also need to be given to the platform. The Cloud Controller uses the credentials to authorize itself against the Service Broker. The credentials are stored in the ccdb.
As explained earlier, the above picture shows the commands issued by the end user to the platform are accepted by the Cloud Controller and the corresponding API calls the Cloud Controller issues to the Service Broker.
To be able to access a service instance the application developer needs to bind it to the application. That allows the credentials needed by the application to become available in the VCAP_SERVICES environment variable. The Cloud Controller injects the credentials in the VCAP_SERVICES environment variable as part of the bind operation. This is also shown in the picture. The same happens when we create service keys, we can get the information under a service key that is injected to the VCAP_SERVICES.
It is up to the service developers how they want to develop the Service Broker. Service developers need to implement the Service Broker APIs according to the expectation of the Cloud Foundry platform. A Service Broker can be created for each reusable service or an existing Service Broker can be extended with the required APIs. It is also up to the Service developer what action needs to be taken or what resources need to be reserved for each service instance. How the APIs are built and what tasks they do in the backend.
Service developers can follow the Open Service Broker API documentation. It has all specification that need to be followed to develop a Service Broker. For example, the headers to be used in the APi calls, the structure of json request and response bodies for each API for each operation are described. Let's look at the service catalog that needs to be exposed by the Service Broker. The service metadata is needed so that the service can be uniquely identified and displayed in the service marketplace. The /v2/catalog endpoint returns a list of all services available on the Service Broker. The Cloud Foundry Platform queries this endpoint from all Service Brokers to fetch the details which the platform will show to the platform users. The fields that need to be populated as a response of the GET request to this endpoint by the Service Broker are name, id, description, tag, bindable, metadata and many more. You can get the details from the documentation.
At last, An individual Service Broker may support one or many platforms using different URL prefixes and credentials. One of such platforms is cloud foundry. Another example of a platform can be a Kubernetes cluster.
In this post I have discussed how a reusable service works internally using a Service Broker along with Cloud Controller and how the service instances are managed. I have also briefly mentioned how a Service Broker have to be implemented.