Why you’re doing service catalogs wrong
summary
Argues that service catalogs must be built incrementally and as side effects of solving real problems — start by solving alert routing, access and onboarding and the catalog emerges as data rather than as a monolithic project. Shows concrete tooling choices: small Go package metadata, YAML or Notion backstops, Google groups and Backstage for surface, and tradeoffs between chasing 3,000 entries and focusing on one team of ~10 to get value in weeks not months. Demonstrates that working routing + paging prevents data rot and actually works.
AI-written summary · about
chapters (8)
- 0:00Service catalogs intro
- 3:56Catalog pitfalls
- 9:15Three catalog problems
- 11:01Start small, deliver value
- 14:39Catalog data decay
- 18:09Rethinking catalogs
- 21:00Building Incident.io catalog
- 23:06Key takeaways
related talks
19mWhy You’re (Probably) Doing Service Catalogs Wrong
01h 02mTools for simplified large scale systems
30mEverything Is A Product...
24mThe Lifecycle of A Service
38mMicroservices, a bittersweet symphony
40mKill "Microservices" before its too late
06mChoose Your Own Adventure
30mWorking with DBAs in a DevOps World