Open skonto opened 3 years ago
This proposal was already brought up (with a different motivation): https://github.com/open-telemetry/opentelemetry-specification/pull/1480
I think my arguments against the change still stand (copied from the mentioned PR):
code.function
that can arise for example. I think "serverless", "serverless_function", "faas_instance", "cloud_function" might be better names, but I am not convinced renaming is worth it.There are cases where function frameworks run on premise that are not covered by the current spec.
The name "faas" may not be a perfect fit, but I think they are still covered. Also, while from the company perspective, the function framework may not be provided "as a service" when running on premise, from a developers perspective, it is a service they can use 😃
What might be helpful: adding a value to cloud.provider and faas.invoked_provider to signify on-premise.
@Oberon00
This proposal was already brought up (with a different motivation): #1480
Good to know I missed that. Thanks
Also, while from the company perspective, the function framework may not be provided "as a service" when running on premise, from a developers perspective, it is a service they can use I think "serverless", "serverless_function", "faas_instance", "cloud_function" might be better names, but I am not convinced renaming is worth it.
For the operator though who runs stuff on-premise the term faas is a bit unrelated (typically it is about cloud managed services with a specific cost model etc) but it could be ok if we expand the definition or at least make it clear somehow. Btw people could run services both on-premise and on the cloud and we might want to make a distinction and this is where the proposal above defining the provider might be useful.
Regarding the confusion for code function it was solved easily. I dont see a real issue if a domain prefix is used like serverless
the same way code
was used. I think this would be much better than relying on:
I think when most users read "faas" they will not know what it is.
and then let them find out what that is. Reason is there are users out there who are aware of cloud computing and they will identify faas quickly.
I think the term faas applies equally to cloud and on prem. When on prem, there is still a "service" provided to other applications that manages their serverless functions.
Should an industry term such as "faas" be used in the semantic conventions? We don't use "IaaS" or "PaaS", as far as I can see, to refer to anything matching those terms. What happens when "faas", as an industry term, falls out of favor and is replaced with another?
I'd be interested to have your thoughts on this @rakyll.
I agree it makes sense for "on-premise" to be an option for a provider. Should a separate issue be opened for this?
What are you trying to achieve?
I am defining the metrics specs for Openshift Serverless and I am looking to use a standard approach. The Opentelemetry spec currently covers only the case of a FaaS using
faas
as the prefix for the corresponding naming conventions for resources, traces, metrics etc. I see a better fit to change this to something more generic likefunc
instead. There are cases where function frameworks run on premise that are not covered by the current spec.What did you expect to see? A more generic definition for function metrics.
Additional context. Previously discussed here.