Moving Your Applications to Windows Azure

  • Article

Lifestyle experts will tell you that moving to a new home is one of the most stressful events people undertake during their lifetime yet, given a choice between that or moving applications to a new platform, many of us would unhesitatingly start packing the china. Thankfully, however, moving your applications to Windows Azure is a breeze.

For many years, Microsoft has been building highly scalable applications in datacenters around the world—applications that have global reach and high availability, and offer great functionality to users. Windows Azure allows you to take advantage of the same infrastructure to deploy your own applications, with the corresponding capabilities to reduce your maintenance requirements, maximize performance and minimize costs.

Of course, people have been outsourcing their applications to third-party hosting companies for many years. This might be renting rack space or a server in a remote datacenter to install and run their applications, or it might just mean renting space on a Web server and database from a hosting company. In either case, however, the range of features available is usually limited. Typically, there’s no authentication mechanism, message queuing, traffic management, data synchronization or other peripheral services that are a standard part of Windows Azure.

It might seem like all of these capabilities make moving applications to Windows Azure fairly complex, but as long as you take the time to consider your requirements and explore the available features, moving to Windows Azure can be a quick and relatively easy process. To help you understand the options and make the correct decisions, the patterns & practices group at Microsoft has recently published an updated version of the Windows Azure migration guide: “Moving Applications to the Cloud on Windows Azure” (msdn.microsoft.com/library/ff728592).

The guide covers a wide range of scenarios for migrating applications to Windows Azure. In the remainder of this article I’ll explore these scenarios, look at the decisions you’ll need to make, and see how the guide provides practical and useful advice to help you make the appropriate choices. While the guide follows a somewhat-contrived multi-step migration process—which most people are unlikely to follow in its entirety—this approach demonstrates most of the options and shows the capabilities of Windows Azure that might be useful in your own applications. Figure 1, taken from the guide, shows a conceptual map of the migration paths you might follow when moving an application from an on-premises datacenter to Windows Azure.

A Conceptual Map of Some of the Possible Migration Paths in Windows Azure
Figure 1 A Conceptual Map of Some of the Possible Migration Paths in Windows Azure

Infrastructure or Platform Hosting?

As you can see from the map, the initial decision when migrating to Windows Azure is to choose which route to follow—Infrastructure as a Service (IaaS) or Platform as a Service (PaaS).

As its name suggests, the IaaS approach provides the runtime infrastructure—such as a virtual server and network connectivity—­for you to install the OS, services and applications of your choice. Effectively, you just pick up your server and run it in Microsoft datacenters. Windows Azure offers a range of preinstalled OSes you can choose from (such as Windows Server and Linux), and you can still take advantage of peripheral services, such as authentication though Windows Azure Active Directory, messaging with Windows Azure storage queues or Service Bus, global routing to your application through Traffic Manager, and more.

Alternatively, you can have Microsoft manage the OS and runtime platform for you by adopting the PaaS approach. Windows Azure Web Sites provides an easy-to-use hosting platform for Web applications and Web sites with simple management and deployment capabilities that can integrate directly with many source control systems, and supports a range of programming languages. If you want more control over the platform, including the capability to run a mixture of different types of roles and directly integrate caching, you can choose the Cloud Services approach. This allows you to deploy separate Web and worker roles; provides a wider range of configuration options; and is well-suited to a versioned and staged deployment environment.

As you’ll see later in this article, the choice between IaaS and PaaS isn’t limited to application code. When you follow the IaaS route, you can choose to deploy a Windows Azure Virtual Machine (VM) that has a database such as SQL Server or MySQL preinstalled. Meanwhile, on the PaaS route, Windows Azure also offers a hosted database mechanism called Windows Azure SQL Database that’s effectively a hosted SQL Server instance you can use in almost exactly the same way as an on-premises SQL Server.

Getting to the Cloud with IaaS

There are several distinct advantages to using the IaaS approach for hosting your applications. For example, you might be able to move to a VM in the cloud without needing to make any changes to your application code, and connect it to your internal network and domain through a virtual network, and all of your testing, deployment, management and monitoring systems will continue to work much as they did before.

