Windows Azure is an upcoming operating system for the cloud from Microsoft, announced on October 27 at PDC. Windows Azure provides developers with on-demand compute and storage to host, scale, and manage Web applications on the Internet through Microsoft data centers. Azure goes beyond what other providers, such as Rackspace's Mosso or Amazon's EC2, offer. First, it will be available with a complete suite of tools and technologies for building your next big cloud application. Second, the Azure platform's goal is to support all developers and their choice of IDE, language, and technology; meaning that you can use your favorite tool for all kinds of development as well as Python, PHP, Ruby, Eclipse and so on. It supports popular standards and protocols including SOAP, REST, and XML. Using the Windows Azure tools, developers can build, debug, and deploy to Windows Azure directly from their existing development environment.
Figure 1: Azure Services (courtesy of www.azure.com)
Windows Azure will be renamed to something else and will be available in the second half of 2009. Pricing will be based on resource consumption like CPU cycles, bandwidth an storage. Your obvious question is how we can develop applications right now since Windows Azure has not been released yet. Microsoft released the first CTP of the SDK and Tools for Visual Studio to let you write applications right away.
Some of the key features of Windows Azure platform are:
- Windows Azure provides a scalable and highly available virtualized hosting environment on which you can develop and deploy .NET applications. The environment includes machines and load balancers, so that you can create your own scalable applications.
- It provides a storage service that includes support for blobs, tables and queues, which means that you can concentrate your development efforts on your core business logic.
- It is bundled with lot more other new tools and technologies to leverage your applications with .NET Services, SQL Services, Live Services and so on.
- How many times a year have you seen Microsoft’s sites down? Who doesn’t want to host their apps within Microsoft’s Data Centers which pretty much ensures reliability and low downtime?
- Scalability? We will talk about it a bit later.
- Windows Azure SDK CTP
- Windows Azure Tools for Microsoft Visual Studio October 2008 CTP
- For more information or related downloads: http://www.azure.com/
Some more downloads might be required depending on what you have got installed in your machine, so the best way to get all working is reading the release notes and find the pre-requisites for your PC. After you have installed these as instructed you will be good go with application development on Azure. You will find new items in the New Project dialog box as Blank Cloud Service, Web and Worker Cloud Service etc. in Visual Studio. Obviously - like any other CTPs - Azure SDK may crash your Visual Studio or PC several times during development, so use them at your own risk.
The Azure Todo-list
At a first look, Azure may seem complicated, that is why I have chosen a simple Todolist web application to illustrate how to create your first application on Azure from scratch. The application has Sign up, Sign in forms and a Tasks webform which uses an
UpdatePanel to perform AJAX operations.
Figure 2: Task list
Figure 3: Add New Task
This application will let users add tasks into their Todolist and track them at a later time. The objective of this application is not to use any local data storage like SQL database. Instead, it will store and retrieve data from the cloud which means no matter which language/platform you write your application on, it will be able to access the data. For instance, if you would like to develop an iPhone application which will be able to play with your saved tasks on the go, you will be able to do so. That does not mean you do not need SQL Server in your local development PC, because Azure SDK under the hood makes use of your local SQL Server instance to simulate cloud environment for you. We will discuss this a bit later.
Before we start, I want to apologize for not picking a color scheme based on the color Azure - oh well. Let’s dig into some code.
For our solution I chose the Web Cloud Service type project, which brings up two projects called AzureTodolist and AzureTodolist_WebRole. I have also added a new project named AzureTodolist.Models which contains the required business logics and objects.
Figure 4: Solution structure
An Azure application may contain three types of projects:
- Service (AzureTodolist): This type of project defines the service definitions which will be used to communicate with the cloud environment,
- WebRole (AzureTodolist_WebRole): Contains usual ASP.NET WebForm project, and
- WorkerService: Responsible for performing asynchronous actions (which we won't be looking at).
The Service Definition and the Service Configuration
ServiceDefinition.csdef contains the service definition of the project. In this file you can define both the WebRole and WorkerRole. Inside the definition XML file, you will find a
ConfigurationSettings block like the following:
Here you see
AccountSharedKey, which are the two properties required by Windows Azure to access resources from your particular account. This information identifies you to Windows Azure. The
TableStorageEndPoint is a property that we will use to define where Azure should look for our database stuff. In this XML file, note the
InputEndpoints element which you can use to define http/https or ports and so on. Now open up the ServiceConfiguration.cscfg file which holds the value for the properties defined before:
The values set for
AccountSharedKey can be used in your PC for your own use. Note the value for
TableStorageEndpoint. Table storage service is running at this endpoint. Similarly there are two other services for Blob and Queue which we will not cover in this article. We will only work with Table. You can see the running services in the system tray when you run the solution:
Figure 5: Development Storage
A very important element is
Instances which has a property
count=”1” which means there will be only one instance of the WebRole we are defining. You can also change this value to two or more if you need to simulate multiple instances of your application. You can also find a Development Fabric UI in the tray while you run the application to trace and monitor the WebRole and WorkerRole activities and their instances:
Figure 6: Development Fabric UI
You can also see the local data store for this by running WebRole from Tools > Open local store. The diagram below has been taken from the Azure SDK documentation to help illustrate the concept of Service Definition and Configuration:
Figure 7: Service Definition and Service Configuration
AzureTodolist_WebRole is a fairly typical WebForms application. We will make use of a library called StorageClient.dll which you can find in your <Azure-SDK-installation-directory>\v1.0\samples\StorageClient\Lib\bin\Debug folder that basically wraps up a client for the storage services we can utilize. Since we do not have any SQL database in action, we need to make sure of the availability of the tables that our application demands to run correctly. In order to accomplish that, in the
Application_BeginRequest event - inside Global.ascx.cs - we will invoke a method from that library which makes sure that the data model we are expecting in the application already exist. If not, it creates the tables and makes them available for us:
TodolistContext is a tiny little class responsible for defining the data model required in our applicaton:
Listing 1: Listing of AzureTodolist.Models.TodolistContext.cs
This class tells the caller that we are going to need two types of tables:
SiteUserTable that are in turn defined by the classes
SiteUser. Note that the class has been inherited from
TableStorageDataServiceContext, which helps into our authentication process and connects automatically to the TableStorage endpoint with the account information we stored previously in the Service Configuration file. As you can see we also accessed the Web.config’s
appSettings element which enables us to define whichever table names we want.
The Data Model
The classes inside AzureTodolist.Models.Objects contain the table structures for the application. Let us dig into the Task.cs which defines the Task table:
Listing 2: Listing of AzureTodolist.Models.Objects.Task.cs
Task class has been extended from
TableStorageEntity which is again available in the library that we are using. Instead of inheriting from this class, we could also use the
[DataServiceKey("PartitionKey", "RowKey")] attribute. For ease of use we are extending from
TableStorageEntity because it already has these two properties -
RowKey - under the hood. Each instance of the
Task class is considered to be a row in the table and one of the fields of each row should be unique to distinguish itself.
RowKey just does this for us, and we are leaving it up to
Guid.NewGuid(). Now about the
PartitionKey; this key is used to identify which storage node inside Azure you want the data to be stored. That means that if you look for load balancing among the storage nodes, you’ll get the support. You can distribute rows in many different instances by using this key. We do not need multiple instances for this application, so we are retrieving this value from
appSettings. However, we could also write the constructor of the
Task class like the following:
One very important aspect to remember is that you always need to have a parameterless constructor for the model, because Windows Azure attempts to create a new instance of the object with no parameters and then fill up the properties.
Let us see some UI code inside Tasks.aspx.cs. The code below is fairly simple; we are going to create
TaskService in two different classes inside our Models project. The intention behind such modularity is to increase testability of the code, although we will not write any test code for this app.
Now take a look at the TaskService. The code below adds a new
Task to the Table.
When a context object is being created through
TodolistContext, which eventually is extended from
DataServiceContext, it represents the runtime context of ADO.NET Data Services. The
DataServiceContext enables us to use its
UpdateObject() methods to work on our data - of course followed by
ADO.NET Data Services Under the Hood
We can also run nice LINQ queries against our data context. Have a look at the snippet from TaskService:
Wait, why we did not use
orderby instead of performing a sort operation on C# objects that affects performance? Well, unfortunately we cannot use
orderby and other operators now since they are not implemented yet. We will probably have to wait for the next CTP for that. When such LINQ queries are executed and ADO.NET Data Service comes to action, it generates an URI like the one below:
This is now making sense. Remember the TableStorage endpoint we defined before? Now the ADO.NET Data Service will allow us to connect to this data storage and let us run queries against it. So, in Windows Azure public URIs for your tables will be in the following format, provided that you properly authenticated yourself in you request:
Do you know what is interesting besides this? You will find all your data stored into your local SQL Server instance. See the snapshot below:
Figure 8: Data stored into local SQL Server instance
Useful Command-line Tools
Windows Azure SDK has been shipped with a few tools that you can make use of which I intend to talk about in future articles. These tools are used by Visual Studio as well as the SDK, but you can use them as needed by passing parameters to them. You will have to run them from Windows Azure SDK Command Prompt. Some of them are:
- cspack: helps to prepare the service for deployment.
- csrun: deploys the service to the development fabric and manages it.
- devtablegen: allows you to generate tables for use with the Table Storage Service.
Most common and widely implemented answer to the scalability of application infrastructure is adding new servers, more bandwidth, load balance them, backup, and monitor them 24/7. Those who run enterprises or large websites know the pain of managing and maintaining a web farm. Windows Azure will handle all the hurdles for us so that developers can concentrate only on the business logics and other important aspects of the application. The business owner will have peace in mind that his site will not have any downtime (literally) and can expand on demand, thus makes his site durable, scalable and available all the time. No more sleepless nights and nightmares fixing the servers, database failure, backup/restore. He will probably host the application in Azure and watch it grow.
Developers are going to be up to the speed because they will write code in their same old environment, tools and technologies. Unlike Mosso, Amazon EC2 and Google App Engine, Windows Azure is going to support almost all languages and all platforms, and their approach to open standards certainly is a blessing for the developer community.
This article illustrated how you can write applications for Windows Azure. Microsoft has unleashed the most advanced and optimized virtualization technology that makes going to the cloud easier than ever. After all who does not want to host in Microsoft’s Data Centers?
You might also be interested in the following related blog posts
Building Applications for Windows Azure
WPF 4 (VS 2010 and .NET 4.0 Series)
Announcing Visual Studio 2010 and .NET FX 4 Beta 2
PDC 2009 Sessions Posted
IDCC conference in Israel – Spet. 14th
Telerik Launches RadControls for Silverlight 3 for Line-of-Business Application Development
A Unique Silverlight Viewer for Reporting Services Aimed to Display Reports from Reporting Services in Silverlight Applications.
Intersoft Solutions Releases WebUI Studio 2009 The Worlds Most Innovative Web Development Toolkit
CodeDigest.Com Article,Codes,FAQs - April,2009
So what is Windows Azure?
Please login to rate or to leave a comment.