The `Service` data model - blueprint
Proposal
After several user interviews, we can draw a few conclusions on how users understand what a Service. The interviews revealed many details and we should come up with a user flow and data model that fits the learned insights. To help with designing the solution, we should specify the data and its connections to other data in GitLab.
Insights learned
- Services are defined at the project level
- A single project can hold multiple services
- We should be able to list services at group and organization levels.
- Services can be filtered by metadata (e.g. tenant, region). These could vary by customer or even by group.
- Services are tied to environments. Every service might be present in multiple environments and every environment might host multiple services. Not every service is expected to present in every environment and no environment is expected to host all the services.
- A service is a logical concept that groups several resources.
- A service is typically deployed independently of other services. A service is typically deployed in its entirety.
- Deployments in the interviews happened using CI via
Helm
,helmfiles
or Flux and aHelmRelease
- Even in Kubernetes, there might be other tools (Kustomize, vanilla manifests) to deploy a service
- Outside of Kubernetes other tools might be used. e.g. Runway deploys using Terraform
- Deployments in the interviews happened using CI via
- Metrics related to a service should be customizable and configurable by project maintainers (developers?). Metrics might differ from service to service both in the query and in the meaning. (e.g. traffic does not make sense for a queue)
- Metrics should integrate with various external tools, like OpenTelemetry/Prometheus, Datadog, etc
- We want to connect a Deployment of a service to the MRs, containers, packages, linter results included in the Release
- A service contains a bunch of links to external (or internal) pages
Prior art
Edited by Viktor Nagy (GitLab)