Azure Applications 101 – Part I

As any responsible company, we never rest on our laurels. Although it’s already a bit late in the game, we’ve decided to take a peek at how to develop a real-world Azure application. We really don’t like the fact that most online tutorials start and finish with a Hello World or a really complex, enterprise, AppFabric + Service Bus + a myriad of buzzword technologies based example.

Ok, so what do we consider a real-world Application?

Based on applications we have developed so far, most of them consist of the following ingredients (simplified):

• A Web Front-end
• A WCF/Web Service Layer (for external integration)
• A storage back-end
• Runnable services (e.g. indexing, data mining)

Keep in mind this is more of a physical architecture than a logical one, as the architecture within each role is determined based on the project. So to put this into some context, suppose we have a Job Platform. Initially, all data is stored in a typical relational database, like MS SQL or MySQL. But we usually have a few runnable services that index data and store it in special databases (e.g. Lucene/SOLR, Sphinx) for faster searching, some handle analysis of data and others handle data mining. These services need to run at certain time points, periodically or based on events. This data is then accessed from two points, a web front end, and a services layer. Keep in mind this services layer is not the same as with logical architecture, but it merely exposes WCF or Web Services for external consumption – a prime example would be a Facebook application, or a Windows Phone client.

How do these relate to Azure?

Azure’s programming model is based on roles. Azure provides three basic roles:

• Web Role: this is pretty self-explanatory; it interacts with the outside world via HTTP. It can utilize different technologies, but for our purposes we are going to focus on ASP.NET / MVC applications.
• Worker Role: code inside the worker role runs similar to a Windows Services. It can interact with the application and/or the outside world through a variety of ways, either HTTP, TCP, a custom protocol – the sky is the limit. Develops usually use this role to perform operations that need to happen in the background, e.g., indexing, data mining.
• Virtual Machine Role: these roles run a full VHD (Virtual Hard Disk) image, for example of a Windows Server 2008, or even Linux. You create these VHDs from your own machines and migrate to the cloud. These VHDs can be loaded on demand, and you can use them for various tasks, like hosting external services (e.g. SOLR).

When you start your project for the first time, you’ll notice a couple green dots in the Azure Emulator:

These are instances of roles. A typical Azure application runs multiple instances of the same role, and the crucial predicate here is that these instances are inter-changeable. This means that if one instance is shut down for some reason, or fails, the application will continue to function normally. You need this because the basic premise of the cloud is that it allows you to scale your applications according to actual load, not some guesstimate figures.

Azure handles load balancing out of the box already. According to various sources the current implementation performs load balancing with a round robin algorithm, meaning it routes traffic to all instances in a “circular fashion”. Microsoft has, in time for MIX 11, released a CTP of Windows Azure Traffic Manager allowing you to choose your load balancing/routing.

To get a better overview of Azure for Developers, read up on http://www.microsoft.com/windowsazure/Whitepapers/AppFabricForDevelopers/default.aspx.

But what does this mean for our sample application?

To build our real-world application, we now need to map our ingredients to Azure roles. Using the roles provided by Azure, we can deduce the following:

1) Web Role; we will use the web role to host the web front-end, and another web role to host the service layer. We could combine this into one project, but under certain scenarios this may turn out to not be optimal, for example, if our mobile clients make more requests than we anticipated, we wouldn’t necessarily need to scale the web front-end as well – separating them also ensures we won’t get a performance hit for our web users. This depends largely on your application and the way you architect your solution.

2) Worker Role; we will use the worker role to handle data processing, like gathering, data mining. This will be explained later in this series, but in general, each task must derive from RoleEntryPoint.

What about storage?

Our application will use SQL Azure for its relational database needs. SQL Azure is a relational database service based on SQL Server. It should, in theory, provide a highly available, scalable multi-tenant database service. It supports T-SQL out of the box and you can use the existing models and knowledge to use the service itself. There are some differences between the full SQL Server and SQL Azure and this will be explained further in a follow-up post.

Real-world Application

So to demonstrate how to use Azure in a real-world application we will build a Food Ordering Application. It will be accessible from a MVC 3 based web application. It will also expose a WCF service with functionality to get the current list of available menu items, and put down an order for a person. This WCF will be available externally as well as internally (inside our project, but for different roles). To help us with our choice, it will perform weekly indexing of data from the restaurant web site to parse available menus.

Tags: Azure, C#, Cloud, development, Introduction, SQL Azure