Cross-namespace forwarding

[SeanFeldman]

Description

Organizations grow and evolve. Having all internal systems using the same service bus namespace is not ideal and causes a lot of pain (number of entities limitation, provisioning and monitoring challenges, performance, etc.). It would be great to have cross-namespace forwarding that would allow systems using different namespaces to communicate with each other in a reliable manner, without resorting to workarounds. Ideally, using guaranteed cross-namespace forwarding with ASB conventional semantics.

[EldertGrootenboer]

Thank you for the feedback. This is in our backlog, although we don't have timelines yet.

[SeanFeldman]

This is in our backlog, although we don't have timelines yet.

The internal backlog is not visible and cannot be subscribed to receive updates.

Please re-open this issue until there are better means of getting notified or the feature is available. Thank you, @EldertGrootenboer.

[vladansw]

@EldertGrootenboer Are there any updates on this cross-namespace feature?

[EldertGrootenboer]

We don't have any updates for this feature yet, once we do, we will update this issue.

[Sandeep7OnShell]

@EldertGrootenboer Any idea if we are talking about months, years for this to be picked up. I am sure projects would like to take decisions based on when will this be available.

[EldertGrootenboer]

Thank you everyone for your feedback on this item so far. We are continuously prioritizing the different requests we get from all our various feedback channels. As of now, we don’t have a clear timeline for this feature yet, except that this will not to be picked up at least in the next six months. Once we have more information, we will come back on this thread. In the mean time, to help us give this the right priority, it would be helpful to see others vote and support this feature, as well as explain their scenarios.

[serbrech]

We would be very interested in this functionality as well.
The use case is to have a native forwarding across namespace in case of blue-green deployment, or failover.

[sanketshahMS]

+1 on this, would be great if this feature is available.

[michasacuer]

+1, will be great feature

[SteveDurkee]

+2, my baby agrees too

[Sandeep7OnShell]

+5 from my side, my team agrees.

[codewisdom]

Come on MSFT! Let's get it done.

[EldertGrootenboer]

Thank you for your feedback on this item, it helps us in our efforts to continuously prioritize the different requests we get from all our various feedback channels. We have added this feature in our backlog, however we currently don't have an ETA on when development might start on this. For now, to help us give this the right priority, it would be helpful to see others vote and support this feature, as well as explain their scenarios.

[vladansw]

Hi @EldertGrootenboer, we use SB to integrate multiple systems. ATM we have one SB instance and a service behind it that does some processing and serves messages to all systems but we want to split this to multiple smaller SB instances and have each system to monitor and maintain their own instance. We cannot do it via code because it would be a nightmare to maintain.

[Sandeep7OnShell]

@EldertGrootenboer request for this feature is evident and more than even. It would be of great help to the community if this can be picked and some insights for timelines are shared.

[michasacuer]

@vladansw We have really smiliar problem and my colleagues in other companies so I am surprised that this has low prio. Will be a day and night difference in terms of user experience

[markusfoss]

+5 from me and my team

[AramYako]

++

[issacnitinmsft]

++

[ingmarkellner]

+5 from me and my team.

[HenrikSommer-Energinet]

+1 Organizations

[meciasbueno]

+1 organization

[msterin]

+1

[Sandeep7OnShell]

@SeanFeldman and @EldertGrootenboer, Appalled to see that this issue was opened on Oct 22, 2021 and it still lacks any plan or vision from MS. Looking at all the reactions from a lot of people in this thread, I thought its high time that MS will pick this up but haven't witnessed anything like that.

No doubt people turn unhappy with MS seeing all this.

[timtucker-dte]

@SeanFeldman and @EldertGrootenboer, Appalled to see that this issue was opened on Oct 22, 2021 and it still lacks any plan or vision from MS.

2021 is nothing.

Look at all the top feature request for Service Bus -- a lot of the top entries have been on the backlog for 6-10 years:
https://feedback.azure.com/d365community/forum/7c0a897d-2125-ec11-b6e6-000d3a4f0f84

[SeanFeldman]

Look at all the top feature request for Service Bus -- a lot of the top entries have been on the backlog for 6-10 years

Wrong metric. Look at the number of upvotes. Just to contrast with something else, have a look at some of GitHub (product) issues running for years with hundreds of upvotes and zero response from the team.

Yes, I wish every feature I requested was already there. But there's a reality that needs to be considered. Which folks tend to forget.

Also, I wish folks would use GitHut and not split their votes between GitHub and Feedback (which is not that great for tracking processes and engagement).

[timtucker-dte]

Yes, I wish every feature I requested was already there. But there's a reality that needs to be considered. Which folks tend to forget.

I get it -- the reality is that for many components in Azure there are far fewer people maintaining them than there are using them.

It's not really the fault of any one team or project -- it seems like the trend for MS as a whole is to under allocate staff & resources for development vs. marketing & sales.

Also, I wish folks would use GitHub and not split their votes between GitHub and Feedback (which is not that great for tracking processes and engagement).

I try to stick mostly to GitHub for things that have projects, but it's hard when the recommended "best" place to submit feedback for MS products varies product-by-product and keeps shifting every few years.

For a while it was UserVoice. Now it's the Feedback Portal (for some things)... which was supposed to be better for tracking & engagement.

For things like tracking the Feedback requests for a local emulator for storage bus, it seems less clear where that would go in GitHub -- i.e.: is that something that would go here, or would that wind up a completely different codebase / repository that doesn't exist yet?

[SeanFeldman]

Emulator issue: #223

[janisBerz]

+1

[EldertGrootenboer]

We have brought this item in our current planning. We don't have a specific date when development will start for this, once we have more information around this, we will update this thread.

[asos-gurpreetsingh]

Come on please @EldertGrootenboer there has been a glimmer of hope since April 2022 (not on April fools day) . It is Aug 2024 now. We need this feature please, this will simplify things for everyone. Any rough idea about when will this get picked up for development ? month, year, decade, century ?

[Sandeep7OnShell]

@asos-gurpreetsingh and Others, Keep no hope on MS products going forward. We are using MS tech stack for huge amounts of codebase and we see the quality of MS code/products downgrading with each passing day(base MS products are already built sadly). This is a prime example of its state of afairs when the requirement is there since years and no serious thought from MS at all.

You are correct, it might be decades, century or people should look for other options as a saver before it gets too late.

[michasacuer]

@asos-gurpreetsingh and Others, Keep no hope on MS products going forward. We are using MS tech stack for huge amounts of codebase and we see the quality of MS code/products downgrading with each passing day(base MS products are already built sadly). This is a prime example of its state of afairs when the requirement is there since years and no serious thought from MS at all.

You are correct, it might be decades, century or people should look for other options as a saver before it gets too late.

Well might be true. What features community receives for ServiceBus in two years? Cross namespace forward is really great Quality of Life change that will help a lot of teams

[coorter]

+1 - upvoting! This will make my whole team life much, much easier... otherwise we need to look for some nasty workaround which will make our life miserable... :(

[scaffida]

+1 our team is facing similar case and it would indeed avoid workarounds