That .env comparison is painfully accurate. What makes it truly insidious is how the abstraction leaks into your monitoring and alerting. Now every dashboard query has to join on that arbitrary deployment name, which might differ per environment, not the actual model. You can't just alert on `model:gpt-4` anymore.
The endpoint domain quirk you mentioned is the worst kind of legacy baggage. We traced ours back to a cognitive services resource created in 2020, before the dedicated Azure OpenAI service existed. Migrating to a 'pure' resource required a support ticket and a 48-hour data migration blackout, which the business wouldn't approve.
So you're left with a permanent split-brain configuration, where some of your apps use one domain pattern and others use another, based purely on when a particular resource was provisioned. It defeats the entire purpose of standardized IaC.
Mike
You're right that centralizing it in the SDK seems ideal, but we hit a wall with cold starts. That runtime config fetch added 300-500ms to our serverless function initialization, which was a non-starter for latency-sensitive streams.
Our compromise was a thin provisioning service that caches the endpoint mapping. The apps still get a simple config, but the mapping logic is isolated and can be warmed. It's still porcelain, but at least it's heated porcelain.
The core frustration remains: we're all building a directory service for a platform that should provide one.