Skip to main content
Version: Latest

a9s Service Broker

This section describes the operation of the a9s Service Broker component.

Introduction​

The a9s Service Broker is the implementation of the Open Service Broker API. This API is shared between all Service Brokers installed on a Platform (Cloud Foundry or another); it is the basic requirement for the Service Broker to communicate with others components of the Platform and the Platform itself.

Among the requirements for a Service Broker, it needs to provide a Catalog, which is a list of services the a9s Service Broker can provide.

The Open Service Broker API project allows independent software vendors, SaaS providers and developers to easily provide backing services to workloads running on cloud native platforms such as Cloud Foundry.

The specification, which has been adopted by many platforms and thousands of service providers, describes a simple set of API endpoints which can be used to provision, gain access to and managing service offerings.

The project has contributors from Google, IBM, Pivotal, Red Hat, SAP and many other leading cloud companies.

-- Quote from Open Source Broker API

The a9s Service Broker is responsible to receive requests from the Platform (provisioning, binding, ...) and act on it, storing information about the provisioned Service Instances and their states. It is the first contact and responder to any request.

Update a Service Instance​

A common request to the a9s Service Broker is to update a Service Instance. To the a9s Service Broker, this can be one of the following cases:

  • Changing the Service Plan of the Service Instance.
  • Setting/Updating various configuration parameters (set by the user).
  • Maintenance update of the Service Instance.

When updating a Service Instance, the following errors can happen:

  • The Service Plan update is not supported: This happens if an update from the current plan to the new requested plan is not supported by the platform. Repeating the same request will not lead to success. In such a case the error message contains additional information for the Application Developer.
  • A provided configuration parameter is invalid: This error can be caused by various issues with a configuration parameter, for example:
    • The set parameter doesn't exist.
    • The parameter value has the wrong data type, e.g. the value should be a float but an integer was provided.
    • The parameter value is not supported, e.g. the value must be foo or bar but baz was provided. It is worth noting that repeating the same request will not lead to success. In such a case the error message contains additional information for the Application Developer.
  • A maintenance update is available but the Application Developer has blocked automatic maintenance updates: This is the case when an outstanding maintenance update for the Service Instance is available and must be applied first. To continue, the maintenance update must be manually applied first by the Application Developer. In such a case the error message contains additional information for the Application Developer. For more information, see Using a9s Service Dashboard - Update the Service Instance.
  • The Service Instance can not be updated because of an ongoing operation for the Service Instance: This takes place to ensure the integrity of the Service Instance, as another operation with higher priority, for example, a running backup or restore whose interruption could harm the health of the Service Instance. The update can be retried as soon as the operation has finished. In such a case the error message contains additional information for the Application Developer.
  • An unspecified error occurred while updating the Service Instance: This type of error is not tied to a specific root cause, for example, an external API cannot be reached for whatever reason, a bug in a vendored system occurs, etc. The update can be retried in a later time. In such a case the error message does not contain any detailed information to prevent accidental leakage of sensitive data. The Platform Operator will find more information in the logs.

Example​

Let's make a concrete example out of this, on a Cloud Foundry Platform. Let's assume that you want to create an a9s PostgreSQL Service Instance. In order to do so, you would use the CLI command cf create-service.

cf create-service a9s-postgresql13 postgresql-single-small my-service

This command would send a request to Cloud Foundry's Cloud Controller. The Cloud Controller will recognize that the Platform do have a service named a9s-postgresql13 and that it is offered by a9s Service Broker. It will then forward the request to it, leaving him generate the files and further commands required to generate the services requested by you.

note

The Cloud Controller knows the a9s Service Broker because the Service Broker has been registered in the Platform. This is out of the scope of this overview.

If you want to know more about this topic, you can read the official documentation on this topic.

In the presented case, a9s Service Broker will receive a provision request, as described by the Open Service Broker API.

This request will contain certain data that the a9s Service Broker will store in its own database in order to work as expected, and start communicating with the underlying a9s components in the following order:

  1. SPI
  2. Deployer