The Which, the When, and the How of Windows Azure Services: Websites

Windows Azure is a platform with many different services that you, the developer can piece together to create your solutions. But when do you use which service and how? In this blog series, you’ll discover the answer to that by using different scenarios used by developers working with Windows Azure today.

I’ll never forget this one time (at band camp? LOL) I was doing a presentation and after a full 2 hours of going through the Windows Azure platform, a developer at the back of the room stood up and said to me “Jonathan, now that I understand what Windows Azure is, what do I use when?” I took a minute to reflect on the question – to understand exactly what he was asking me. I thought he was joking at first, but after thinking about it for a bit, the question made sense. It’s very easy to understand what each individual service does, but it is a bit harder to piece together how all the different services work together.

In the next few posts, I’ll go through some scenarios that I see often being used today and will endeavour to highlight how different services can be used to meet certain requirements.

If you need a crash course or a refresher on the Windows Azure platform, check out my Azure Camp Online series or visit an Azure Camp in a city near you. 
 

Attributes of a Website

Before going to into the which, the when, and the how of Windows Azure services for websites, let’s take a moment to understand some of the key attributes of a website:

• Need to be responsive
  With Internet speeds and capabilities as they are today, there is a level of user expectation that the website be responsive. In other words, when you access the site, you expect it to come up instantaneously. When you click on links, you expect them to react instantaneously. When you tell the site to perform an action, like logging in, you expect that all of the backend data access, logic, page rendering, etc. be executed in under a second.
• Have varying demand needs
  Your website may just be starting and so you only have a few hundred users right now, but tomorrow that might be different. If you have an existing website, perhaps you go through seasons where there’s more demand than others (e.g. holiday shopping season), or perhaps someone shared your website’s link on a social network and it went viral. Your website will have varying demand needs throughout its lifecycle.
• Potentially store massive amounts of data
  Simpler websites may only store images, stylesheets, a few documents, and lots of text. More complex sites may store massive amounts of images, videos, documents, data, etc. The more complex the site is, the more data it will store. Similarly, the longer a site is up, the more data it will accumulate over time.
• Available to everyone
  You would think that this one is obvious – putting your site on the Internet, which is public, makes it available to everyone. While this is true, depending on the nature of your site, the notion of “everyone” may actually just mean your neighbourhood, your province, or the country. However, with all of the technological capabilities that exist worldwide, your online presence is truly a global presence, reaching many more people than ever before.

There are definitely more, but these are the ones that relate to this discussion.

Mapping Attributes to Services

Now that we know the above, we can map these attributes to Windows Azure services:

• Need to be responsive and have varying demand needs both relate to scale. Scale is achieved by using one or more Windows Azure Compute instances. The more compute instances you add, the more “horse power” your site will have and therefore the more it will be able to take on. This will increase the speed at which the site responds to request, and more importantly, be able to handle the traffic that comes to it by sharing the work across the multiple instances.
• Potentially store massive amounts of data maps onto either Windows Azure Storage and/or SQL Azure, both of which give you the ability to store massive amounts of data depending on the type of the data. If you need to store images, videos, documents, or other large binary type data, Storage is the way to go. Since it is delivered as a service to you, you won’t find yourself worrying about its scalability, availability, or most importantly, its capacity. Use as you need and pay for only what you use. Storage also has services for non-relational data – Table Storage. You’ll want to use table storage for flat (non-relational) data. For more complicated data, or relational data, you’ll want to use SQL Azure, which will allow you to work with data in much the same way that you do with SQL Server today, just without the headache of managing a SQL server.

When looking at storage options there’s a lot to consider, so you’ll need to dig deeper into this one before making a decision. I have some excellent resources I’ll highlight in a few posts that will help you with this. 

• Available to everyone maps onto two different services that take care of two different aspects of your ability to reach everyone. The one thing that is common between both, however, is that the emphasis is put on not just being “available”, but more importantly, available, responsive, and providing the best experience depending on where you’re located in the world. The two services that map to this requirement are Content Delivery Network and Traffic Manager. You’ll want to use the Content Delivery Network (CDN) to be able to geographically distribute your storage objects (images, videos, documents, etc), placing copies of the data in “edge nodes”, or cache nodes around the world, making the data physically closer to users requesting it. This reduces the distance the user’s request has to travel and therefore increases the responsiveness of your site (i.e. the ability for your site to return the data to the user). Traffic Manager takes care of intelligently sending users trying to access your site to a data center that is closest to them based on rules that you can define. For example, if you have your site deployed to one of the Windows Azure North American data centers and to one of the European data centers and a user is trying to access your site from Asia, Traffic Manager can route the user to the European data center. The European data center is physically closer, thereby reducing the length of the trip, and getting the site and data back to the user as fast as possible.

Using the attributes of a website as a guide, we’ve now been able to map Windows Azure services to meet the requirements of each.

Next Steps

As with everything in technology, there is always more than one way of achieving the same result, but one way will work better than another for the requirements of your particular solution. The best way to figure out which one is best, is to try it out yourself.

• If you’re working on a brand new site, create a proof-of-concept site that will simulate some of the key areas of your site that you foresee will require special attention. Those include high volume areas where you’d want to test the load and geographic distribution, areas that give access to or write to storage, data access, authentication and authorization mechanisms, and others. Test each area of your proof-of-concept against your functional and non-functional requirements and see the impact (positive or negative) on the application. Adjust as necessary to reach your desired results.
• If you’re working on a existing site, in some cases, that makes this process easier. Take your site and deploy it to Windows Azure. Start adding on the Windows Azure services discussed above, one by one, and test each time to see the impact (positive or negative) on the application. Adjust as necessary to reach your desired results.

Keep In Mind

Testing with the emulators that are included with the Windows Azure SDK (while it is definitely something you should do before deploying)will not give you as accurate of an idea as testing with the live production environment. In order to truly determine what will work best, you’ll definitely want to deploy to Windows Azure itself.

If you’re an MSDN, MPN, or BizSpark member, you have Windows Azure benefits included with your subscription that give you ample resources with which to test Windows Azure. If you’re not a member, you can use the 90 day free trial which also gives you ample resources with which to test. The only difference is that you’ll have 90 days to do it in. For most scenarios, 90 days is sufficient to do the necessary testing.

TIP: You can now set usage limits on your Windows Azure deployments. This will help you ensure that you don’t go over the resources that are included with the trial or MSDN, MPN, and BizSpark memberships. This will then prevent any unwanted charges going on your credit card.

Get a Conversation Going

Do you have any questions about Windows Azure as it relates to websites? Have you already tried different services and architectures for your solution and learned a few things along the way? Start a conversation on LinkedIn and ask or share with others.

Disclosure

As I mentioned above, there is more than one way to do anything mentioned above and different scenarios will call for different architectures. What’s mentioned in this post is just A way of architecting the solution. Don’t take this post to mean that it is the only way or the best way.