PaaS - Under The Hood: Packaging and Deployment in Windows Azure - Part 1

The fundamental unit of deployment in Windows Azure is a Role. A Role is the template that contains the actual bits and the configuration. It is a mechanism for the developers to deal with the Compute (which is called as a Hosted Service) part of the Azure. New and existing applications targeting the Cloud need to be packaged into one or more Roles. For running web applications, Windows Azure offers a template called WebRole. ASP.NET and PHP applications will be deployed as WebRoles since they are exposed on HTTP 80 or 443 to the outside world as web applications. For running non-UI, long running processes, the code needs to be deployed as a Worker Role. A WorkerRole is designed to run the “raw” code that can be run on Microsoft Windows Server 2008 OS with an exception of UI based applications. Windows Azure also offers another Role called a VMRole that can be used to run applications that do not fit into the Web Role and Worker Role types. VMRole is typically used to run legacy applications and components with dependencies that may not run on the other two roles. An in-depth discussion around Roles is outside the scope of this article. We will focus on the way an application is packaged and the techniques of deploying it on Windows Azure.

Typical Windows Azure application contains three elements – 1) One or more Roles, 2) the service definition of the application and, 3) the service configuration.

1. Role – This contains the ASP.NET web application packaged as a WebRole or code that is packaged into WorkerRole. This contains the usual .NET code and a mandatory class for Role Entry point in the form of a WebRole.cs and WorkerRole.cs. This combination of Role EntryPoint and the traditional code turns the project into a WebRole or a WorkerRole.
2. 
   
3. Service Definition – This XML file (typically called ServiceDefinition.CSDEF) enumerates all the Roles that will be deployed into one Hosted Service. The settings that need to be defined once and before running the instances go into this file. Settings like the size of the VM, the certificates to be included for the Hosting Service, definitions of custom settings that can be passed to the application at runtime, input and internal endpoints for the communication, local storage space per role, and finally the startup tasks that need to be executed. In summary, this file has the global settings for the Hosted service and the settings that are required per role.
4. 
   
5. Service Configuration – This XML file (typically called ServiceConfiguration.XXX.CSCFG where XXX can be Cloud or Local) contains the settings that can be changed without forcing redeployment of the application. For example, the number of instances of a specific role can be changed in this file that would impact your deployment immediately by spinning up more VMs based on a specific role. Though Windows Azure is a PaaS, it gives the ability to choose a Guest OS version for better compatibility of the runtime. Developers can opt for a specific Guest OS that comes with a specific version of .NET runtime, patches and features that map to a specific version of Azure SDK. By changing the setting in the Service Configuration file, developers can switch between a variety of Guest OS releases. Custom settings defined in the Service Definition file can be changed at runtime forcing the application to refresh itself with the new settings.
6. 
   

So, a Windows Azure application contains one or more Roles, Service Definition and Service Configuration.

Once we have all these in place, we need to package the application for the Cloud. In the next step, we will explore the options to package an application.

The packaging process will emit two files that need to be deployed. One of the two files is the CSPKG file that contains the compressed version of the application combined with the settings mentioned in the CSDEF file. The other file is the ServiceConfiguration.CSCFG file that contains the runtime settings that can be changed during the lifecycle of an application. But what are the options to generate these two files? We can use one of the three techniques to complete the packaging.

1. Visual Studio - Once the Windows Azure Tools for Visual Studio are installed, developers can enjoy the single click deployment from the IDE. Visual Studio offers both packaging and publishing of the Cloud applications. This is the most intuitive and productive way of deploying applications to the Cloud.
2. 
   
3. CSPack command line tool – This comes as a part of Windows Azure SDK. CSPack can be used to package applications for both Windows Azure Emulator running locally and Windows Azure.
4. 
   
5. MSBuild – Developers can use MSBuild to prepare an application package for Windows Azure. The MSBuild XML file will have the appropriate tools to invoke the compilation and packaging the application.
6. 
   

All the above tools will emit the final .CSPkg file and .CSCFG file ready to be deployed.

This article looked at what goes into a Cloud application targeting Windows Azure. We discussed the extra elements that needed to be added to conventional .NET applications to transform them into Cloud applications. This is essentially the first step in going to the Cloud. In the next part of this article, we will take a closer look at the deployment and how various tools interact with the Windows Azure control plane. Stay tuned!

- Janakiram MSV, Chief Editor, CloudStory.in