About the On-Demand Services SDK
Service brokers let developers create service instances in their development spaces that they can call from their code. To do this, the brokers provide an interface between the Cloud Controller and the add-on software service that they represent. The service can run internal or external to a CF deployment, but the service broker always runs inside the cloud.
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 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 services marketplace, which developers access with
cf marketplace or through the Pivotal Cloud Foundry (PCF) Apps Manager.
On PCF, cloud operators make software services available to developers by finding them on Pivotal Network and then installing and configuring them through a tile interface in the Ops Manager Installation Dashboard. 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.
When you deploy PCF, you must create a statically defined network to host the component virtual machines that constitute the PCF infrastructure.
PCF components, like the Cloud Controller and UAA, run on this infrastructure network. In PCF v2.0 and earlier, on-demand PCF services require that you host them on a network that runs separately from this network.
Cloud operators pre-provision service instances from Ops Manager. Then, for each service, Ops Manager allocates and recovers static IP addresses from a pre-defined block of addresses.
To enable on-demand services in PCF v2.0 and earlier, operators must create a service networks in Ops Manager Director and select the Service Network checkbox. Operators then can select the service network to host on-demand service instances when they configure the tile for that service.
On-demand PCF services rely on the BOSH 2.0 ability to dynamically deploy VMs in a dedicated network. The on-demand service broker uses this capability to create single-tenant service instances in a dedicated service network.
On-demand services use the dynamically-provisioned service network to host the single-tenant worker VMs that run as service instances within development spaces. This architecture lets developers provision IaaS resources for their service instances at creation time, rather than the operator pre-provisioning a fixed quantity of IaaS resources when they deploy the service broker.
By making services single-tenant, where each instance runs on a dedicated VM rather than sharing VMs with unrelated processes, on-demand services eliminate the “noisy neighbor” problem when one application hogs resources on a shared cluster. Single-tenant services can also support regulatory compliance where sensitive data must be compartmentalized across separate machines.
An on-demand service splits its operations between the default network and the service network. Shared components of the service, such as executive controllers and databases, run centrally on the default network along with the Cloud Controller, UAA, and other PCF components. The worker pool deployed to specific spaces runs 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.
The on-demand services SDK is an SDK you can use to create on-demand brokers for single-tenant service offerings.
The on-demand services SDK simplifies broker and tile authoring, and is the standard approach for both Pivotal internal services teams and Pivotal partner independent software vendors (ISVs) to develop on-demand services for PCF.
The ODB SDK provides a generic on-demand broker (ODB) that answers API calls from the Cloud Controller. The service author plugs service-specific functionality into the ODB SDK via an executable called a Service Adapter. For more information about the responsibilities of service authors, please see Creating the Service Author Deliverables.
No additional or third-party components other than the service broker and the BOSH release for the service itself are required. This simplifies the setup. Everything is done through the single install process. This approach also simplifies support because there are fewer moving parts, and your customer’s network needs less customizing of DNS rules and additional firewall ports.
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.
A service adapter is a binary that is called out by the ODB when it wants to do service-specific tasks.
The above diagram 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, 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 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.
The following procedures outline how to set up, create and maintain a service tile based on the ODB SDK:
- Setting up networking — The operators ensure that network rules are set up to allow the necessary communication between components.
- Setting up your BOSH director — The operators ensure that minimum versions of Cloud Foundry and BOSH are available.
- Creating the Service Author Deliverables — The service authors provide their deliverables.
- Deploying an On-Demand Broker — The operators upload their releases and write a manifest.