Service renaming

[LikeTheSalad]

OpenTelemetry has become the observability data industry standard for several platforms, especially related to backend services, and, while it probably was not foreseeable at the time of its creation, it has become so widely popular that it's now being used for purposes beyond telemetry for backend services, and moved onto other scopes such as mobile apps and web pages too! Which speaks volumes of how fast this community has grown and it's a testament to the hard work and love that has been put into expanding its capabilities.

As it would happen with any growth story though, as time passes by and OpenTelemetry expands and evolves, some of its parts, which were exactly what was needed at the beginning, might not make too much sense anymore, and one important aspect of it that has been discussed in the Client SIG, is the way to refer to an "entity that produces telemetry", be it a backend service, web app or mobile app for example, all of which, at the moment, would be defined as service, based on the current semantic conventions, which has proven to be confusing for people who are starting to adopt OpenTelemetry for non-backend services purposes.

This issue aims to provide a term to identify an "entity that produces telemetry" in a way that wouldn't be tied to any particular environment so that it better represents the wide range of use cases that OpenTelemetry has come to support in time, and hopefully covers any use case that might arise in the future as well. I'm conscious of the longevity of the current term service and how widely adopted it is across existing services and even non-services entities, which most likely won't make this an easy change for sure, though I believe that, based on how fast OpenTelemetry is growing, the longer we wait to make these kinds of changes, the more difficult it will become.

The proposed name to replace it with is origin, more details on what the change would look like in this PR.

[reyang]

This has been discussed before. During the 10/20/2023 TC triage, we decided that the name service has established and should be used for other components such as clients / devices, instead of switching to a different name. As a follow up, we should clarify what service means in the specification.

[LikeTheSalad]

I see, would you mind elaborating a bit on the "established" part? I just would like to better understand the reasoning why everything has to be called a service and what you mentioned kind of sounds like a "That’s the way we’ve always done it" argument which, if that's the case, is just a bit disappointing for a modern project like this one.

[Oberon00]

It's not a disappointing argument. This is part of the specification, one of the main uses of a specification is to have behavior that people can rely on. There is tons of code out there relying on service.name being the name of the service/component/origin/whatever. Changing that means breaking tons of code, most of which is not under the OpenTelemetry project's control.

[LikeTheSalad]

I see, so it's that argument. It's a bit disappointing to me tbh, although I understand that it's difficult to make these kinds of decisions so that's fair enough.

[Oberon00]

You can't bring that argument against any change of course, but "service" is a very fundamental concept and it's marked as stable, which means the OpenTelemetry project did commit to not make breaking changes to it.

[svrnm]

@LikeTheSalad as someone who was involved in an earlier iteration(s) of this discussion (see @t2t2's list here open-telemetry/semantic-conventions#557 (comment)), I see where your disappointment is coming from, but as @Oberon00 stated this is a change that can not be done without a lot of trouble.

A few personal thoughts on this topic:

• As a former web developer I must say, that if I would be asked to set a "service.name" and "service.*" for my frontend app would feel odd but I would comply with it and not think about any longer. I might be looking into the spec why this is the case, so one thing that we should add there to close this chapter is a note about this discussion and the conclusion (as stated by @reyang in Service renaming #3791 (comment)). And at the end, service is not the worst name, my frontend app is a "service" in some way
• As someone who know spent a few years with APM and observability solutions, I must say that having a common name across the building blocks of your larger application is a BIG win. And yes, there could have been better words than service, but because we have it, it makes things on the backend so much easier, e.g. if I would like to do a service map (e.g. look at the servicegraphconnector) you don't need to change code to have your client site (browser, mobile, ...) introduced, because they are just another service. And what about those cases where the "client site" is a service, like a headless browser used for PDF generation? Or, what if you have a smart device that talks to your smartphone app, that talks to your backend, I am fine with having "3 services" vs different things, requiring me to rewrite my analytics...

[mtwo]

Note from the maintainers meeting this week: @jack-berg suggested that we create a canonical issue (or other GitHub artifact) or note in the semantic conventions that describes why 'service' will be so difficult to change at this point, as these discussions surface pretty regularly.

[jack-berg]

Clarifying PR here: open-telemetry/semantic-conventions#630

[svrnm]

@open-telemetry/technical-committee please take a look at this issue once again, the PR was merged and reverted again, is this the right issue to have a continued discussion on the topic or is there another issue that replaces this one? Or is this/will this be covered by the Entities Project?

[jack-berg]

This is covered by the entities project. It aims to answer the same types of questions posed by this issue.

[jack-berg]

@jsuereth / @tigrannajaryan I've added the sig-issue and spec:resource labels to indicate that this is something the entities SIG should cover.