Service (services.serving.knative.dev) is very confusing.

[n3wscott]

/area API /kind dev /kind doc

tl;dr: Rename Service to Function.

Argument

Taking Core Kubernetes' Service resource, and comparing it to the Knative Service resource, I am very confused about the naming of this object. And some will say this is a bikeshed topic but disagree: If future users/customers are unable to quickly understand the abstractions being made inside of Knative, they will have a hard time getting value from the project.

Currently we would need to say the following: The Service manages a Route and the Configuration. A Configuration produces one or more Revisions. The Route exposes the Revision via a Service.

Proposal

Rename Service to Function.

Then we could say the following: The Function manages a Route and the Configuration. A Configuration produces one or more Revisions. The Route exposes the Revision via a Service.

At the end of the day, the user is wanting to use the project to host functions, and (a super cool feature of this project!!!) is that you can define your Function from external source and the machine serves that for you!!! NEAT! Likely even in the typical non-k8s way to talk about services, what is being represented by a Revision is not a full application (aka, not really a service). An application is likely assembled from many Functions and external services. (Compare that to: An application assembled from many services and external services.)

There is likely history here, please educate me.

[n3wscott]

the UX is much improved with the new version of kubectl.

[stroebitzer]

What about ServiceContext?

[scothis]

Speaking with a number of users at SpringOne about Knative, the name "Service" initially confuses just about everyone who has familiarity with Kubernetes. It is also causing confusion as new users join the working groups. This confusion is actively hostile to growing understanding amongst users who are new to Knative.

Short names help with the UX in kubectl, but don't help when discussing Knative with other humans. Even in conversations among those of us who understand the distinction, if the word "service" is not qualified we have to ask "did you mean a knative service or a k8s service?"

Within riff we are considering sidestepping the issue by either using Configuration and Route directly instead of Service, or creating a higher level CRD that treats Service as an implementation detail.

[asciimike]

@scothis thanks for the additional data points.

On the third point:

• We've considered Service to be a developer first primitive, if operators feel comfortable managing k8s resources directly I don't think that's a flaw in the API, just our attempt to provide for both groups in an easy way. The Service can be set to manual mode which allows for manipulation of those resources independent of the Service or ignored altogether if it's that objectionable.
• Is the issue in Riff one of functionality (Service doesn't do what Riff needs) or naming (omg another Service)? If it's the former, what is it missing? Or do you simply view it as superfluous?

[steren]

Would prefixing all Knative resource names with a "K" help? "KService", "KRevision", "KRoute", "KConfiguration"?

(This was suggested in https://github.com/knative/serving/issues/1397#issuecomment-409375931, and this is what was implemented for the short names)

[mattmoor]

The ship has sailed on renaming this. Going to close this.

[marun]

I wish k8s would discourage the creation of types with kind/plural names that duplicate that of core types (i.e. types that don't have a group). Even if the practice wasn't likely to cause user confusion, it complicates the life of tool developers.