The downside is creating this service bus resource in the first place. This is a big benefit - we can ensure that our application code only really needs to change a connection string but the rest of the code deals with consistent resource names. Then inside each namespace, the names of our individual resources (topic/subscription/queue) will be consistent across all environments: Consistent resource names inside namespace Instead of having a single namespace that everyone shares, we can instead create isolated namespaces per developer: Namespace per developer You'll have to roll your own convention and setup, and ensure your code can handle topics, subscriptions, and queues having somewhat dynamic names. The downside is all this additional naming complexity and the pain of setting all this parallel infrastructure up. One advantage to this approach is we can use a higher Service Bus pricing tier (perhaps even Premium, around $700/mo), ensuring our developers use the exact same resource during development as production. We have to use a naming convention to separate these resources, perhaps using the machine name or developer's login: Service bus resources per developer In this approach, we pick an appropriate tier of Azure Service Bus (probably Standard or Premium), and create isolated resources for each individual developer (or machine). Namespaces aren't free, and each namespace tier has different features, so we have to consider costs and capabilities. These each have their benefits and drawbacks, however.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |