Services Toolkit Terminology and User roles

Terminology

Service

  • A broad, high-level term used to describe something used in either the development of, or running of Application Workloads
  • Often, but not exclusively, synonymous with the concept of a Backing Service as defined by The Twelve Factor App *… any service the app consumes over the network as part of its normal operation

Examples

  • A PostgreSQL service (implemented as a Kubernetes Operator provided by Tanzu Data Services)
  • A PostgreSQL service (implemented as a process running on an Application Developer’s laptop)
  • Object storage (implemented as SaaS running on AWS)
  • AppSSO

Service Resource

  • Any Kubernetes resource which provides (partial) functionality related to a Service

Examples

  • A Kubernetes resource with API Kind PostgreSQL
  • A Kubernetes resource with API Kind FirewallRule
  • A Kubernetes resource with API Kind RabbitmqUser
  • A Kubernetes resource with API Kind ClientRegistration providing access to an App SSO service
  • A Kubernetes resource with API Kind Secret containing credentials and connectivity information for a Service (which may or may not be running on the cluster itself)

Provisioned Service

  • This term is defined in the Service Binding Specification for Kubernetes.
    • Essentially, any Service Resource which defines a .status.binding.name which points to a Secret in the same namespace containing credentials and connectivity information for the resource
  • See Provisioned Service for the full definition.

Service Binding

  • A mechanism in which Service Instance credentials and other related connectivity information are communicated to Application Workloads in an automated way

Examples

  • The Service Binding concept implemented through the ServiceBinding Service Resource provided by https://github.com/vmware-tanzu/servicebinding

Service Instance

  • An abstraction over one or a group of interrelated Service Resources that together provide the expected functionality for a particular service
  • One of the Service Resource that make up an Instance must either adhere to Provisioned Service or be a Secret conforming to the Service Binding Specification for Kubernetes
    • This guarantees that Service Instances can be Claimed and subsequently bound to Application Workloads
  • Service Instances are made discoverable through Service Instance Classes

Examples

  • The RabbitmqCluster Service Resource provided by the RabbitMQ Cluster Operator
    • This Service Resource adheres to Provisioned Service, as such any RabbitmqCluster resource on a Kubernetes cluster could be considered a Service Instance
  • A logical grouping of the following Service Resources could be said to form a single “AWS RDS” Service Instance:
    • An AWS RDS DBInstance
    • An AWS RDS DBSubnetGroup
    • A Carvel SecretTemplate configured to produce a Secret conforming to the Service Binding Specification for Kubernetes
    • A Role, RoleBinding and ServiceAccount
  • A Kubernetes Secret conforming to the Service Binding Specification for Kubernetes containing credentials for a Service running external to the cluster

Service Instance Class

  • Provides a way to describe “classes” (i.e. categories) of Service Instances
  • Allows for discovery of Service Instances belonging to the class
  • Refers to a pool of Service Instances
  • Different classes might map to different Services or to different configurations of the same Service

Examples

  • A ClusterInstanceClass named “rabbitmq-dev” pointing to all RabbitmqCluster Service Resources configured with .spec.replicas=1 identified by label class: rmq-dev
  • A ClusterInstanceClass named “rabbitmq-prod” pointing to all RabbitmqCluster Service Resources configured with .spec.replicas=3 identified by label class: rmq-prod
  • A ClusterInstanceClass named “aws-rds-postgresql” pointing to Secrets conformant with the Binding Specification and identified by label class: aws-rds

Resource Claim

  • A mechanism in which requests for Service Instances can be declared and fulfilled without requiring detailed knowledge of the Service Instances themselves

Examples

  • The Resource Claim concept implemented through the ResourceClaim Service Resource provided by https://gitlab.eng.vmware.com/services-control-plane/services-toolkit/

Claimable Service Instance

  • Any Service Instance which is permitted to be claimed via a Resource Claim from a namespace, taking into consideration:
    • Location (namespace) of the Service Instance in relation to the location (namespace) of the Resource Claim
    • Any matching Resource Claim Policies
    • Exclusivity of Resource Claims (i.e. a given instance can only be claimed once at a time)

Examples

  • A RabbitmqCluster Service Resource residing in the same namespace as a Resource Claim and which has not already been claimed by another Resource Claim could be said to be a “Claimable Service Instance”
  • A RabbitmqCluster Service Resource residing in a different namespace to a Resource Claim, for which a matching Resource Claim Policy exists, and for which has not already been claimed by another Resource Claim could be said to be a “Claimable Service Instance”
  • A RabbitmqCluster Service Resource residing in the same namespace as a Resource Claim which has already been claimed could not be said to be a “Claimable Service Instance” due to the exclusive nature of Resource Claims

Service Resource Lifecycle API

  • Any Kubernetes API that can be used to manage the life cycle (CRUD) of a Service Resource

Examples

  • rabbitmqclusters.rabbitmq.com/v1beta1

Service Cluster

Workload Cluster

User Roles

Services Toolkit caters to the following user roles.

It is important to note that these User Roles are not User Personas - it is perfectly possible (and even expected) that one human being could be associated with many User Roles at any given time. The User Roles align to Tanzu Application Platform’s User Roles, and the Services Toolkit team is primarily responsible for defining the Service Operator role.

The User Roles listed here consist of a short description as well as the Jobs To Be Done for the role. For detailed information on corresponding RBAC associated with each role, please refer to Detailed role permissions breakdown.

Application Developer (AD)

Encompasses both app-editor and app-viewer roles as defined by Tanzu Application Platform

Jobs To Be Done

  • Bind and unbind Application Workloads to/from Resource Claims
  • Get, List, Watch ResourceClaims
  • Get, List, Watch ClusterInstanceClasses associated with ResourceClaims

Application Operator (AO)

Encompasses the app-operator role as defined by Tanzu Application Platform

Jobs To Be Done

  • Discover and learn about Service Instance Classes available on a cluster
  • Discover Claimable Service Instances associated with Service Instance Classes
  • Lifecycle management (CRUD) of Resource Claims

Service Operator (SO)

Coming Soon.

check-circle-line exclamation-circle-line close-line
Scroll to top icon