Effective Communication

As the saying goes, naming in programming is one of the more, if not the most, arduous tasks to get right for everyone concerned. It is crucial for effective communication and the efficient organization of referenced structures, which is why Name is a first-class citizen in the OpenSignals open application programming interface. The Name interface serves two needs: to define service structures and access environment values.

Namespaces / Name Parts

In OpenSignals, a name is effectively a namespace – a sequence of name parts or string-valued nodes in a tree. The string “banking.teller” when converted into a name, becomes two names. The first name has a value of “banking” with an empty prefix. The second name, the actual result for the transformation, is a name with a prefix property referring to the first name and a string value of “teller”. If we add both “deposit” and “withdraw” to the teller name reference, we end up with two additional name references, both having a prefix referencing teller.

Hierarchices / Aggregation

As a Name is treated much like a constant, the string value for a part should be viewed likewise. It is via this hierarchical naming scheme that OpenSignals supports the modeling of aggregated services. If a service is created for both the deposit and withdraw name references, there is an implicit grouping of these services under the service teller and, in turn, banking. This does not preclude other grouping forms, such as at the context level or within management tooling via boundaries.

Service Decomposition

In OpenSignals, a service is an identifiable activity of interest that can be decomposed into more refined activity levels within a service and across other service compositions. Developers writing instrumentation need only worry about the logical service names; the underlying OpenSignals provider is required to capture the environment, which itself can be nested and exposed via the context.

Lightweight Identifiers

It is important to note that names are context-independent. The same name can be used across different contexts within the same process or across processes. The context and its named property values map capture some aspect of the environment, the more physical or deployment components of the model, and the service name the logical and far more permanent aspects.

Context Separation

Comparing the OpenSignals approach with popular metric systems that use both a name and a set (or bag) of labels (or tags), the context is where infrastructure metadata resides cleanly separated from the service naming and the derived service level model. The context is not entirely lost; it is not always relevant and helpful to be promoted. It is best to see the context and the state therein as transient and the service naming as semi-permanent and the basis for the ongoing operational management of systems.

Model ≠ Map

The simplicity of the OpenSignals naming scheme and the clean separation of both context and environment from a logical service level model means that system engineers and developers do not get bogged down in the component categorization and typing that many of the observability and application performance monitoring solutions force unnecessarily on them – component types such as environment, cluster, region, domain, host, container, pod, service, entry point, URL, port, and so on. The model is not the map.