Effectively, all you’ve done is replace the Ethernet cable in your datacenter with an Internet connection to Windows Azure. A Windows Azure virtual network can connect your on-premises network to a network you configure in the cloud using a standard virtual private network (VPN) router, allowing you to use internal network IP addresses just as you would on-premises. Yes, there is some additional latency over the connection, and you’ll need to consider how to handle occasional transient connection failures, but you are freed from the need to manage and update the hardware, infrastructure and OS. (To handle transient connection failures for many different kinds of operations, consider using the Microsoft Transient Fault Handling Application Block. For more details, see msdn.microsoft.com/library/hh680934(PandP.50).)  

The IaaS approach using Windows Azure VMs is ideal when you need to run software or services where you don’t have access to the source code or you can’t modify the application (such as when you depend on a third-­party application). It also works well if you need a non-standard configuration of the OS or the usual services, or if you want to be able to set specific permissions on files and resources.

In terms of testing and deployment, your development teams will see no difference from existing processes. The on-premises development computers and the build server can deploy to the test and production environments in Windows Azure, or you can locate the test and build servers in the cloud. Figure 2, based on a figure from the guide, shows an example of a test and deployment configuration that encompasses both on-premises and cloud-hosted testing environments by using two separate Windows Azure subscriptions—one for testing and one for the live application.

Overview of a Possible Development, Test and Deployment Mechanism
Figure 2 Overview of a Possible Development, Test and Deployment Mechanism

So the only real difference when choosing the Windows Azure IaaS approach is that the application is no longer running in your own expensive, air-conditioned server room, consuming resources and demanding bandwidth from your Internet connection. Instead, it’s running in a Microsoft datacenter of your choice where changes to the VM are persisted in the backup storage of the original image, reliable connectivity is provided at all times and the runtime platform will ensure that it’s continuously available.

In addition, you can choose from a range of sizes for your VM; update the running instances when required; configure the OS and its services to suit the application’s specific demands; deploy additional instances to meet changes in load; and even set up automatic routing to deployments in different datacenters to maximize availability and minimize response times for users around the world.

Simplifying Management with PaaS

If you want to avoid managing the OS yourself, you might choose the PaaS approach. While this does mean that you give up some opportunities to configure your runtime platform, it reduces administrative tasks and management costs because Microsoft is responsible for maintaining the servers, updating the OS and applying patches. You simply concentrate on the application code and its interaction with peripheral services.    

The easiest way to move a Web site or Web application to Windows Azure is to deploy it to Windows Azure Web Sites; very few, if any, changes are required to the application. You can deploy from Microsoft Team Foundation Server (TFS) or other source code repository systems such as GitHub. Depending on your needs and your hosting budget, you can choose to host on a shared Web server or on a reserved instance where you can guarantee the performance and manage the number of instances to meet demand.

Alternatively, if you need a built-in mechanism for versioning deployments and staging applications, as well as the freedom to scale parts of the application separately, you may decide to use Windows Azure Cloud Services Web and worker roles to host your application. By moving the background tasks to worker roles and placing the UI in Web roles, you can balance the load on the application, perform asynchronous background processing, and scale each type of role separately by running the appropriate number of instances of each one.

(To implement autoscaling for roles in a Cloud Services deployment on a predefined schedule, or in response to runtime events such as changes in server load, consider using the Microsoft Autoscaling Application Block. For more details, see msdn.microsoft.com/library/hh680892(PandP.50).)  

To connect Web and worker roles, you typically pass data between them as messages using Windows Azure storage queues or Windows Azure Service Bus queues. (Service Bus queues support a larger message size and have built-in facilities for authentication and access control.) Using messaging also opens up the design to allow the use of standard messaging and storage patterns such as Request/Response, Fire and Forget, Delayed Write, and more. If your application is built as components following a service-oriented architecture (SOA) design, moving it to Windows Azure Cloud Services will be relatively easy. 

Of course, using Web and worker roles can mean that some refactoring of the application is required. However, in many cases this isn’t onerous and doesn’t affect the core business logic or presentation code. For example, ASP.NET MVC applications work fine when migrated to Windows Azure, and they can access data stores such as SQL Server in exactly the same way as when running on-premises or when deployed to VMs using the IaaS approach.

