Deploying the ASP.NET Web API using Azure Websites

Microsoft Azure Websites is a Platform as a Service (PaaS) offering from Microsoft, which allows publishing web apps in Azure. The key focus when building Microsoft websites is to enable a true enterprise-ready PaaS service by allowing rapid deployment, better manageability, global scale at high throughput, and support for multiple platforms. The development of Azure Websites started about 3 years ago under the internal project name Antares with the primary intent to create a cheap and scalable web hosting framework for Microsoft Azure. The main target was shared and cross-platform hosting scenarios. The first preview release for Azure Websites came out in June 2012 and went General Availability (GA) in mid-2013.

Note

Azure Websites was recently renamed and is now part of Azure App Services. REST based service development is now referred to as API apps. For the scope of this book, we will focus on the existing service implementation. To learn more about App Services, please refer http://azure.microsoft.com/en-us/services/app-service/.

There are other PaaS offerings available in Microsoft Azure, such as cloud services that provide Web and worker roles. There is also Microsoft virtual machine through the Infrastructure as a Service (IaaS), so why choose websites?

Let's look at some of the features provided by Azure Websites, which make them an appealing candidate for Web API and web app deployment:

• Cloud-First by design: This is a no-brainer, Azure Websites was started to eliminate the dependency of IIS for cloud developers. Azure Websites leverage SQL Server as a configuration backend, which allows to achieve a greater website density in multitenant environments. It is also intended as a stateless and scalable server architecture.

• Dynamic provisioning: The allocation of resources for Azure Websites is determined based on dynamic rules to ensure optimum allocation and performance of the system overall.

• Network share support: All instances can leverage shared content storage, this ensures optimum reliability in case the frontend machine goes down.

• Stateless servers and smart load balancing: Following the cloud design patterns, all VMs are stateless by design.

• Build on existing PaaS platform: Internally, Azure Websites are hosted in PaaS VMs, so it automatically leverages most of the goodies provided by the cloud services platform today. The following figure shows the main components that make up Azure Websites:

  

As we can see in the preceding figure, Azure Websites are built on existing technologies, such as Azure storage and web and worker hosting model. It adds additional abstraction to enable rapid deployment and easy configuration management through a set of hosting site and site content databases. Furthermore, Azure load balancers are used in conjunction with IIS Application Request Routing (ARR) load balancers to achieve high availability and Hyper Scale. Azure Websites provides the following benefits:

• Development support: Websites can be used for developing solutions in an array of languages such as ASP.NET, Java, PHP, Python, and Node.js. Moreover, the development platform does not need to be Windows, OSX, or Linux. CMS solutions such as WordPress, Drupal, and Joomla are fully supported. The integration with code management tools, such as Git, and source control systems, such as VSO and GitHub, is seamless. To add the cherry to the cake, the tools provided by Visual Studio 2013 and above are so easy to use that development, testing, and deployment just take minutes.

• Built for DevOps: Azure Websites are targeted to reduce the overall time taken to market and provide an effective TCO. Some of these features include high available environment with automatic patching support, automatic scale, automatic disaster recovery and backups, comprehensive monitoring and alter, and quick and easy deployment.

With such great features, is there any scenario where Azure Websites might not be a good fit?

Well, there are some scenarios where we may be better off using Azure Cloud Services and perhaps even Azure Virtual Machines:

• Low-level machine access: Although Azure Websites provide a standard tier that allows its deployment VM, customization that can be done on that VM is still restricted. For example, elevated privileges are not supported as of writing this.

• Background processes: There are scenarios where we want to have backend tasks that run complex processing jobs such as math calculations. Worker roles in cloud services seem appropriate for these scenarios. Having said that, from an application perspective, we can still leverage websites as a frontend. For example, a Web API hosted in Azure Websites may push calculation requests to an Azure Service Bus queue, and a backend worker role can then listen to these requests and process them. Another aspect that is supported by Azure Websites is WebJobs, which is associated with an Azure Website, and as of today, can be used for processing lightweight background tasks, such as startup tasks. WebJobs may become more powerful in the future and could then be considered as an alternative for worker roles.

