About On-Demand Brokers
This topic provides information about on-demand brokers for people who want to create on-demand service tiles for Pivotal Cloud Foundry (PCF).
Service brokers let developers create service instances in their development spaces that they can call from their code.
Cloud Foundry Service Brokers
Cloud Foundry Service Brokers provide an interface between the Cloud Controller and the add-on software service that they represent. The service broker works by providing an API which the Cloud Controller calls to create service instances, bind them to apps, and perform other operations. Cloud Foundry service brokers are implemented as HTTP servers that conform to the Open Service Broker API.
In addition to providing an API, a service broker publishes a service catalog
that may include multiple service plans, such as a free tier and a metered tier.
Brokers register their service plans with the Cloud Controller to populate the Marketplace,
which developers access with
cf marketplace or through the Pivotal Cloud Foundry (PCF) Apps Manager.
On PCF, operators find services on Pivotal Network and install and configure them through a tile interface in the Ops Manager Installation Dashboard to make them available to developers. Installing a service tile creates a service broker, registers it with the Cloud Controller, and publishes the service plans that the broker offers. Developers can then create service instances in their spaces and bind them to their apps.
The central element behind a service tile is the service broker, but the tile software includes other components that make the service easy for operators to install and maintain and easy for developers to use. These components include configuration layouts, upgrade rules, lifecycle errands, and BOSH manifests for deploying the service instances.
The on-demand services SDK provides a generic on-demand broker (ODB) that answers API calls from the Cloud Controller.
Service authors add service-specific functionality to the on-demand services SDK through an executable called a Service Adapter. These components combine to create a BOSH deployment. For more information about BOSH deployments, see What is a Deployment.
Tile authors customize the tile interface used by operators. The tile consumes the BOSH deployment to generate a BOSH manifest for deploying on-demand instances of the service. The diagram below illustrates this process.
The on-demand services SDK imposes no constraints on the service authors’ ability to offer new functionality or expose configuration options in their service plans, such as rate limiting and external load balancers.
There are several roles involved with creating and managing on-demand service tiles. These roles can be separate or combined. This section provides a summary of the responsibilities for each role.
Service authors write and maintain the service adapter. For more information about service author responsibilities, see Service Author Deliverables.
Tile authors determine which configuration options to expose to Ops Manager operators, create the tile, and publish it on Pivotal Network. For more information, see Creating an On-Demand Service Tile.
Operators deploy and maintain the broker. They also manage access control for Cloud Foundry (CF) developers. This documentation provides information for two types of operator, Ops Manager operators and BOSH operators. These roles may be separate or combined. The following describes each type of operator:
- Ops Manager Operator: Uses the Ops Manager UI to configure plans and provide service specific configurations. For more information about configuring a specific service, see the Pivotal Documentation for the service.
- BOSH Operator: Creates and modifies the on-demand service broker manifest to provide service specific configurations. For more information about operator responsibilities, see Operator Responsibilities.
When you deploy Pivotal Application Service (PAS), you must create a statically defined network to host the component VMs that make up the infrastructure. Components, such as Cloud Controller and UAA, run on this infrastructure network.
On-demand services might require you to host them on a separate network from the default network. You can also deploy on-demand services on a separate service networks to meet your own security requirements.
PAS supports dynamic networking. Operators can use dynamic networking with asynchronous service provisioning to define dynamically-provisioned service networks. For more information, see Default Network and Service Network below.
On-demand services are enabled by default on all networks. Operators can optionally create separate networks to host services in BOSH Director. Operators can select which network hosts on-demand service instances when they configure the tile for that service.
On-demand services use BOSH to dynamically deploy VMs and create single-tenant service instances in a dedicated network. On-demand services use the dynamically-provisioned service network to host single-tenant worker VMs. These worker VMs run as service instances within development spaces.
This on-demand architecture has the following advantages:
- Developers can provision IaaS resources for their services instances when the instances are created. This removes the need for operators to pre-provision a fixed amount of IaaS resources when they deploy the service broker.
- Service instances run on a dedicated VM and do not share VMs with unrelated processes. This removes the “noisy neighbor” problem, where an app monopolizes resources on a shared cluster.
- Single-tenant services can support regulatory compliances where sensitive data must be separated across different machines.
An on-demand service separates operations between the default network and the service network. Shared service components, such as executive controllers and databases, Cloud Controller, UAA, and other on-demand components, run on the default network. Worker pools deployed to specific spaces run on the service network.
The diagram below shows worker VMs in an on-demand service instance running on a separate services network, while other components run on the default network.
A service adapter is a binary that is called by the ODB for service-specific tasks. The diagram below shows where responsibility lies for each aspect of the ODB workflow.
The service author can focus on building the BOSH release of their service and provide a service adapter binary that manages manifest generation, schema generation, binding, and unbinding. The ODB manages all interactions with Cloud Foundry and BOSH.
Thanks to BOSH v2, service authors can define resources globally (in Cloud Config). This makes manifests portable across BOSH Cloud Provider Interfaces (CPIs) and lets them be substantially smaller than old-style manifests. The ODB takes advantage of other BOSH v2 features as well, including dynamic IP management, availability zones, and links through which deployed BOSH instances can access IP addresses and other information from other instances.
Once an on-demand tile is authored and distributed, the operator installs and configures it the same way they do with any other Pivotal products. In the process, they select which of the tile’s available service plans to offer their developers.
This documentation provides information for operators and developers in the following sections.
This section provides information about how to operate an on-demand broker for BOSH operators and Ops Manager operators.
This section provides information about creating on-demand services and tiles.