Moving to Windows Azure Cloud Services can also present an opportunity to update your authentication and authorization mechanism, especially if you find you need to perform some refactoring of the code. Modern applications increasingly use a claims-based authentication mechanism, including federated identity and single sign-on (SSO).

This type of mechanism allows users to sign on using a range of existing credentials rather than requiring specific credentials just for your application, and to sign on only once when accessing more than one application or Web site. The access-control feature of Windows Azure Active Directory, along with Windows Identity Framework (WIF), makes implementing claims-based authentication and federated identity easy. Figure 3, based on a figure from the guide, shows an example for the fictional company Adatum’s a-Expense application, where users are authenticated by their own Active Directory and are issued a token that they present to the application in order to gain access.

Adopting a Claims-Based Authentication System
Figure 3 Adopting a Claims-Based Authentication System

For more information about claims-based authentication, check out the related patterns & practices publication, “A Guide to Claims-Based Identity and Access Control,” at msdn.microsoft.com/library/ff423674. 

Where Will My Data Live?

Almost all business applications use data, and often this is stored in a database such as SQL Server or a relational database management system (RDBMS) from another supplier. A typical scenario when migrating an application that uses a relational database is to deploy a Windows Azure VM that hosts the database server (Windows Azure provides preconfigured VMs containing either SQL Server or MySQL). Alternatively, you can install almost any other type of data store that runs on Windows or Linux in a VM running in Windows Azure.

You connect to a cloud-hosted database from your cloud-hosted application just as you would if the database and application were located in your own datacenter. However, this is only one of the options available in Windows Azure. Typically you’ll need to decide whether you deploy the data for your applications in the cloud, or keep it on-premises and communicate with the database server over a virtual network or through messaging. If you choose the cloud, you must also decide whether to follow the IaaS or PaaS (SQL Database) path.

The Command Query Responsibility Segregation (CQRS) pattern typically uses messaging to communicate data updates and query results between application components, and Windows Azure provides two queuing mechanisms your application can use for this. However, for standard data access, introducing a network such as the Internet between the application and the database can result in delays and subsequent poor performance. If circumstances or regulatory requirements demand an on-premises database, Windows Azure Caching can help to reduce these delays. (For more information about the CQRS pattern, check out the related patterns & practices guide, “CQRS Journey,” at msdn.microsoft.com/library/jj554200.) 

Windows Azure SQL Database is an ideal solution for general data storage when migrating an existing application that uses SQL Server. Unless the code requires some of the more esoteric features of SQL Server—such as free text search, XML handling capabilities, procedures that require CLR programmability, or distributed queries that rely on the SQL Server Service Broker—the existing application will work with no changes.

Windows Azure SQL Database is also very cost-effective when you need to store only the usual volumes of data. However, for very large volumes of data or when you need to deploy many databases, using a database server hosted in a VM becomes an attractive solution. You can choose the appropriate size of VM, and even use multiple VMs to implement database failover or a shared data store.

Sometimes data storage and querying needs go beyond the capabilities of relational database systems. For example, corporations often have petabytes of data in Web server logs, financial transaction files, social media information, medical data, or other types of data that aren’t regularly processed but might be of use for occasional or future querying. Windows Azure offers the HDInsight service (based on open source Hadoop technologies) for just this scenario. For more information, see hadooponazure.com.

Tables, Blobs, Queues and Drives

Windows Azure also offers a different type of storage that’s not based on the relational SQL paradigm. You can use Windows Azure storage tables and blobs to store application data, storage queues to pass messages between application components and storage drives that act rather like a traditional disk-based filing system.

Windows Azure storage tables are schema-less, meaning each row is an entity containing a property bag of values, and a table can have different types of entities in each row. This is ideal for structured (columns and rows) and semi-structured data. Windows Azure storage blobs, on the other hand, are better suited to storing unstructured data such as documents, binary data, XML files and images.  

Windows Azure storage is also very cheap compared to using a VM-hosted database server or SQL Database, but it does mean that existing data-access code must be rewritten. Typically, Windows Azure tables and blobs are more useful when you design your applications from scratch to run in Windows Azure. However, if your application has a clearly delineated data-access layer that you can replace with one designed to use Windows Azure tables and blobs, it’s reasonably easy to change over to using Windows Azure storage instead of a relational database.    

