Clarification on backends section

[abonas]

It seems that there is a conceptual change here compared to Istio for example - every version of a service is a separate service with a completely separate name check https://github.com/deislabs/smi-spec/blob/master/traffic-split.md#example-implementation

web-current and web-next - so the differentiation is merely textual in service names? so there is no one service with multiple versions, but several services with separate names? Also, if we look at the required work process in this example, when a user wants to deploy the "web-next", the current version already should be running under the name web-current, or renamed to it. And then the web-next will need at some point be renamed to web-current? isn't this more maintenance? Less filter/search abilities that can be done on labels rather than searching inside strings of a name?

[surajssd]

• This is not specific to Istio and a generic specification. Istio has been chosen to start implementing TrafficSplit first.

• web-current and web-next - so the differentiation is merely textual in service names? so there is no one service with multiple versions, but several services with separate names?

The difference is mere textual in this config. But those k8s services are pointing to different versions of same application (which are deployed as different deployments as mentioned in https://github.com/deislabs/smi-spec/blob/master/traffic-split.md#workflow)

• Probably checkout the working example of the TrafficSplit Istio implementation here https://github.com/deislabs/smi-adapter-istio/tree/master/docs/smi-trafficsplit and let us know your thoughts, if this still feels cumbersome to you?

[abonas]

• Probably checkout the working example of the TrafficSplit Istio implementation here https://github.com/deislabs/smi-adapter-istio/tree/master/docs/smi-trafficsplit and let us know your thoughts, if this still feels cumbersome to you?

yes, it is still not intuitive. the example also states :

Create a new deployment named foobar-v2, with labels: app: foobar, version: v2

So user does need to add a label with version in addition to a service with a different name? there is something unclear in how users are guided to create multiple versions of the same service. nor is it making it easy to filter by versions.

[christian-posta]

@abonas so basically all of the filtering is done in the k8s svc objects and being reused in TrafficSplit.

The user is responsible to name their deployments and services accordingly (ie, foobar-v1 deploy/svc, foobar-v2 deploy/svc, etc) while clients use the "root svc" with it's FQDN (e.g., http://foobar). All of the labels/selectors are still the same as in k8s w/o svc mesh.

In this approach, I honestly think it simplifies managing multiple versions of a service using the baked in k8s constructs.

[grampelberg]

As a +1 to @christian-posta, instead of creating an arbitrary new type of solution (like istio's VirtualService), we're purposely building on top of k8s native primitives. If we removed the extra service from the picture (for each leaf), the spec would be required to fully support selectors. That's extra functionality for implementations and users to get their heads around. Instead, by basing this on services and how all k8s applications talk to each other by default, we're able to make something that is easy to implement, works the way users expect k8s to work and is extremely configurable for testing (imagine sending requests to the v2 service before switching anything over instead of doing some crazy pod selector to do it).

[abonas]

If 2 separate services with different names are representing the same microservice (but its different versions), how are they expected to be recognized as versions of the same service? Is it by the 'app' label?

[christian-posta]

Yah, any label(s) that together identity the app, excluding any version-specific labels. Example:

svc/foobar-v1 with labels: app=foobar env=prod version=v1

svc/foobar-v2 with labels: app=foobar env=prod version=v1

the root svc:

svc/foobar with labels: app=foobar env=prod

All clients use svc/foobar

All normal traffic is controlled with SMI constructs affecting the root service (svc/foobar)

Then, you can do things like run smoke tests against svc/foobar-v2 directly without affecting traffic routing. You also eliminate the confusion of "well, v2 in the routing layer uses these selectors while v2 in the deployment layer really means this, and the k8s svc construct could mean something else", etc

[grampelberg]

Also, any traffic that does not originate from a mesh will work normally through svc/foobar (remember, load balancing is a client side concern and not a server side concern).