There are many reasons you may want to have a static IP address for outbound connections. For example, you may be accessing a system which requires you to whitelist IP address in a firewall, such as SQL Database or an external service.

Currently, the only way to get a static IP address for outbound connections is to use App Service Environment. App Service Environments are quite complex, and has a very high price tag. You need at least 4 instances, 2 of which must be P2, meaning you'll pay at least 1000 EUR/month. Paying 1000 EUR/month just because you want a static IP address is obviously ridiculous.

I'm looking forward to being able to use a static IP address without an App Service Environment.

Deploying a Java application to Azure for the first time is not bad, but incremental updates are very painful. The basic functionality works, but it involved multiple steps that really shouldn't be there.

1. Every time that you want to deploy a WAR file, you have to delete the application's exploded directory (ROOT, for example). In order to do this properly, you have to stop the server first. You should be able to simply replace the WAR file (ROOT.war, for example), and have Tomcat take care of updating the application. If you have an application that is large or has a lot of files this process can take your application out of service for a long time (20+ minutes to delete all the files over FTP in my case).

2. There is no easy way to redeploy/restart Tomcat without taking the service out completely. When updating certain classes that may be loaded in memory, you may need to trigger a Tomcat redeploy.

3. When deploying WAR files over GIT (or any of the other deployment methods), it looks like Azure SOMETIMES attempts to have Tomcat deploy the newly uploaded file before it is finished uploading. This results in a partial application deploy and requires to you to restart the server anyway to get it to load properly.

Deploying exploded WAR files via a repository seems to work OK, but classes don't always get reloaded if they change.

4. The Catalina and other tomcat generated logs seem to be locked by the OS (even for reading), and are unavailable via FTP until the site is stopped. This makes debugging issues very difficult, as errors can't be read while the server is running.

Currently 503 errors (service unavailable) present a blank white page with "service unavailable" to the users which is far from professional for us. It would be far better if we could provide a custom 503 page which would include a logo etc., and some text along the lines of "We apologise for the inconvenience, we are working on it. These issues usually resolve in about five minutes. please contact support for further help if required." or something similar.... This error might be caused by Azure network issues, so away from the web app instance.

It would also be helpful if this were possible for 403s as well. However 503 is the most important.

I have raised this idea before, but it seems to have disappeared.

I am pretty surprised that we cannot do this already.

Thanks.

For multi-tenant applications, we require the ability for Azure to support double wildcard custom domains.

Single wildcard custom domains are currently well supported, i.e.

*.mydomain.com

catches all unmapped, single subdomain urls e.g. level1ex.mydomain.com, level2ex.mydomain.com etc

The issue (which isn't documented: see forum post below) is that secondary level wildcards are not supported at all by Azure:

e.g. www.level2.mydomain.com will result in a 404 error.

Why is this important? in a multi tenant environment, with lots of customers on different subdomains, it is best from an end-user perspective to support a www. subdomain prefix, as that's what 99% of non-technerati do when navigating to a website!

i.e. typing in www.level2.mydomain.com should be resolvable by Azure, just as single-level domains are, and not result in a 404

https://social.msdn.microsoft.com/Forums/azure/en-US/4196087d-0ef9-44dc-9192-73e434bdb194/second-level-subdomains-wildcard-domains-on-azure-dont-work-as-expected?forum=windowsazurewebsitespreview

We've recently suffered a 3 hour outage on our web app due due to the process servicing the web app continuously crashing. After escalating the issue and working with an escalation engineer we have not been able to diagnose the cause (access violation but unfortunately the crash dump was corrupted).

However what we have learned is that even with multiple instances running if this was to happen again the unhealthy instance would not be removed from the load balancing and all requests serviced by that instance would fail. According to the escalation engineer the load balancing just detects infrastructure failures, not application health per instance.

Would it be possible to leverage the existing web test functionality to define a 'health test' for the application? If Azure detects that an instance fails the health test for an extended period of time it could tear down the instance and create a new one?

We are seeing some delays in Time To First Byte because OCSP stapling is not active on Azure Web Apps SSL endpoints.
This causes our clients' browsers to call the issuing CA's endpoint before SSL negotiation can really begin.

Stapling would save the client browser from having to make an extra request to the CA checking if the certificate has been revoked.

There is also a potential privacy issue for our clients that the CA will be able to log these requests. If the web server takes care of OCSP on the other hand no requests will be sent from the client to the CA.

The wikipedia article on OCSP stapling explains things pretty well.
https://en.wikipedia.org/wiki/OCSP_stapling

Running webpagetest.org against your site with the browser set to firefox shows the OCSP calls to the CA.