Just making sure folks have seen the recent Polybase work for loading data from ADL to SQL DW. https://docs.microsoft.com/en-us/azure/sql-data-warehouse/sql-data-warehouse-load-from-azure-data-lake-store and https://azure.microsoft.com/en-us/blog/sql-data-warehouse-now-supports-seamless-integration-with-azure-data-lake-store/
Polybase is fine, but it requires setting up the external tables ahead of time and pointing them to a destination that has to exist at the time. It would be better if we could push data directly to SQL DW from within ADL U-SQL query. Making a SQL Outputter would be super useful.
This remains unplanned.
Here's a use-case for us that is actually blocking our adoption of Functions.
Ideally, I'd like to use Functions with each logical group of functions in its own unique service plan running under a consumption pricing model. Unfortunately, I can't do this because the consumption pricing plan doesn't allow VPN connections. As a result, none of my Functions would be able to connect to our database inside of a virtual network.
Unable to use a consumption plan, I could create a standard service plan for my Functions and connect via the VPN networking service. This would be fine, but then it would require me to put Functions from multiple solutions into the same app service plan. Unfortunately, due to the requirement that everything be in the top-level directory, this would result in all compiled Functions being placed into the same \bin folder in the root, potentially causing many conflicts between DLL versions.
I have actually tried placing them in sub-folders, but the engine doesn't find any of the Functions. Webjobs have each set of compiled resources within their own sub-folders and that allows many of them to be placed into the same app service, which works well for us.
As it stands now, I can't use Functions even though I want to. I'm actively looking for solutions to this problem, ideally one that would allow us to use the dynamic consumption pricing model.
357 votesBrian Vallelunga shared this idea ·
SSL only requires multiple IPs when the client is on Windows XP, using an older version of Internet Explorer. Most modern browsers support SNI (Server Name Indication) and thus don’t require multiple IPs.
Support for multiple IPs is under review in the team.
Is there any work being done on this? It was requested two years ago and has a huge amount of votes. We'll have to consider another cloud provider without this feature. Multiple IPs for apps and Web Sites is still a must-have feature for many people due to the SSL restrictions.
SNI is going to be useless for the next few years unfortunately. There's just too little support, especially among mobile browsers.
Without this feature, I likely can't deploy our solution to Azure, as I have the exact same needs. In fact, we don't need HTTP at all, just HTTPS.