Windows Azure provides many remarkable services that benefit its customers. Assuming that you’ve already decided to hop on Windows Azure, some questions you might be asking include: What are the key considerations when moving applications to the cloud? How do you move an application to the cloud?
The goal of this article is to discuss several common considerations (including any changes that might apply) when moving your application to Windows Azure. Though there are also significant concerns from business perspective, this article will focus on the technical aspects.
The first and probably the most significant consideration is the architecture. Your current architecture may or may not work perfectly on the cloud. Some applications may be moved easily and without many changes, while others may require a certain degree of alignment to fit a cloud-centric architecture.
Designing architecture that fits into the cloud model sometime is not enough.
More important is designing the architecture that brings optimal results. For instance: faster response time, elastically scalable system, and cost effective solution.
If your current application is deployed on multiple instances (a.k.a. a web farm), you are one step closer to a cloud-centric architecture. I would recommend you to check out this post on the web farm concept to see where the differences are compared to single-instance deployment. The web farm architecture is naturally very similar to Windows Azure multiple-instance deployment.
Even though you can have a single instance for your Windows Azure deployment, it’s recommended to have at least two instances per role to meet the 99.95% SLA. The instances sitting behind Windows Azure load-balancer will be load-balanced in round-robin.
In web farm architecture, storing information in each individual instance will not work when the information should be shared across instances. The information could refer to session state, any relational data, or any unstructured files. Thus, a central repository is required to ensure that each request from the client will be consistently handled. Figure 1 illustrates how the multiple-instances are deployed in Windows Azure.
Figure 1: Multi-instance architecture
Pertaining to central repository, the following summarizes various options that best suit shared information.
The second aspect that should be taken into account is application-level security. This will eventually lead to the question: How do you manage your user account and profile? Many applications use database or Active Directory to keep their user profile. There are also some that rely on third-party identity providers.
Below describes how each method will be reformed when moving the application to Windows Azure.
Storing user accounts inside the database is perhaps the simplest method. As long as the database you are using is compatible with SQL Server 2008, to migrate it to SQL Azure shouldn’t be too much trouble. The user account tables should be migrated along with the other tables in your database.
If you are using ASP.NET Membership Provider, migrating to SQL Azure is even easier with the availability of ASP.NET Universal Provider Nuget Package.
Active Directory is popular choice, especially for corporate applications. This avoids having one person (with a single user ID) manage different accounts across many applications. With the release of ADFS (Active Directory Federation Service) 2.0, third party applications, regardless of whether they’re residing on-premise or in the cloud, can authenticate to corporate Active Directory account using claim-based authentication.
Nowadays, many applications, especially public facing websites, rely on third-party identity providers (such as Google ID, Live ID, Facebook, etc.) to perform authentication. Fortunately, Windows Azure offers Access Control Service which simplifies the authentication process with multiple identity providers.
Even though cloud solutions provide a wide-range of services, there are also some limitations. To know what’s available and what isn’t is the responsibility of cloud architects when designing a cloud solution for their customers. For the features that are unavailable, the architects should provide alternate solutions that meet the requirements.
The following discusses an example of a potential limitation in Windows Azure and how it could be overcome.
Logging and monitoring are important as they could be used to tracing exceptions, monitoring performance, and planning for capacity.
Although configuring them is normally not difficult, there are some differences between performing these tasks on-premise or in the cloud. For one thing, you might have many instances in a cloud environment, the cloud instances aren’t persistent and, they might have a massive amount of data.
Now, the goal is to store the diagnostic information persistently, accessibly, and cost-effectively so that the diagnostic information can be viewed and monitored easily.
Windows Azure Diagnostic (WAD) enables you to collect diagnostic information from your Windows Azure application. WAD transfers the diagnostic information to Windows Azure Storage to ensure its persistency. The transfer can happen either on a schedule or on-demand. As we know that Windows Azure Storage is a highly-accessible service that’s competitively priced, so that goal can be accomplished.
Data transferred to Windows Azure Storage can be accessed either with tools or API. Some tools (such as Cerebrata’s Azure Diagnostic Manager) enable us to view and monitor the diagnostic information easily through GUI (Graphical User Interface) as is shown in Figure 2. With that, we are able to take appropriate actions.
Figure 2 Cerebrata Azure Diagnostic Manager
I haven’t discussed everything that needs to be taken into account, but the four points discussed above are the some of the key considerations when moving your applications to Windows Azure. Although some changes might apply, the changes are normally around the architecture and design. You don’t have to change the business logic.
In the next article, I will elaborate in more detail with a case study on moving an application to the cloud: starting from the current scenario, challenges that customer faced, architectural changes, and the final outcome.
This post was also published at A Cloud Place blog.