This topic provides information about on-demand brokers for people who want to use On-Demand Services SDK (also known as ODB) to create on-demand service tiles for Tanzu Operations Manager.
Cloud Foundry Service Brokers and Tanzu Operations Manager Tiles
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 can 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 Apps Manager.
Tanzu Operations Manager Tiles
Operators find services on VMware Tanzu Network and install and configure them through a tile interface in the Tanzu Operations 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.
On-Demand Services SDK and the On-Demand Broker
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 in the BOSH documentation.
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.
On-Demand Service Roles
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 Author
Service authors write and maintain the service adapter. For more information about service author responsibilities, see Service Author Deliverables.
Tile Author
Tile authors determine which configuration options to expose to Tanzu Operations Manager operators, create the tile, and publish it on VMware Tanzu Network. For more information, see Creating an On-Demand Service Tile.
Operator
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, Tanzu Operations Manager operators and BOSH operators. These roles can be separate or combined. The following describes each type of operator:
- Tanzu Operations Manager Operator: Uses the Tanzu Operations Manager UI to configure plans and provide service specific configurations. For more information about configuring a specific service, see the VMware 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.
Service Network Requirement
When you deploy VMware Tanzu Application Service for VMs (TAS for VMs), 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.
TAS for VMs supports dynamic networking. You can use dynamic networking with asynchronous service provisioning to define dynamically-provisioned service networks. For more information, see Default network and service network.
On-Demand services are enabled by default on all networks. You can create separate networks to host services in BOSH Director, if required. You can select which network hosts on-demand service instances when you configure the tile for that service.
Default Network and Service Network
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 shows worker VMs in an on-demand service instance running on a separate services network, while other components run on the default network.
Service Adapters
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 (AZ), and links through which deployed BOSH instances can access IP addresses and other information from other instances.
After an on-demand tile is authored and distributed, the operator installs and configures it the same way they do with any other VMware products. In the process, they select which of the tile’s available service plans to offer their developers.
Get Started Using ODB
This documentation provides information for operators and developers in the following sections.
Operator Guide
This section provides information about how to operate an on-demand broker for BOSH operators and Tanzu Operations Manager operators.
Service and Tile Developer Guide
This section provides information about creating on-demand services and tiles.
