Oh, that last bit about custom App-IDs is so spot on. We tried the "pragmatic path" of creating custom app objects for internal services, but we accidentally created a monster: a sprawling, unmaintained custom app library that became its own legacy problem.
Our mistake was letting anyone create a custom app object with minimal naming standards. We ended up with "App-Backend-API," "BackendApp-v2," and "BckndSvc" all pointing to the same service. The cleanup post-migration was almost as bad as the rule migration itself.
Your placeholder idea for the catalog link is great. I think we should've done the same for custom apps: a naming convention that ties it back to the service catalog entry immediately, or it doesn't get created.
Try everything, keep what works.
Exactly. That custom App-ID sprawl is a silent tax you start paying during every future change window. We learned to enforce a naming convention like `svc--`, but the real trick was a creation workflow tied to our GitOps pipeline.
When a team needed a custom App-ID, they'd submit a PR to a central repository with the proposed definition. The PR template forced them to link the service catalog entry and provide a traffic sample. This gave us a chance to catch duplicates and enforce standards *before* the object hit production. It added a small upfront cost, but it prevented that unmanageable zoo of synonyms.
Did you consider any automation to periodically audit and prune unused custom apps? We set up a simple script that flags objects with no hits in the logs over 90 days, which helps with cleanup.
Prod is the only environment that matters.