if you've stumbled upon this post you most likely already know MS Azure App Service: a fully managed HTTP-based platform for hosting web applications, REST APIs, and mobile back ends provided by MS Azure.
Deploying a Web Application using App Service is considerably easier and faster than setting up a dedicated on-premise or cloud based Web server - be it a Phisical Machine, a Virtual Machine, or container - while keeping (almost) the same benefits in terms of customization of the underlying stack: that's especially true for ASP.NET Core apps, since all versions of .NET are fully supported by App Services as application engines. As a matter of fact, such approach can be a tremendous advantage for most ASP.NET Core projects, as long as we don't need to perform complex low-level infrastructure configuration tasks.
In this article, after listing the main pros and cons of App Service, we'll briefly see how we can use it to create a Web App instance on MS Azure for a typical ASP.NET Core app and use our own domain name (DNS) instead of the default one provided by Microsoft.
App Service pros and cons
As we've briefly explained early on, App Service is basically a Platform-as-a-Service (PaaS) infrastructure that can be use to host a web application instead of having a dedicated Web Server. It goes without saying that such managed approach comes with some advantages and drawbacks.
Here's a list of the most important App Service advantages:
- Built-in HTTPS support. All App Service apps comes with a free SSL/TLS certificate, meaning that we can have in-transit Encryption (and a trust level certified by a third-party authority) without having to buy anything. However, that's only true if we stick with the default domain name provided by App Service (the one ending with *.azurewebsites.net), since the built-in HTTPS certificate will only cover that domain: if we want to use a custom domain, we'll have to "secure" it with our own certificate.
- Multiple languages and frameworks. App Service can support web applications built using the following server-side engines: ASP.NET, ASP.NET Core, Java, Ruby, Node.js, PHP, or Python; furthermore, it's also possible to run PowerShell and other scripts or executables as background services.
- Managed production environment. App Service automatically keeps the OS and language frameworks up to date, without having to manually patch them - like we normally have to do with Web Servers.
- DevOps integration. It's possible to set up Continuous Integration (CI) and Countinuous Deployment (CD) automation strategies using various CI/CD platforms such as Azure DevOps, GitHub Actions, BitBucket, Docker Hub, or Azure Container Registry.
- Global scale with high availability. App Service can be scaled up or out manually or automatically, meaning that we can host our apps anywhere in Microsoft's global datacenter infrastructure.
- Security and compliance. App Service is ISO, SOC, and PCI compliant: users can be authenticated with many MS-native and third-party auth providers such as Azure Active Directory, Google, Facebook, Twitter, or Microsoft account.
- Restricted Access. The web application can be configured to be publicly accessible (from anywhere on the internet) or from specific IP addresses (or IP masks) only, or other while-listing techniques.
- Application templates. The Azure Marketplace provides several available App Service templates that can be used to immediately create common applications, including WordPress, Joomla, and Drupal.
- Visual Studio and Visual Studio Code integration. App Service apps can be deployed and debugged from Visual Studio and Visual Studio Code using dedicated tools.
- CORS support. Cross-Origin Resource Sharing can be configured to support specific RESTful API scenarios.
And here's a list of the most known drawbacks:
- Pricing. Azure App Service has a great free tier (F1) and several cheap tiers that can be used for development and testing purposes: however, those tiers have a (very) limited amount of available CPU and RAM and - most importantly - will only provide few hours a day of processing time - meaning that the App might cease to work if it receives too many requests during the day. For high-duty production requirements we will eventually need to subscribe to more expensive plans, with average costs not much different from the price of most general purpose Virtual Machines. For that very reason, in some specific scenarios a dedicated Web Server VM might even be a cheaper choice, especially if we can afford to use it to host multiple web apps.
- Fixed Domain Name (for cheap tiers). All App Service apps are hosted using a custom third-level domain ending with *.azurewebsites.net. Here's a typical example: mywebapp.azurewebsites.net. Such domain can be changed with a custom domain name, but doing that will require a custom HTTPS certificate - since the built-in certificate can only cover the "default" domain. However, the free tiers - as well as most cheap tiers - don't allow to use custom HTTPS certificates, thus making such change impossible to do. As a matter of fact, if we want to use a custom domain name (which can be purchased through one of the many domain registration services available online) we have to use one of the most expensive tiers (see previous point).
- No Remote Desktop. Azure App Services is not a "real" server, therefore we can't use a "typical" RDP connections to browse settings, review configuration files, look at the system logs, and so on. We have to get used to the "managed" interface provided by MS Azure, which - luckily enough - offers a lot of useful tools and dashboards to do this kind of stuff. That said, such approach can have a huge impact for those System Administrators who might want to use "their" toolset to administer the web server, because they won't be able to install any software and/or management tool.
- No Performance Counters. Performance counters can be a pain to work with, but they are very useful if we want to understand what happens under the hood and get some useful key metrics about IIS, applications, and the .NET CLR. Without performance counters there is no way to monitor things like garbage collection, IIS queuing and a lot of other data that can be critical to troubleshooting weird performance problems.
- Specific Skillset. Administering a local Web Server isn't an easy task, but most System Administrator have the required knowledge to do that decently enough. Conversely, App Service is quite easy to pull off - as long as the operating user is willing to acquire some specific expertise with the MS Azure platform. This might sound easy to do, however it requires the proper mindset, training, and often a good dose of humility, which is something that some System Administrators might lack - especially if they're not suited to work with MS Azure and/or cloud platforms in general. It's important to understand that being able to properly deal with App Services will likely take a certain amount of practice, which can be only achieved with specific and dedicated training.
Conclusion
That's it, at least for the time being: in a future post we'll see how we can technically deploy our ASP.NET Core Web Application to an App Service instance and change its domain name to a custom one.
