What Is a Service?¶

The SRE team introduced the concept of a Service to help teams rethink how their Applications are defined within KNMI, and to make service boundaries more explicit and intentional.

Relation Between Application and Service¶

A Service is a part of an Application. An Application can consist of one or more Services.

For example, the Application weather-api could consist of the Services public-weather-api, internal-weather-api, and weather-data-feed, each consumed by different external clients.

graph LR
    A[Application: weather-api] --> B[Service: public-weather-api]
    A --> C[Service: internal-weather-api]
    A --> D[Service: weather-data-feed]

Note

As stated in the following Guidelines section, the recommended default is a one-to-one mapping between Application and Service. Only split into multiple Services when different external clients depend on distinct parts of your Application.

Guidelines¶

As a starting point, it is recommended to use a one-to-one mapping between an Application and a Service. Only split an Application into multiple Services when there is a clear need and justification.

The definition of a Service is not static, but in general it has the following characteristics:

Single-Team Ownership¶

A Service is owned by a single team. If a KNMI Application contains a distinct part that is owned by a different team, that part is a strong candidate to become a separate Service within a KNMI Application.

External Clients¶

A Service is consumed by one or more external clients. “External” can mean other teams within KNMI, not just external customers.

A useful rule of thumb for defining a Service boundary is whether a specific set of resources is relied upon by external consumers. If other teams depend on a part of your Application being available, it likely deserves its own Service definition with dedicated Service Level Indicators (SLIs) and Service Level Objectives (SLOs).

For example, if you expose an API that is consumed by other teams, defining this API as a separate Service makes sense, as its availability directly impacts others. If the API is only used internally by your own Application (e.g. frontend ↔ backend), it usually does not make sense to define a separate Service. In that case, model the distinction using the component label.

These guidelines are intended to provide direction; every situation can be discussed with the SRE team.