Deploying Windows Azure Application to Compute Emulator & Evaluating role configuration change in Compute Emulator (dev fabric)

Deploying Windows Azure Application to Compute Emulator

&

Evaluating role configuration change in Compute Emulator (dev fabric)

In earlier days if I wanted to see how the application is going to behave after we tweak the configuration values in .cscfg file I used to deploy them on azure to evaluate the code which deals with role environment change though it is time consuming and few bucks for azure usage. Later I found a way to evaluate all my code which deals with role environment change in local compute emulator (dev fabric) and started making most use out of it. There are plenty of azure command line tools availale, but at first cut I found this “csrun” tools as very handy. Here are the ways to deploy your cloud application to compute emulator, change configuration values and evaluate it.

To evaluating the role environment change events, we need to deploy the application either using csrun.

For this I have used an application called cloudplay, which has 1 worker role, 1 ASP.Net web role and 1 ASP.Net MVC 3 worker role.

In that worker role I have a setting called ‘setting1’ and will be this value as Trace Information in regular interval, this has been used to reflect changes happening in configuration file.

Deploying the application through CSRUN :

1. Open Windows Azure Command Prompt in Administrator Mode ( StartàAll Programs à Windows Azure SDK v1.5 àWindows Azure SDK Command Prompt )

2. Change the directory to where your csx and cscfg files are located

3. Once changed the directory execute the below command

csrun /run:cloudplay.csx;serviceconfiguration.cspkg /launchbrowser

Note: You can skip the /launchbrowser flag if you don’t have web role in the cloud service.

4. Look for the command prompt for deployment Id and note it down. (Shown above in the image)

5. Now open the Compute Emulator UI and see the instance count of ‘worker’ and trace information written as ‘arun’.

Note : I tried deploying it through VS and updated the configuration through CSRUN, it doesn’t work.

After the successful deployment we could modify the configuration anytime, for making the change and bringing them online refer the below steps.

1. After the successful deployment open the ServiceConfiguration in any text editor.

2. Modify any configuration setting’s value, save it. (For better understanding , change the role instance count of any role)

a. Preferably modify the setting1 value, save it. ( Here I have changed both instance count of ‘Worker’ and value of setting1.

3. Go to command prompt again, ensure you are in the same directory of service configuration file.

(If you are not in service configuration directory, you need to use the full path)

4. Now run the below command.

csrun /update:101;Serviceconfiguration.cscfg

5. Look the command prompt for configuration update messages

6. Open the compute emulator UI, and look new value of setting1 getting written into it. (If you modified the role instance count instead of modifying the setting1 , please look for the newly modified number of instance ).

Notice, after the updating the configuration now worker has 2 instances and its printing ‘arunprasad’ instead ‘arun’.

Likewise, you will be able to modify any configuration setting value.

Windows Azure Storage Crisp Definition

Picture 1: Windows Azure Storage provides blobs, tables, and queues.

The ability to execute code in Windows Azure Compute is a fundamental part of an Azure platform, but it’s not enough. Applications also need persistent storage. Meeting this need is the goal of the Windows Azure storage service, generally the when we hear the sound “Storage” it is obvious that we are thinking about Relational Data Base, Storage medias but this Windows Azure Storage is not a Relational DB / Storage media. This is different and completely no SQL. Below is the crisp definition for Windows Azure Storage.

Applications work with data in many different ways. Accordingly, the Windows Azure storage service provides several options. Those options were depicted in above picture (Picture 1)

The simplest way to store data in Windows Azure storage is to use blobs. A blob contains binary data, and as Picture 1 suggests, there’s a simple hierarchy: Each container can contain one or more blobs. Blobs can be big—up to a terabyte—and they can also have associated metadata, such as information about where a JPEG photograph was taken or who the singer is for an MP3 file. Blobs also provide the underlying storage for Windows Azure drives, a mechanism that lets a Windows Azure role instance interact with persistent storage as if it were a local NTFS file system.

Blobs are just right for some situations, but they’re too unstructured for others. To let applications work with data in a more fine-grained way, Windows Azure storage provides tables. Don’t be misled by the name: These aren’t relational tables. The data each one holds is actually stored in a group of entities that contain properties. And rather than using SQL, an application can query a table’s data using the conventions defined by OData. This approach allows scale-out storage—scaling by spreading data across many machines—more effectively than would a standard relational database. In fact, a single Windows Azure table can contain billions of entities holding terabytes of data.

Blobs and tables are both focused on storing and accessing data. The third option in Windows Azure storage, queues, has a quite different purpose. A primary function of queues is to provide a way for Web role instances to communicate asynchronously with Worker role instances. For example, a user might submit a request to perform some compute-intensive task via a Web interface implemented by a Windows Azure Web role. The Web role instance that receives this request can write a message into a queue describing the work to be done. A Worker role instance that’s waiting on this queue can then read the message and carry out the task it specifies. Any results can be returned via another queue or handled in some other way.

Regardless of how data is stored—in blobs, tables, or queues—all information held in Windows Azure storage is replicated three times. This replication allows fault tolerance, since losing a copy isn’t fatal. The system provides strong consistency, however, so an application that immediately reads data it has just written is guaranteed to get back what it wrote. Windows Azure also keeps a backup copy of all data in another data center in the same part of the world. If the data center holding the main copy is unavailable or destroyed, this backup remains accessible.

Windows Azure storage can be accessed by a Windows Azure application, by an on-premises application, or by an application running at a hoster or on another cloud platform. In all of these cases, all three Windows Azure storage styles use the conventions of REST to identify and expose data, as Figure 4 suggests. Blobs, tables, and queues are all named using URIs and accessed via standard HTTP operations. A .NET client can use a Windows Azure-provided library to do this, but it’s not required—an application can also make raw HTTP calls.

Creating Windows Azure applications that use blobs, tables, and queues can certainly be useful. Applications that rely on relational storage can instead use SQL Azure, another component of the Windows Azure platform. Applications running on Windows Azure (or in other places) can use this technology to get familiar SQL-based access to relational storage in the cloud.

References

1. MSDN

2. Windows Azure updates April 2011

3. David Chappell’s Azure Platform