Azure Web Sites Deployment: how does it work?

Azure Web Sites supports continuous deployment from source code control and repository tools like BitBucket, CodePlex, Dropbox, Git, GitHub, Mercurial, and TFS/VSO. You can use these tools to maintain the content and code for your web site, and then quickly and easily push changes to your site when you want.

Supported Deployment types

Pushing local files to Azure by using Local Git allows you to manually push updates from a local project to your Azure Web Site, while deploying from BitBucket, CodePlex, Dropbox, GitHub, or Mercurial results in a continuous deployment process where Azure will pull in the most recent updates from your project.

While both methods result in your project being deployed to an Azure Web Site, continuous deployment is useful when you have multiple people working on a project and want to ensure that the latest version is always published regardless of who made the most recent update. Continuous deployment is also useful if you are using one of the above mentioned tools as the central repository for your application.

On the net there are plenty of articles explaining how to deploy an Azure WebSite (i.e. http://azure.microsoft.com/en-us/documentation/articles/web-sites-deploy/) or how to implement Continuous Deployment strategies (i. e. http://azure.microsoft.com/en-us/documentation/articles/web-sites-publish-source-control/).

But how does it work behind the scenes?

Well, the answer is "Kudu".

Kudu is the engine behind deployments in Azure Web Sites, but it can also run outside of Azure.

It has a somewhat unusual architecture, in the sense that it is a single-tenant rather than multi-tenant service. What this means is that each Azure Web Site has its own instance of the Kudu service, completely distinct from the Kudu service sites used for other Azure sites.

It stays active in background and "watches" for checkins, commits, new files, completed builds and so on. When it detects something, KuduSync starts and do the "dirty work".

It's a great tool, because:

• it’s an open source project available on GitHub (https://github.com/projectkudu/kudu)
• it's automatically installed on all Windows Azure Web Sites
• it can use a custom deployment script

But the most important thing (imho) is this:

The deployment is created in your website’s folder structure and the new deployment is copied to your site’s root, leaving old deployments intact.

This means you can "rollback" to any deploy you've done in the past. This, for me, it's a killer feature!

It's also possible to have access to the Kudu web dashboard, using an url like "https://your_website_name.scm.azurewebsites.net/" and your deployment credentials or your Azure service admin credentials.

Kudu Dashboard

In the Kudu dashboard you can find a lot of useful informations about your website's environment together with a set of tools to manage your website and, last but not least, a complete set of REST APIs. There is also the possibility to manage WebSites extensions.

There is also a great video where David Ebbo and Scott Guthrie explain how Kudu works: http://channel9.msdn.com/Shows/Azure-Friday/What-is-Kudu-Azure-Web-Sites-Deployment-with-David-Ebbo

Azure WebSite, Cloud Service and Virtual Machine: which to choose?

Sometimes it happens to start a new development project or to plan a deploy on the cloud, on Azure, but you don't know what kind of service is better to use: a WebSite, a Cloud Service or a Virtual Machine? What pros and cons do they have?

Let's deiscover the main differences.

Warning: this post is updated with the information available to August 5th, 2014.

First of all, a diagram (the same that Microsoft uses in the Azure official docs), to compare our three services:

Courtesy of Microsoft

In this image the "simplicity / control" ratio between services is quite clear. To be extremely synthetic:

• WebSite: 
• Solution extremely simple to use, it offers a good set of tools to support (monitoring, alerts, stairs, etc) but at the expense of the level of customization and control over the configuration. 
• In multi-tier applications, it provides support to the only web tier
• Cloud Service:
• Less simple to use and deploy compared to Websites, provides a much greater level of control.
• Also in this case there are several tools for monitoring and support already included
• You can use both WebRoles (that actually are dedicated VMs with IIS installed) as well as WorkerRoles (always dedicated VMs, but without IIS. You can think about WorkerRole as a Windows Service)
• In multi-tier scenarios, you can use a combination of WebRole and WorkerRole to implement the web tier, the middle-tier and the backend
• In multi-tier, you can scale the frontend and the backend independently
• Virtual Machine:
• Leaves the configuration and customization completely to the user, so it's more complicated to manage but provides the highest level of control possible, as with the on-premises server.
• You can use it for any kind of application and architecture
• You need to manually deal with the management of the system, including upgrades, security policies, etc. etc.
• It's the ideal choice in complex scenarios or when you need to host software or services that are not supported in WebSites or Cloud Servives.

This is the official services features comparison table:

FEATURE	WEB SITES	CLOUD SERVICES (WEB ROLES)	VIRTUAL MACHINES
Access to services like Service Bus, Storage, SQL Database	X	X	X
Host web or web services tier of a multi-tier architecture	X	X	X
Host middle tier of a multi-tier architecture		X	X
Integrated MySQL-as-a-service support	X	X 1	X
Support for ASP.NET, classic ASP, Node.js, PHP, Python	X	X	X
Scale out to multiple instances without redeploy	X	X	X 2
Support for SSL	X 3	X	X
Visual Studio integration	X	X	X
Remote Debugging	X	X	X
Deploy code with TFS	X	X	X
Deploy code with GIT, FTP	X		X
Deploy code with Web Deploy	X	4	X
WebMatrix support	X		X
Near-instant deployment	X
Instances share content and configuration	X
Scale up to larger machines without redeploy	X
Multiple deployment environments (production and staging)	X	X
Network isolation with Azure Virtual Network		X	X
Support for Azure Traffic Manager	X	X	X
Remote desktop access to servers		X	X
Ability to define/execute start-up tasks		X	X
Automatic OS update management	X	X
Integrated Endpoint Monitoring	X	X	X
Seamless platform switching (32bit/64bit)	X	X

1 Web or worker roles can integrate MySQL-as-a-service through ClearDB's offerings, but not as part of the Management Portal workflow.

2 Although Virtual Machines can scale out to multiple instances, the services running on these machines must be written to handle this scale-out. An additional load balancer must be configured to route requests across the machines. Finally, an Affinity Group should be created for all machines participating in the same role to protect them from simultaneous restarts from maintenance or hardware failures.

3 For Web Sites, SSL for custom domain names is only supported for standard mode. For more information on using SSL with Web Sites, see Configuring an SSL certificate for an Azure Web Site.

4 Web Deploy is supported for cloud services when deploying to single-instance roles. However, production roles require multiple instances to meet the Azure SLA. Therefore, Web Deploy is not a suitable deployment mechanism for cloud services in production.

If you want to take a llok at the complete services comparison, see the guide on the official Azure documentation.