a9s Service Broker
This section describes the operation of the a9s Service Broker component.
Overview
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 -- a list of services the 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
Duty
The a9s Service Broker is responsible to receive requests from the Platform (provisioning, binding, ...) and act on it. It is the first contact and responder to any request.
The a9s Service Broker has its own database where it will store information about the services instances deployed and their states.
Example
Let's make a concrete example out of this, on a Cloud Foundry Platform.
Let's assume that you want to create a postgreSQL service.
In order to do so, you would use the CLI command cf create-service.
cf create-service a9s-postgresql10 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-postgresql10 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:
- SPI
- 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 service requested (Redis, 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 services. As a consequence, their are independent SPI for Redis, 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 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.