By Jim White (Director of Training and Instructor)

This is the second of a two part blog post on considering Windows Azure for your applications.  See the 1st post here.

Cloud computing, and in particular Microsoft Windows Azure are hot topics in IT circles today.  A report on CNN has even suggested that Internet users will live in the cloud by 2020 (see the report here).  While you and your organization is probably investigating Azure and other cloud computing technologies, here are a few things you should know before you jump into running your applications and data in Azure.

1. Migration is not free.

Azure is a different environment. Despite what some in the industry might lead you to believe, your existing .NET applications are going to need work before they can run in the Azure cloud. You can?t just flop an existing ASP.NET application on to the cloud without some thought. Architecture and design are still important steps on the way to cloud migration. Sriram Krishnam, a member of the Windows Azure program management team and author of Programming Windows Azure (O?Reilly) said it best in this passage from his book.

?you?ll often find yourself needing to rewrite/modify parts of your application. Though platforms such as Windows Azure try to make it as seamless as possible to port applications, there are some inherent differences, and you?ll need to make at least some small changes.?

Yes, you can leverage existing .NET knowledge and code, but you still have many things that operate a bit differently in the Azure environment. File storage/access, logging, diagnostics, security, and data storage/access are just a few aspects of your application that you?ll want to look at in migrating to the cloud.

2. Scaling is not automatic

One of the key selling points of Azure, and cloud computing in general, is that it allows organizations to scale their applications and data storage on demand without provisioning new hardware, bandwidth, software, etc. Azure does provide as near-to-infinite set of resources to host your applications and data as can be thought of in the real world. Moreover, these resources can be requisitioned within minutes or hours, versus days or months in normal provisioning cycles. However, the IT community often misunderstands that the scaling in Azure does not happen automatically. That is, if your application suddenly starts to see a huge spike in requests, Azure does not detect that and automatically requisition more hardware and virtual environments for application to run in to meet the onslaught of demand. You must either manually, or through code your write or purchase, detect the need to scale and then provision Azure resources (and deploy your apps/data) to answer the blitz of new requests.

If this doesn?t sound easy, you are right. In fact, one of the reasons that Microsoft does not yet provide automatic scaling and provisioning in Azure is that even they are not yet sure how to determine a scaling need. What does ?busy? or ?stressed? mean? Without a way to effectively measure and configure a response to measures, it is difficult to scale automatically.

3. Backups aren?t there.

Just one incident of not backing up your hard drive and losing sensitive data is usually enough to teach most computing resource users to backup early and often. We in the industry go to great lengths to backup crucial data; often contemplating and dealing with the unthinkable just to ensure the survival of our organization?s data. Many that explore Azure are glad to hear that all data stored in Azure, no matter what the form (Azure Storage or SQL Azure) is replicated three times (on three different physical servers). A common misconception is that this should suffice for ?backups.? The triplicate replicas of data stored in Azure is really meant for high availability of the data. It is not for backups! Backups are still your responsibility. When something happens to one of the three replicas, the other two take over while Azure rebuilds the third data replicate. Therefore, your applications and customers that use the data are never worse for wear. However, if your application (or a malicious user) creates bad data, or if the whole data center goes up in smoke (unthinkable ? maybe ? but remember backup is about contemplating the unthinkable), your data is gone, corrupt, unusable, etc? Backups in the cloud are not any picnic either. You do not have access to the servers that host your data and today there are no Azure tools that provide backup management activity. You must either write or buy code and tools to backup your data out of the cloud and put it somewhere it is safe.

4. Logging/Diagnostics require some thinking.

As developers, you cannot debug applications in the cloud. You debug your applications in a development environment and then deploy them to the cloud where you do not have very good vision of what is happening. Azure provides the means to capture all the standard log and diagnostic data you want. However, you must code and configure your applications to request and capture this data. You must also code or buy a solution for extracting this data to an environment near you where you can make sense of the information. In the case of some problematic event, you want to make sure your Azure logging/diagnostic solution can report back to you in a timely manner with enough data that you can react to the current situation. If this sounds like you have to put some planning and design into bug and downtime events (and the handling of those) you are correct again!

5. Savings are negated by poor architecture.

Azure and other cloud platforms are about saving money. Instead of buying and operating a whole data center yourself, you purchase a slice of a data center and share in the cost of its operation. Further, you ?pay for play.? That is, you provision the computing resources you need as/when you need them and you pay for exactly what you use ? nothing more and nothing less. All true, but because you are now charged for each computing hour, each transaction, GB of data stored, and GB of data bandwidth, you can write applications that exceed traditional data centers. Software engineers, as Azure engineers, need to think like an MBA graduate as much as they think like a CS major. Writing applications that are extremely (and often needlessly) chatty increase costs. Data stored too long or in the wrong place can inflate costs. Azure offers multiple data storage options for a reason. Some are cheaper and more scalable in certain situations. As you are charged for every hour of computing time, underutilized application instances meant to handle the occasional spikes in demand cost you money in Azure. Design and architect your applications and data storage to leverage the pay-as-you-go model without evaporating your savings on the data center.

If you would like to learn more about Windows Azure, check out our training course here. If your consultants can help you ?navigate in the clouds?, please contact Ryan McCabe for assistance. Also, I invite you to join the Windows Azure User Group ? it?s a virtual users group ? where you?ll find some great educational material and virtually meet people discussing Azure.