Skip to main content
Version: 58.0.0

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

a9s SPIs​

SPI stands for Service Providing Interface and its job is to provide the information required in order for the a9s Service Broker to work as expected. Depending on the requested Data Service (KeyValue, PostgreSQL, ...) and the kind of request (provisioning, binding, ...), the SPI will provide different response.

In order to provide better maintainability, scalability and properly separate the concerns, anynines splitted the SPI by Data Service. As a consequence, their are independent SPIs for KeyValue, PostgreSQL and all other services offered by anynines.

a9s SPIs come with TLS (HTTPS) enabled for its API by default.

a9s Deployer​

a9s Deployer is an adapter for any kind of Orchestrator. In the case of a Cloud Foundry installation, it is a Wrapper around BOSH.

The Deployer takes care of the underlying deployment, reflecting the real Service Instance, whenever it is a Virtual Machine (VM) or a Container, via an API.

a9s Deployer comes with TLS (HTTPS) enabled for its API by default.

BOSH​

BOSH is a VM orchestrator.

BOSH is a project that unifies release engineering, deployment, and lifecycle management of small and large-scale cloud software. BOSH can provision and deploy software over hundreds of VMs. It also performs monitoring, failure recovery, and software updates with zero-to-minimal downtime.