GitLab Service Catalog
Problem to solve
As companies grow, the services used to support internal and external applications grows alongside the company. As time goes by, it becomes more and more challenging to list and/or document all the running services (along with details such as who owns, where it's deployed, etc) let alone all the information surrounding them.
Development teams often work on creating independent services and they require tooling to stay informed on the status, version, and contacts for other services. Further, Operations team members need access to configuration, runbooks, and escalation contacts for services to aid in troubleshooting when complex systems fail.
Engineers do love challenges but not the type of challenge that requires memorization of tons of information and recall it. This problem is often solved with the use of a service catalog application. GitLab already contains significant information about projects (applications), version, contact as well as infrastructure configuration (instance/group/project kubernetes clusters), runbooks and escalations (incidents).
The infra team describes this problem at lenght on the Service Inventory Catalog page
Users of GitLab could potentially create a service catalog of their own and have GitLab render the contents of their
service-catalog.yml file for easy consumption.
Rendered contents could display under
Operations >> Service Catalog
Permissions and Security
What does success look like, and how can we measure that?
What is the type of buyer?
Links / references
This could perhaps be an upstream dependency that could be leveraged for many apps to show inside an iframe gitlab-ce#59422