• Virtual Network support: Since Azure Websites VMs are controlled by Microsoft PaaS infrastructure, there are minimal options to support Virtual Networks or customer domain integration. As of September 2014, a preview release of supporting websites on Virtual Network has been added as a feature. For the latest information on Virtual Network support, please visit http://azure.microsoft.com/en-us/documentation/articles/web-sites-integrate-with-vnet/.

• Remote desktop: As of writing of this book there is no support for remote desktop on Azure Websites. It may not be a big limitation though, as websites now support remote debugging from within Visual Studio for all pricing tiers.

• In-role cache: Due to the stateless nature of Azure Websites, in-role caching is not supported. However, we can use a distributed cache such as Redis and make it work with websites.

Note that some of the scenarios mentioned here might not be available as of today, but the team may provide support for these in future releases. As a rule of thumb, consider these as recommendations and not protocols. Considerable planning should be conducted based on customer requirements and timelines before making a decision to choose any of the platform options.

Deploying to Azure Websites

Now that we have a fair understanding of Azure Websites' capabilities, let's deploy the Web API we built in the previous section to an Azure Website.

Note

This sample assumes that the user is signed into an Azure account in Visual Studio. It is required to view the Azure subscription when creating the ASP.NET Web API project. For more information on Azure tools for Visual Studio, please visit http://msdn.microsoft.com/en-us/library/azure/ee405484.aspx.

Since we did not associate our Web API project to an Azure Website at the time of its creation, we will now provide details on the Azure subscription and website where we want the deployment to be hosted:

1. Right-click on the Web API project. Click on Publish to open the Publish wizard, and select Microsoft Azure Websites as the publish target.

2. In the Microsoft Azure Websites dialog, click on New to create a new Azure Website. Here, we provide details about our Azure subscription and give a name to the website. When deciding on a name, ensure that it is unique; the Create Site dialog box validates the fully qualified URL to ensure that there are no existing sites with this name. In case the site name already exists, an error is thrown by the Create Site dialog box.

3. By default, the domain name is set to azurewebsites.net. It is the default domain for all tiers; we can also provide a custom domain for our deployments (for example, www.mywebsite.com).

   

4. Once the Website is created, we are ready to publish our Web API. Azure Websites provides the following publish methods for web applications:

   • Web deploy: This is also known as msdeploy. It streamlines the deployment of web application to Azure Websites. It enables the packaging of Web application content, configuration, databases, and any other artifacts, which can be used for storage or redeployment. If the package needs to be redeployed to a different environment, configuration values within the package can be parameterized during deployment without requiring modifications to the packages. Use this option to delegate deployment to Azure Websites.

   • WebDeploy package: We can use this option when we have an existing WebDeploy package.

   • FTP: This allows to deploy source from an FTP server.

   • File system: This deploys source from a local filesystem location.

5. Once the deployment is complete (should not take more than a few seconds), we will have our Web API running in the cloud.

6. To test the deployment, replace the local domain name we used in the Testing in a browser section with the cloud domain name of the Azure Website as shown:

   Request	http://dotnetbook.azurewebsites.net/api/package/1
   Response	{ "Id": 1, "AccountNumber": "ac09ae02-00cf-426d-b969-909fae655ab9", "Destination": "TX", "Origin": "CA", "Weight": 2, "Units": 1, "StatusCode": 1, "History": null, "Properties": null }

If we now browse to the Azure management portal and go to the Azure Website we just created, we can right away see incoming requests and how the traffic is being monitored by Azure Websites similar to how it is shown in the following diagram; now that is true PaaS!

Note

The new Azure portal (currently in preview) provides more detailed statistics about the resources leveraged by Azure Websites. These include storage, network, and compute. The preview portal is accessible at https://portal.azure.com/.