A service is an abstract concept that encapsulates business logic that can be run in a distributed application. A service construct is made of service versions and service instances. Each service maps to multiple service versions, and each service version maps to multiple service instances.
For an illustration of the service hierarchy in Tanzu Service Mesh, see the diagram in the How Does a Tanzu Service Mesh Service Relate to a Kubernetes Service? section.
You can use service versions to manage the life cycle of changes within a service. From time to time, you may need to make changes to a service to improve or expand its functionality. To release the updates in your environment, you create new versions of the service. You need to configure an endpoint for each version and deploy the version through on your platform.
Multiple service versions are commonly used in testing scenarios (such as A/B testing) and canary rollouts.
How Does a Tanzu Service Mesh Service Relate to a Kubernetes Service?
A Tanzu Service Mesh service can represent a business logic microservice where in Kubernetes it can be mapped to any of the following types of workload controllers: Deployments, ReplicaSets, StatefulSets, DaemonSet, Jobs, and CronJob.
In Tanzu Service Mesh, for services running on a Kubernetes cluster, service instances map to Kubernetes pods. Service instances are what get replicated when a service and service version scale horizontally.
In the following diagram, this could be, for example, a service called frontend, which is represented by Tanzu Service Mesh service as an abstract concept. The diagram shows two deployments : Service Version v1 and Service Version v2. Each version has three service instances in the Get All Accounts microservice.
In the future, the Tanzu Service Mesh definition of a service can include software that is run on virtual machines, as an example.
This diagram shows that Tanzu Service Mesh service is at the top of a hierarchy.