As with all cloud-based services, there’s a chance that transient network issues or intermittent and temporary throttling of resources could cause an initial connection request to fail. The Transient Fault Handling Application Block (mentioned earlier) can be used to automatically detect failures and retry all storage operations, including relational databases and Windows Azure storage. This is a good practice for all cloud-based applications, and the Transient Fault Handling Application Block makes it easy to implement.

Worker Roles and Background Tasks

One of the strengths of Windows Azure Cloud Services is the provision of a special type of role designed to perform background processing. The worker role isn’t limited to use only as an ancillary part of an application; in reality it’s a Web role without the Web server (IIS) installed. However, the typical scenario is to run continuous tasks in the worker role that listen on Windows Azure queues (or Service Bus queues) for messages that instruct the role to perform some action in the background, as illustrated in Figure 4.

Passing Messages from a Web Role to a Worker Role
Figure 4 Passing Messages from a Web Role to a Worker Role

Separating out asynchronous and background tasks in this way helps you to implement many basic application design principles such as separation of concerns and single responsibility. By passing information and commands as messages between roles, you aid encapsulation of each role and reduce dependencies, in much the same way as when applying SOA principles.

For example, the guide explores how Adatum uses worker roles to compress and store images of receipts uploaded by users so as to conserve storage space, and to export the expenses data to the Adatum payroll application. Both tasks are initiated by a message placed in a queue. The message contains data relevant to the individual task.    

As you refactor your application for deployment to Windows Azure Cloud Services roles, tasks that are suitable for running in a worker role will usually be obvious. Background tasks may also be initiated on a schedule, and you can minimize hosting costs by running more than one task in a worker role as long as you include code to restart any that might fail or stall. Windows Azure does detect when a role fails and will attempt to restart it, but it can’t detect when an individual task in a role fails.

You must also consider how you will handle any feedback or output from the background task. For example, you might decide to use the delayed write pattern to store details of the orders that users submit by packaging each one in a message that the UI sends to a worker role task. The worker role will read the message from the queue and store the details in the database. However, if the order number is generated only at the point of storage, it will be more complex for the worker role to return this order number to the Web role for display in the UI.

Can I Afford Windows Azure?

As you’ve seen, Windows Azure contains a broad range of features and services that should fulfill all your applications’ requirements, even if you aren’t exactly sure what all of them are at the moment. You can deploy to any of the datacenters located around the world and take advantage of huge storage and scalability capabilities. But can you actually afford to have your applications live in Windows Azure? 

In Chapter 6, “Evaluating Cloud Hosting Costs,” of the guide, Adatum carries out several costing exercises to discover approximately how much it will be billed for running its a-Expense application in Windows Azure. The application will use a single Web role and a single worker role, and will need to store about 20GB of data in a relational database and 120GB of images in Windows Azure storage. At current prices, Adatum expects this to cost around $3,000 per year. Although Adatum can’t accurately identify the cost of running this application in its own datacenter, because many of the resources it uses are shared with other on-premises applications, the expected cost on Windows Azure compares very favorably.

Even better, by introducing an autoscaling solution such as the Enterprise Library Autoscaling Application Block, Adatum calculates that it can run the application only during office hours, but double the capacity by adding extra role instances at the end of each month when most expenses are filed, and reduce the overall cost to something around $2,000 per year. Moreover, by adapting the application to use Windows Azure tables and blobs instead of SQL Database or SQL Server, Adatum calculates that it could save an additional $750 per year.

Of course, your own application capacity requirements and operating schedules will be different, and will depend on the load the applications must handle and the storage they require. However, it seems clear that you can afford to live in Windows Azure, and that moving in will be a great deal less stressful than moving your family to a new home!

More Information

The patterns & practices guide, “Moving Applications to the Cloud on Windows Azure,” is available at msdn.microsoft.com/­library/ff728592. You can download a PDF copy of the guide from microsoft.com/download/details.aspx?id=29252.

The associated guides and frameworks from patterns & practices are:

You can find the Windows Azure homepage at windowsazure.com, and the Windows Azure Developer Center is at windowsazure.com/en-us/develop/overview.