Azure for New Projects

I have been hearing a lot of comments lately about Microsoft Azure. Some of what I’ve heard has to do with the perceived pain of migrating existing ASP.NET applications. I know Microsoft says it is supposed to be easy but the fact is that there are some new skills required. Most likely there will be some code changes, even if they are minimal. Additionally there are questions as to the cost effectiveness of using Azure to host a single website for a small to medium business. Whether or not migration of an existing application to Azure is appropriate (both from a business/economic and a technical perspective) will likely remain a subject of discussion for some time.

For this article, though, let’s just consider the other class of applications – new applications – that could be developed for Azure. Certainly there will be new applications developed going forward. Besides the usual differences between PaaS and IaaS, what does Azure give us that an ASP.NET solution deployed to an Amazon EC2 instance, for example, might not?

Most new applications begin with a consideration of architecture. There should be a clear separation between well-defined logical layers. When developing a new application we should almost always be thinking in these terms. Does Azure offer any benefits or options over a traditional solution stack based on .NET, IIS, SQL Server and Windows?

Let’s consider three possible layers in an n-tier model:

  1. The Presentation Tier:
    Well, not really. You will still have to implement this yourself according to the best practices of the particular framework you are going to target. An Azure Web Role will still have basically the same presentation semantics as a traditional .NET Web Forms or MVC application.  
  2. The Business Tier:
    With web and worker roles Azure actually does provide us with a pretty nice abstraction that can help us make a clean separation between presentation and business tiers. Putting the business logic into worker roles, for example, may make sense from both an architectural and a performance perspective.
  3. The Data Tier:
    With Azure we have options on how we could store our data. Do we need the acid properties of a relational database or would an eventually consistent representation of the data be okay for our application? Note that the choice here is directly tied to cost: if we need a relational database in an Azure solution we have to pay extra for it.

We must also consider scalability right from the outset. What is the probability that our application may have to grow to “Internet Scale”? Are we likely to become the next Facebook? What is the downside if we need to scale quickly and cannot? Scale is much more achievable if it is considered as part of the original design.

Azure does offer some attractive alternatives for new application development. If nothing else it should give the system architect an opportunity to think “outside the box”. Azure is a little different than traditional ASP.NET and there is a bit of a learning curve to climb. Consider attending Learning Tree’s Azure programming course to speed your ascent!


Type to search

Do you mean "" ?

Sorry, no results were found for your query.

Please check your spelling and try your search again.