Closed scothis closed 3 years ago
Keeping this as a draft at the moment because I expect it might be contentious, but it's otherwise ready to go.
cc @baijum (I can't tag you as a reviewer for some reason)
I understand that in many modern architectures the term application
is meant to represent some kind of grouping. However, I think the legacy use of application
to mean "a piece of business logic code" is still too strong to move away from.
Even from the first two sentences of the workload k8s doc we find evidence of this association:
A workload is an application running on Kubernetes.
So if we're in the context of k8s, workload == application.
Whether your workload is a single component or several that work together, on Kubernetes you run it inside a set of pods
We often try to move away from application
when describing a single component, but here it seems workload
is also meant to describe either scenario.
I think the legacy use of
application
to mean "a piece of business logic code" is still too strong to move away from.
A good bit of this is skating to where I think the puck will be, rather than where it is today. As applications grow into systems of microservices and other components, the "workload" name will help distinguish exactly what is being bound.
When thinking about the set of components that comprise an application, the ServiceBinding
resource is one of them. To be both part of a logical application and reference a different component of that logical application as an "application" is a bit odd.
I always use "application workloads" while talking about service binding given that "application" is anyway a vague term in Kubernetes. 🤷♂️
On Tue, Mar 9, 2021, 14:56 Scott Andrews notifications@github.com wrote:
I think the legacy use of application to mean "a piece of business logic code" is still too strong to move away from.
A good bit of this is skating to where I think the puck will be, rather than where it is today. As applications grow into systems of microservices and other components, the "workload" name will help distinguish exactly what is being bound.
When thinking about the set of components that comprise an application, the ServiceBinding resource is one of them. To be both part of a logical application and reference a different component of that logical application as an "application" is a bit odd.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/k8s-service-bindings/spec/pull/148#issuecomment-794376645, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEFEADHWSQJTYXAHQDDLG3TCZVO5ANCNFSM4Y2OCGZQ .
I checked a few web user interfaces and noticed "Workload" is used everywhere.
Looks like "Workload" is commonly used in the Kubernetes ecosystem.
I think it depend with which lenses you look at these docs. 😄
For example, this k8s page talks about injecting data into an application, which is exactly what the ServiceBindng.spec.application
element aims to do. It didn't say injecting data into a workload.
There are active uses of both "application" and "workload" in the wild. In that regard, both terms are correct.
I still prefer "workload" over "application" as it is more precise.
Rebased
In Kubernetes an application[1][2] is a loose collection of workloads[3] and accompaning resources. What we have been refering to as "applications" are technically "workloads".
Every semantic reference to application has been updated except for common phrases like "application developer" and "application performance monitoring".