Feedback on Endpoints section and data

[jkewley]

Kicking the tires a bit and the team is confused by what the 'endpoints' pivot is trying to surface. At first we assumed it would be a list of private endpoints in use across the network, but after some testing it appears to be any network attached resource.

1. I think it would be useful to include a 'type' column here which allows filtering.
2. I wonder if it might be more useful when a resource is connected via PE to see the PE name in the grid instead. Or maybe two columns - one is resource, second is connection holding the IP (which shows the PE resource instead of the nic when PE is in use)
3. Perhaps 'Endpoint' is a common term for some, but because of the clash with 'private endpoints' and since Azure uses 'Connected devices' when looking at Virtual Networks maybe you should revisit this section name (and columns)
4. I have two unexpected results after tearing down and redeploying resources
   1. A DataFactrory which is vnet joined using a Private Endpoint shows as orphaned. PE shows 'private link resource' association to ADF in the portal
   2. An APIM instance which is consumption and not vnet attached showing up (bia).

[DCMattyG]

Hi there @jkewley, I always love feedback so thank you for the above. Please allow me to respond to each of your points...

"I think it would be useful to include a 'type' column here which allows filtering."

Today we do have this value in the details section, but your ask is valid and we can absolutely add a column to filter on.

Here's what it looks like today:

"I wonder if it might be more useful when a resource is connected via PE to see the PE name in the grid instead. Or maybe two columns - one is resource, second is connection holding the IP (which shows the PE resource instead of the nic when PE is in use)"

We've taken the approach of when the PE is connected, to reflect the Azure resource to which the PE is connected as that feels like a more logical way you'd be searching for things, and when the PE is disconnected, to expose the full PE name and flag it (in red) to show that it is "orphaned".

Here's an example:

"Perhaps 'Endpoint' is a common term for some, but because of the clash with 'private endpoints' and since Azure uses 'Connected devices' when looking at Virtual Networks maybe you should revisit this section name (and columns)"

That's totally fair. You're the first person who has raised this to me, but I'm open to making changes where makes sense. The Endpoints name came more from common nomenclature in other IPAM products more-so than from Azure as the intention was to make this product seamless to adopt for teams whom are used to managing on-premises IPAM tools.

"A DataFactrory which is vnet joined using a Private Endpoint shows as orphaned. PE shows 'private link resource' association to ADF in the portal"

This is likely a bug and I will test this right away an address it. Thank you!

"An APIM instance which is consumption and not vnet attached showing up (bia)."

This is also likely a bug, meaning that I need to exclude "Consumption" type for APIM which cannot ever exist inside of a Virtual Network. Thank you for this as well!

I'd love to discuss items 2 & 3 from your list more (based on my feedback) and if there is a strong case to make changes, I'm always open and willing.

Thank you again for reaching out, your feedback is what makes this tool better for everyone.

[DCMattyG]

One last thought, I did want to confirm your initial assertion. The intention of the Endpoints section is to surface anywhere a Private IP is consumed. In a traditional (on-premises) network, IPAM appliances can accomplish this by running network scans and/or ping tests (perhaps Nmap), but in Azure we need to glean these details from querying ARM (via Azure Resource Graph).

That is the experience we're attempting to deliver by surfacing these details within the UI.

Hope that helps add some additional clarity to the "why".

[DCMattyG]

Just a quick update on this @jkewley, the issue above with the APIM's should now be fixed. The Data Factory one is slightly more challenging due to the completely different way Azure Data Factories handle Private Endpoints, especially in their Azure Resource Graph reply.

The good news is that I do have a plan to address this, but just need a bit more time to verify that it's going to work without causing any other issues. We'll have it nailed soon!