This is the fourth in a four-part series from contributor Patrick Meader on working with Microsoft Azure.
Typical Azure adoption scenarios
There are two basic scenarios commonly cited when using Azure. In the first example, users leverage Azure as a cloud-based platform for an entire application. In the second, users program on Azure to extend an existing application into the cloud or use Azure as a complement to augment a more traditional-style application.
Let's look at the first case. Assume that a business has heavy but seasonal loads that its developers must account for. With such fluctuating loads, it might not make sense for them to purchase the hardware and software necessary for the peak periods if an option like Azure allows them to pay for only what they need.
Similarly, an Internet-based start-up might not know its infrastructure needs in advance. Underestimating could lead to lost business and a poor first impression for the company's product; overestimating could mean spending too much on infrastructure costs that get underutilized or not used at all.
The latter example might also be a use case for extending an application into the cloud. For example, a spike in business during certain seasons will require some aspects of the infrastructure to scale up and down accordingly. Most of the infrastructure can remain as is, but the parts that are being taxed more heavily can be redesigned to work in the cloud.
Giving Azure a try
The Azure model represents a marked departure from creating traditional desktop- or even Web-based applications. Hosting applications on someone else's platform provides some significant potential benefits, in terms of organizing the infrastructure and scaling the hardware that sits underneath applications.
This is especially true if a business's underlying requirements are highly variable or unknown. It also allows users to pay monthly rent on required resources, rather than invest in all the resources required upfront. This can be especially helpful if it's unclear what resources are needed at the time the service is designed. This model, however, also comes with some significant risks.
First, it can be harder to predict costs. If a business doesn't know how many resources it's going to use, it can be difficult to estimate how much money it will spend. Note that all the major services, including Azure, allow for the purchase of higher amounts of service at a preferred rate if a set amount of resource is guaranteed to be consumed.
Second, applications are only as good as the underlying services provided by the PaaS or IaaS vendor. This caveat has been true since the introduction of Web services, but it is increasingly important as users commit more deeply to cloud-based development. Google's Gmail, for example, has recently suffered outages. Its history of uptime has been good, but it should be assumed that any service will suffer some level of outages. This is where service level agreements (SLAs) come in, which provide specific promises about uptime and other service guarantees. Make sure these are reviewed carefully.
Third, consider the commitment and ability of a given vendor to provide the promised service. The costs of switching between providers is significant; Microsoft, Google, and Amazon do not match up exactly against each other in terms of architecture, and users will have to re-architect any application created for one to run on the other two.
The Azure model remains in its nascent development stages -- keep in mind that it's still in beta. But it is not too soon for users to begin considering how applicable it might be, and the existence of pricing models and an SLA go a long way toward making a reasoned evaluation of the costs and potential benefits. There are several scenarios where an Azure-style application might make sense, but developers should proceed carefully and cautiously. Take a close look at Microsoft's SLA, costs and the services that exist today versus what might be coming in the future. And as a final effort, figure out ahead of time how to back out from a cloud service if it doesn't live up to its end of the bargain.
Microsoft Azure for developers
Part 1: An introduction to developing for Microsoft Azure
Part 2: Azure tools for cloud-based development
Part 3: Comparing Microsoft Azure's pricing policies
Part 4: The risks and rewards behind developing in Azure
ABOUT THE AUTHOR: Patrick Meader has been covering the Windows development as an editor, analyst and author for more than 13 years.
