In the previous article in the Monitis blog we discussed the design of Windows Azure. In this article we will focus on the advantages and disadvantages of using that design — compared to an on-premises solution.
Let’s first look at the advantages of using Windows Azure:
- Per-use pricing
As with other cloud services, Windows Azure charges the subscriber on per use basis. What this means is that if your application needs only two instances in the beginning, you will only pay for these two instances. At the moment your application starts needing four instances for example, you will start getting charged for those extra instances. This pricing model makes Windows Azure a great platform for applications that occasionally need a lot more resources than normal. It completely eliminates the need to purchase expensive hardware and software for building your applications.
You can add or remove instances to your application whenever you feel the need to. If everything with your application goes well and you get more and more users using it, you can provide more instances for its use by just changing a number in the configuration file. And, if over time, it proves that the application doesn’t need as many resources, you can easily lower the number of instances.
Windows Azure uses a standard Service Level Agreement (SLA) that ensures you get 99.95% uptime for any application that Microsoft runs on your behalf. The design of Windows Azure allows the Fabric controller position your application to be on different physical servers that can’t be a single point of failure. So, all of your data is stored in three locations.
The design of Windows Azure allows the Fabric controller to identify problems with instances of an application and to power on a new instance in case the previous one crashes. The recoverability is managed entirely from Microsoft. Fabric controllers help to ensure the integrity of SLAs.
- Eased management
The Fabric controller takes care of managing your applications. It first makes decisions about where to run them. Then, it monitors their performance. The Fabric controller saves the collected information and developers can write code on how to use that information. In case an instance crashes, the Fabric controller brings up a new one. It is also responsible for patching the operating system of the virtual machine that runs the instance. All of these management tasks happen in the background without the customer’s concern.
- Ability to integrate with the on-premise infrastructure
The Connect feature of Windows Azure allows the applications that run in the cloud to use on-premises resources and services. The applications can use users and groups from the on-premises Active Directory for creating access rules and they can use internal databases for storing sensitive data.
As with every solution, there are some disadvantages in using Windows Azure including:
- At least two instances per role
The design of Windows Azure makes it necessary for each role of your application (Web role or Worker role, for example) to run on at least two instances. Microsoft designed it that way in order for the Fabric controller to be able to stop one of the instances for restarts after patches or other maintenance procedures.
- Load-balancing between the instances may interrupt stateful applications
With Windows Azure, there are at least two instances of each role that the application needs. So, the Fabric controller load balances users’ requests between them. What this means is that there is no guarantee two requests from the same user will go to the same instance. This may be a problem with some applications that need a stateful connection with the user. A stateful connection is one in which some information about a connection between two systems is retained for future use.
Knowing the advantages and disadvantages of Windows Azure is important, but it is also important for you to understand the pricing that goes with it. With this knowledge you will be able to informatively decide whether Windows Azure is the right platform for your applications or not. We will discuss the pricing model in the next article in this series.