This topic describes the key concepts and terms you need to know about consuming services on Tanzu Application Platform (commonly known as TAP).
As part of Tanzu Application Platform, you can work with backing services such as RabbitMQ, PostgreSQL, and MySQL among others. The most common use of services is binding an application workload to a service instance.
When working with services on Tanzu Application Platform, you must be familiar with service instances, service bindings, and resource claims. This section provides a brief overview of each of these key concepts.
A service instance is a logical grouping of one or more Kubernetes resources
that together expose a known capability through a well-defined interface. For
example, a theoretical MySQL service instance might consist of a
MySQLDatabase and a MySQLUser resource. When considering compatibility of
service instances for Tanzu Application Platform, one of the resources of a
service instance must adhere to the Service Binding for Kubernetes
specification.
Service binding refers to a mechanism in which connectivity information, such as service instance credentials, and connectivity information, such as host and port, are automatically communicated to application workloads. Tanzu Application Platform uses a standard named Service Binding for Kubernetes to implement this mechanism. See this standard to fully understand the services aspect of Tanzu Application Platform.
Resource claims are inspired in part by Persistent Volume Claims. For more information, see the Kubernetes documentation. Resource claims provide a mechanism for users to claim service instances on a cluster, while also decoupling the life cycle of application workloads and service instances.
The following list of Kubernetes operators expose APIs that integrate well with Tanzu Application Platform:
- VMware RabbitMQ for Kubernetes.
- VMware SQL with Postgres for Kubernetes.
- VMware SQL with MySQL for Kubernetes.
Compatibility of a service with Tanzu Application Platform ranges on a scale between fully compatible and incompatible. The minimum requirement for compatibility is that there must be a declarative, Kubernetes-based API on which at least one API resource type adheres to the Provisioned Service duck type defined by the Service Binding Specification for Kubernetes in GitHub. This duck type includes any resource type with the following schema:
status:
binding:
name: # stringThe value of .status.binding.name must point to a Secret in the same
namespace. The Secret contains required credentials and connectivity
information for the resource.
Typically, APIs that include these resource types are installed onto the Tanzu Application Platform cluster as Kubernetes operators. These Kubernetes operators provide custom resource definitions (CRDs) and corresponding controllers to reconcile the resources of the CRDs, as is the case with the three Kubernetes operators listed earlier.
For services that do not provide a resource adhering to the Service Binding Specification for Kubernetes, you might still be able to provide configurations allowing such services to integrate with Tanzu Application Platform. For an example of how to do this for Amazon AWS RDS, see the tutorial Integrating cloud services into Tanzu Application Platform.
It is important to understand the user roles for services on Tanzu Application Platform and the responsibilities assumed by each. The following table describes each user role.
| User role | Exists as a default role in Tanzu Application Platform? | Responsibilities |
|---|---|---|
| Service operator | Yes - service-operator |
|
| Application operator | Yes - app-operator | Life cycle management (CRUD) of resource claims |
| Application developer | Yes - app-editor and app-viewer | Binding service instances to application workloads |
Apply what you've learned: