github twitter linkedin instagram email
The Anatomy of the On-Demand Service Broker
12 May 2018
3 minutes read

As seen here, it is relatively straightforward to write your own service broker. However, to make it create instances on-demand requires considerably more effort, as the broker would need to deploy a brand new service instance on request.

The on-demand service broker release is an open-source project that, by leveraging BOSH, simplifies the process of writing on-demand service brokers. In a nutshell, ODB frees the Service Author of the responsibility of respecting the OSBAPI Spec and handling HTTP requests, allowing them to focus on the behaviour that is specific for their services.

The ODB release packages the On-demand service broker, a generic on-demand broker that is designed to work in with BOSH, and the brokerapi, a Golang implementation of the v2 Open Service Broker API. To use the on-demand broker, the Service Author needs to build what is called the Service Adapter. As ODB uses BOSH behind the scenes, it’s also necessary to have a BOSH release for the desired service.

The Service Adapter

The Service Adapter is an executable that’s invoked by ODB and should implement the following subcommands:

  1. generate-manifest: responsible for generating and outputting to the stdout a BOSH manifest for the service instance being deployed (or upgraded).
  2. dashboard-url: generates an URL for a web-based management interface for the service instance. Optional.
  3. generate-plan-schema: generates a JSON schema to validate user-provided parameters (see here). Optional.
  4. create-binding: outputs a JSON representing a binding. Usually goes to the service instance and create a set of credentials that will be returned.
  5. delete-binding: deletes an existing binding, usually by invalidating or deleting users/credentials.

The service adapter must implement all subcommands, even when the output is optional (e.g. dashboard-url; in this case, it should exit with status code 10). ODB will inspect the exit code to determine the success of the invocation using the following table:

Exit Code Status
0 Success
10 Subcommand not implemented
non-zero code Failure

When exiting with a non-zero status code, the on-demand broker will send the contents of stdout back to the client, and log both stdout and stderr for the BOSH operator. For that reason, service adapter authors should not log sensitive data.

If building the Service Adapter in Golang, one can use the on-demand services SDK to speed up the development process. The SDK allows the Service Author to focus on implementing the logic behind the subcommands, and will handle the command line invocation, parsing the input parameters, serializing the response and handling error cases.

In the next post, we’ll go deeper into the subcommands and start to write our own Service Adapter. See you soon!



Back to posts


comments powered by Disqus