14 Days Free Technical Video Training from WintellectNOW


The Differences Between Development on Windows Azure and Windows Server

Tags: ASP.NET, Azure, Cloud

This post is part of a series called “Windows Azure for the ASP.NET Developer” written by Rachel Appel (that's me!), Adam Hoffman, and Peter Laudati (they're my awesome coworkers!). You can see the complete list of posts in the series at the US Cloud Connection site.

ASP.NET developers, particularly those writing enterprise applications, have to think carefully about the more than business requirements. The environment, team, tools, deployment, performance, security, and other factors weigh in when it comes to building robust Web applications.  When thinking about using ASP.NET on Azure, you or your team might wonder what challenges an ASP.NET deployment on Azure will entail. Let's take a look at some of the common concerns of ASP.NET developers today and how Azure helps alleviate those concerns, by highlighting a few of the differences between developing on Windows Azure vs. Windows Server.

Azure Architecture and State Management

The big architecture decisions are the first topics of consideration for any type of ASP.NET application, and it is no different in the cloud. Some of those important topics you need to consider are:

  • Overall application architecture, e.g., n-Tier or SOA, and where the code should live and execute.
  • Defining which tiers are services and which tiers are customer facing
  • Where to store primary data, reporting data, or lookup data.
  • State Management & Performance
  • Security

If you're already running ASP.NET on IIS and need to map out architectural concerns of moving to Azure, the Azure Application profile guidance [PDF] details migration concerns for ASP.NET developers.

ASP.NET developers are also used to struggling with (or without, to be precise), state over HTTP. Having to deal with the issue of state vs. statelessness imposes requirements on application design, especially when it comes to performance and scalability. Caching in particular, is important, as it allows you to form a strategy around what data is to be static data, and for how long, and with what parameters. While the overall nature of what type of data should be cached doesn't differ (i.e., data that doesn't change often is the best for caching), there are technical differences between caching on-premise and Azure caching. The output cache provider for windows Azure works well for all your pages that need standard page output caching.

If you're already using ASP.NET features such as session state or the output cache, those providers are available in Windows Azure as well, so there is no need to change your code to make it fit on Windows Azure. The session state provider for Windows Azure is particularly useful. The session state provider adds cache data into its own process on Windows Azure, rather than the usual in-process state management. At first this may seem odd to ASP.NET developers but keep in mind that Windows Azure is a different platform that can scale rapidly to handle the load, and the cross-process expense is more than justified. More details are available in this introduction to Windows Azure Caching Services.

Tool and Project Differences

Fortunately for ASP.NET Web Forms and ASP.NET MVC developers, there are no major tooling or project differences that will catch you off guard when you get started with the Windows Azure tools. You will need the Windows Azure SDK for .NET, which includes the Windows Azure Tools for Visual Studio. The SDK & tools integrate seamlessly as part of Visual Studio.

One small difference in tooling is the use of the Windows Azure developer emulator rather than the built-in Cassini ASP.NET development Web server or IIS Express for local machine testing. While you test your ASP.NET application as you normally would using standard debugging tools, the Windows Azure developer emulator shows what's happening in two console windows inside the emulator windows itself: compute and storage. You can watch basic activity logged as you interact with the application locally.

You can learn more about the tools in the next post in this series.

Greenfield ASP.NET Web applications in Windows Azure tend to fall into two categories, the Web Role and the Worker Role, and Visual Studio contains project types to reflect that. Project types targeting Windows Azure are standard ASP.NET MVC or Web Forms applications that have additional references to Microsoft.Windows Azure and related namespaces as well as .config files containing information for an Windows Azure deployment.

Deployment Differences

The application deployment process is unique to the combined concerns of the application and its environment. In corporate settings you might have mounds of red tape in the deployment process, or can only deploy on the third Thursday of the month because of the systems patch schedule. In some shops, devs deploy to internal server(s), others to a hosted environment, and some are already running the cloud.

If you are dealing with a currently existing ASP.NET application, your initial deployment will be the migration to Azure. When you want to port your existing ASP.NET project over to Windows Azure, all that you need is to add a new Azure Deployment project type to your Visual Studio solution. Azure Deployment projects are simple projects that contain installation and configuration commands in XML.

As an ASP.NET developer, deployment is not just the initial deployment, but incremental deployments (patches), and complete site upgrades, as well. Fortunately, Azure Deployment Tools in Visual Studio make deployment a snap, and the Windows Azure PowerShell Cmdlets help you automate everything you need, and work alongside your IT sysadmin with less friction on all deployment projects.

Running your application in production post deployment means you now have a product to support, and with that comes diagnostics and bug fixes.

Diagnostics and Instrumentation

Of course, once deployed, you need to rely on instrumentation and server diagnostics, customarily the realm of the sysadmin. Fortunately for .NET developers and sysadmins alike, Windows Azure has a full range of diagnostics, instrumentation, and health monitoring of applications. For example, error logging and app auditing are usually the responsibility of the developer, while things like the IIS logs are that of the sysadmin. Azure brings the necessary IT tasks that developers also need to do right into your browser.

Additionally, when developing on Azure, you will enjoy a set of Windows Azure PowerShell Cmdlets, which are tools you can use for automating the configuration and management of Windows Azure services.

Though diagnostics in a cloud environment can be different in technical implementation, the necessary data you need to make correct decisions about the app's health remains the same. In the article, Tips for Migrating Your Applications to the Cloud, the authors detail how to setup, monitor, and manage, diagnostics from Azure in Visual Studio. While the Windows Azure tools for Visual Studio provide you with a full debugging experience on our workstation, instrumentation takes on a greater importance in the cloud because you cannot attach a debugger to a production deployment.

Capacity Monitoring, QOS, and Uptime

Traditionally, teams create applications that run on one or more IIS Web servers, or an internal Web farm, depending on the expected load capacity. If the app and team behind it is large enough, you might be fortunate enough to have a sysadmin that monitors all the key indicators of a crash. Or you might be the one who gets the text message during family dinner hour to fix the app when it breaks, and if you're that person, you probably don't enjoy having to RDP into a server and fish around various tools like the Event Viewer and Perfmon. Azure makes all this unnecessary by providing a set of Web based administrative tools that are easy to use, and a complete set of diagnostic APIs for use in code.

Azure ensures almost infallible uptime, and the Windows Azure Storage blog demonstrates this with lots of great info about highly available storage.


If you're an ASP.NET developer just getting started on the Windows Azure platform, or are in need of information about migrating your existing application to Azure, you'll definitely want to try out the 90 Day Azure Free Trial. You won't be billed a single penny unless you subscribe to full Azure services. Once you have your Azure account and free trial, download the Windows Azure Training Kit (or use it online)

For the rest of the posts in this series, see “Windows Azure for the ASP.NET Developer” on US Cloud Connection.

Are you a startup? Get BizSpark cloud access. Got MSDN? Get up to $3,700 of cloud benefits. Don’t have MSDN? Try the cloud free for 90 days!


Comments have been disabled for this content.