Azure Managed VNET Gateway in Production?

Hi Anonymous 

Based on my discussions with this team, they have pushed the ETA once again to February.

I would recommend you open your own case with Microsoft about this.  I have been (unsuccessfully) asking this PBI team to communicate in the public, just as they did in the past.  The "vnet gateway" used to be listed in the public roadmap (so called "release waves").  Until the GA date is shown publicly, I won't really trust the communication that I've been given privately (by extension, you probably shouldn't trust the information that I'm sharing with you. )

I've been waiting for the GA for about three years.  In all honesty there are deeper problems that go beyond the Power BI team.  The underlying "private endpoint" technology for Microsoft vnet-networking is the actual problem.  The technology is unreliable and causes the PBI vnet gateway to be unstable (see PS***).  The long wait for the GA has been somewhat outside the control of the PBI team.  Even if the PBI vnet gateway goes GA in February, you may want to be very cautious about using it this year.  My understanding is that the "private endpoints" are still not fixed, and I think the PBI team is planning to introduce workarounds that cause as many problems as they solve ... like running SQL queries over and over against your data source to compensate for the network bugs.  Depending on the size of these queries this could create problems in the back-end source, or increase your Azure costs.  If your PBI datasets are smallish, then the PBI workaround might work fine for you.  Based on my experience, Microsoft assumes that 95% of their PBI customers have tiny dataset sizes, and I'm guessing they have some telemetry to corroborate that assumption.

Hope this is clear.

*** PS The underlying "private endpoint" technology for Microsoft vnet-networking is causing problems for me in other parts of Azure too.  These problems aren't limited to Power BI.  I have dozens of socket exceptions a day in ADF pipelines and Synapse Spark.  The problems force us to implement a excessive amount of retries, whenever accessing Azure network resources- even in the same region.  The ADF pipeline team requires customers to use retries as a matter of "policy".  Microsoft is totally unsympathetic to these networking problems, even though it is easy to prove that they are a result of bugs in "private endpoints" (and MPE's); the bugs don't impact public service endpoints for the same Azure services in the same region.