Windows Azure Guide part 2: Scaling hosted applications

Tutorial

Windows Azure Guide part 2: Scaling hosted applications

<< Access the first part of the Windows Azure tutorial here

Continue Reading This Article

Enjoy this article as well as all of our content, including E-Guides, news, tips and more.

Read the third article in our Windows Azure guide series >>

Microsoft entered the cloud computing arena with Windows Azure, a Platform as a Service (PaaS) offering, way back in 2008. After initial free availability for developers, the platform was made available commercially around February 2010.

Over the years, the Windows Azure cloud offering has matured considerably in terms of number and capability of service offerings. One of the main offerings is termed as “Compute” or “Hosted Services”, through which applications can be deployed on one or more virtual machines at Microsoft’s data centers. Using the remote desktop feature one can check the deployed application and the hosted machine. This Windows Azure guide will discuss scaling of applications to increase or decrease the number of these virtual machines.

Reason for scaling

This Windows Azure guide addresses the key value proposition of cloud computing, which is the notion of infinite scale. For hosted applications in the cloud, one of the major aspects that organizations look forward to is the ability to scale up/down or outwards on demand or automatically based on rules and trigger conditions, in order to handle variable loads, rapid growth, predictable and unpredictable bursts, and so on.

For Windows Azure hosted applications, the virtual machines at Microsoft data centers run a customized copy of Windows Server 2008 R2 along with Internet Information Server (IIS) 7.5 and .NET 4.0 (as of April 2012).

An application running within IIS is termed as a Web role.  On the other hand if the application is a Windows Service, Web service, batch process, background task, or any kind of process that runs outside of IIS, then the application assumes a Worker role. Web roles are assigned an “http” URL (http://<your_unique_application_name>.cloudapp.net) while Worker roles can be any arbitrary process that performs some operation in response to an event or by checking an external data structure such as an Azure storage services queue.

For this Windows Azure guide assume that we have deployed either or both types of roles (as appropriate) and now need to scale the Web roles and Worker roles independently, as they are normally deployed as separate VMs.

Scaling a Windows Azure Web/Worker role

  1. Management portal

As the first step in this Windows Azure guide logon to the Windows Azure management portal (http://windows.azure.com) and sign in with your Live ID. Click on the Hosted Services button to see your list of deployed applications. Next, choose the Web/Worker role, select the Configure option and edit the XML content. Change the instance count appropriately, as shown in Figure 2.

Figure 1. Windows Azure management portal

Figure 2.  Configure deployment

Service management (SM) application programming interfaces (APIs)

The service management APIs provide programmatic access to most features available in the management portal. These are a set of REST-based calls that interact with the Windows Azure Fabric (the core of the cloud operating system) to perform various tasks across the range of Windows Azure services. Different wrappers have been written over the SM APIs in .NET, PowerShell, command line Azure tool, Azure Java  SDK and many CodePlex (open source) projects (e.g. http://azureservicesmanager.codeplex.com/). Read more on SM APIs here: http://msdn.microsoft.com/en-us/library/windowsazure/ee460799.aspx

 

For this Windows Azure guide we shall design a simple console/Windows Forms- based application to perform scaling using SM APIs.

  1. Get deployment information:
  2. Create an HttpWebRequest with URL as https://management.core.windows.net/<subscription_id>/services/hostedservices/<serviceName>/deploymentslots/<production_or_staging>
  3. i.                   Add the HTTP header x-ms-version: This specifies the version of the SM API that is being targeted.
  4. ii.                  Add a certificate to HttpWebRequest: To learn how to create and add a local self-signed certificate (for development), check this link: http://blogs.msdn.com/b/ericnel/archive/2009/09/22/using-iis-to-generate-a-x509-certificate-for-use-with-the-windows-azure-service-management-api-step-by-step.aspx
  5. v.                 Set the Method property to “GET” and set the ContentType property to “text/xml”.
  6. Perform the GetResponse operation. That’s it! You have made your first call to the Windows Azure fabric using the SM API, and received a response.

Figure 3. Deployment information.

Get the service configuration file:

    1. The response XML from the previous step forms the input for the following calls.
    2. i.       Use XML parser to read all the contents of the node “configuration”.
    3. ii.      Convert to the appropriate ASCII string.  
    4. v.     The final output of this function will return the XML from your serviceconfiguration.cscfg file (which is the configuration settings file for the Windows Azure hosted application).
  1. Figure 4. Service configuration.

     

  2. Change the instance count:
    1. Take the service configuration XML from the previous step, the “role name” (as seen on the management portal) and the new instance count value, to perform the following call.
    2. i.       Parse the XML file to filter for all contents within the given “role name” and further filter for contents within the “instances” child node.
    3. ii.      Change the attribute value for the instance count to the desired value.
    4. v.     Save this new XML and return it.
  3. Figure 5. Change instance count

     

  4. Commit the new service configuration file to Azure through service management API:
    1. Create HttpWebRequest with https://management.core.windows.net/<subscription_id>/services/hostedservices/<service_Name>/deploymentslots/<production_or_staging>/?comp=config
  5. (please note the query string parameter).

    1. i.       Perform similar operations as step “a” for adding certificates, x-ms-version HTTP header, etc.
    2. ii.      Specify request Method property as “POST” and ContentType as “application/xml”.
    3. v.     Add the “new configuration file” as the request stream content payload.
    4. Perform the GetResponse operation.

    Figure 6. Get response request

    In the next Windows Azure guide article we will take this simple and basic application and enable auto-scaling based on diagnostics data (using the Microsoft.WindowsAzure.Diagnostics API) or storage data structures (such as the Windows Azure queue) that will provide rules/triggers for initiating the scaling process. Meanwhile, please refer to the following article on implementing this along with source code here:  http://msdn.microsoft.com/en-us/magazine/gg232759.aspx

  6. About the author: Saranya Sriram works as a Developer Evangelist in Microsoft India, and focuses on Microsoft’s latest cloud services technology. She has spent considerable time in other Microsoft business units in India and Redmond. She is passionate about technology, community meet-ups, presentations, demos and two-way dialogues. She is a graduate from BITS Pilani in Computer Science, and has a Masters degree in Physics.

 

This was first published in May 2012