--- bodyclass: docs headline: Service Model layout: docs sidenav: doc-side-concepts-nav.html title: Service Model type: markdown --- {% capture overview %} The page explains Istio's overall service model. {% endcapture %} {% capture body %} The Istio manager serves as an interface between the user and Istio, collecting configuration, validating it and propagating it to various components. It abstracts platform-specific implementation details from the mixer and proxies, providing them with an abstract representation of user's services that is independent of the underlying platform. The model described below assumes a microservice-based application owned by a single tenant. **Istio-managed service:** Modern cloud applications are created by composing together independent sets of services. Individual services are referenced by their fully-qualified domain name (FQDN) and one or more ports where the service is listening for connections. **Platform-agnostic internal representation:** The Istio model of a microservice is independent of how it is represented in the underlying platform (Kubernetes, Mesos, CloudFoundry, etc.). Platform-specific adapters are responsible for populating the internal model representation with various fields, from the metadata found in the platform. ## Multiple versions of a service Istio introduces the concept of a service version, which is a finer-grained way to subdivide service instances by versions (`v1`, `v2`) or environment (`staging`, `prod`). These variants are not necessarily different API versions: they could be iterative changes to the same service, deployed in different environments (prod, staging, dev, etc.). Common scenarios where this occurs include A/B testing, canary rollouts, etc. Istio [routing rules](../reference/rule-dsl.md) can refer to the service versions, to provide additional control over traffic between services. **Tags** Each version of a service can be differentiated by a unique set of tags associated with the version. Tags are simple key value pairs assigned to the instances of a particular service version, i.e., all instances of the same version must have the same tags. ## Populating the abstract service model Where possible, Istio leverages the service registration and discovery mechanism provided by the underlying platform to populate its abstract service model. Most container platforms come built-in with a service registry (e.g., kubernetes, mesos) where a pod specification can contain all the version related tags. Upon launching the pod, the platform automatically registers the pod with the registry along with the tags. In other platforms, a dedicated service registration agent might be needed to automatically register the service with a service registration/discovery solution like Consul, etc. At the moment, Istio integrates readily with the Kubernetes service registry and automatically discovers various services, their pods etc., and groups the pods into unique sets -- each set representing a service version. In future, Istio will add support for pulling in similar information from Mesos registry and *potentially* other registries. ## Communication between services Clients of a service have no knowledge of different versions of the service. They can continue to access the services using the hostname/IP address of the service. The Istio Proxy intercepts and forwards all requests/responses between the client and the service. The actual choice of the service version is determined dynamically by the Istio Proxy based on the routing rules set forth by the operator. This model enables the application code to decouple itself from the evolution of its dependent services, while providing other benefits as well (see [mixer](mixer.md)). Routing rules allow the proxy to select a version based on criterion such as (headers, url, etc.), tags associated with source/destination and/or by weights assigned to each version. Note that Istio does not provide a DNS. Applications can try to resolve the FQDN using the DNS service present in the underlying platform (kube-dns, mesos-dns, etc.). {% endcapture %} {% include templates/concept.md %}