Just the other day the Microsoft Azure team shifted the CDN functionality into release mode and offered up a pricing model. I reflected on the release in my post ‘Azure CDN Pricing’ however some of the information I provided was in fact incorrect.
This article is to correct some of those mistakes, and also offer a few more insights into the Microsoft CDN. I spoke with Jason Sherron from the Azure CDN team this morning and clarified a number of points and learnt more about Microsoft’s CDN offering.
Some years ago it was true that Microsoft used partner networks like Akamai and Limelight for content delivery. The team responsible for managing the global CDN was the “Edge Computing Network” (ECN) team.
Microsoft also had/has extensive co-location spaces; racks of servers sitting in a 3rd party data centre. Usually these have dedicated backbones and fibre. This localised service has extended over the years to include Microsoft.com, MSN.com, Bing Maps, etc.
Slowly Microsoft has started removing dependencies on 3rd party providers and moving on to their own infrastructure. This article gives some indication of where Microsoft are going with their services. Jason indicated to me that today, Microsoft serves 60% of edge content themselves.
Jason went on further to explain that as of this launch of the Azure CDN, Microsoft are now hosting 100% of your blob storage at those edges around the world. Your data does not sit with Akamai or Limelight, as I previously indicated.
Currently Microsoft has a single point of presence in Australia. The goal of any edge is to be located close to key egress and ingress points in the local area of internet exchange. For us, this is in Sydney, and while Microsoft doesn’t have an entire data centre here, they partner with someone who does, yet the racks are all Microsoft servers. Hopefully we’ll see more presence in the future in other capital cities.
We discussed briefly “what next” with the CDN. While nothing is bedded down completely, the team is investigating the possibility of Silverlight smooth streaming (apparently one of the most requested features) and also the potential of ‘compute at the edge’. How this latter service would differ from an implementation of the Azure Fabric is beyond me at this stage, and Jason was not at liberty to provide further information. I’m certainly very interested to see what this is about though.
In yesterday’s article I indicated you pay twice for CDN retrievals. This is partially true but really should be clarified.
The first time your data gets requested at the edge, the node has to retrieve the blob from Azure storage. You pay at the Azure storage data centre (normal Azure bandwidth charges) and then you pay again when it is delivered from the edge to the user (CDN charges). The content is of course cached at that point. Subsequent requests will hit the cache, which means only one charge.
Essentially if your data is “hot” then you only pay once. If you are constantly finding that your data is “cold” then perhaps CDN isn’t for you.
You have the option of either specifying the time-to-live for your blob object or you can rely on the heuristics of the cache network to determine the best time-to-live. More information can be found in this article: Delivering High-Bandwidth Content with the Windows Azure CDN.
Thanks to Jason for giving up some time to chat with me today, and put up with my follow up emails. Its important to remember that the authoritive source of your content is still your blob storage account, and the CDN cache is just a copy. The cache expiry will also affect the ‘freshness’ of your content so keep this in mind if you have content that changes frequently.
* Update: Please note this article is now redundant. Please defer instead to this clarification: Azure CDN Updated
The pricing structure for the CDN aspect of Windows Azure has just been announced. You may remember that I previously wrote about Global Foundation Services and the mechanism that Microsoft uses to globally distribute its own content. Since CDN might become more interesting to you now that it is officially released, I thought I’d summarise two important points.
I did cover this in greater detail in the previous post about GFS mentioned above; Microsoft does not have a CDN of their own and 3rd party services are utilised to achieve this. While I don’t see it generally being a problem, this might bother some people, mostly the fact that they can’t be sure where their data is actually sitting when it is cached in a CDN node.
CDN nodes are not part of the Microsoft network, therefore you will pay for output data transaction and bandwidth from the Azure Storage service, as well as for connections to CDN node. This means you are really paying a premium for this service. To quote the original release:
Any data transfers and storage transactions incurred to get data from Windows Azure Storage to the CDN will be charged separately at our normal Windows Azure Storage rates.
You have been warned!
I was just putting together a doc for some Azure quick links that will be content handed out to delegates at the upcoming Australian Remix conference. I figured I would also post the list here. If you’re into Azure, you should know about all these destination addresses.
Windows Azure Platform – Home
http://www.microsoft.com/windowsazure/
Windows Azure Platform – Developer Centre
http://msdn.microsoft.com/en-au/azure/default.aspx
PDC Videos 08/09
http://channel9.msdn.com/posts/pdc2008/tags/Azure/
http://microsoftpdc.com/Sessions#/tags/WindowsAzurePlatform
Windows Azure Platform Training Kit
http://www.microsoft.com/downloads/details.aspx?FamilyID=413e88f8-5966-4a83-b309-53b7b77edf78&displaylang=en
Blogs
http://blogs.msdn.com/b/windowsazure/
http://blogs.msdn.com/b/windowsazurestorage/
http://blogs.msdn.com/b/sqlazure/
http://blogs.msdn.com/b/netservices/
http://blog.smarx.com/
http://blogs.msdn.com/b/jnak/
http://www.davidaiken.com/
http://azure.snagy.name/blog
Other
http://www.cerebrata.com/products/cloudstoragestudio/
http://lokadcloud.codeplex.com/
http://azuresecurity.codeplex.com/
http://wag.codeplex.com/
Community Support:
http://www.codify.com/lists/ozazure
http://social.msdn.microsoft.com/forums/en-US/windowsazure/threads/
You may not have heard this name before. In fact, I Googled it and got 0 responses. However the pattern is very important and is very well publicised in Azure circles. Since there seems to be no actual name for this pattern, I’m seeking to give it a name, so that we can all speak a common language. First I’ll explain the pattern in concept, then I’ll explain it in the context of Azure.
The Asynchronous Work Queue Pattern allows workers to pull work items that are guaranteed to be unique from a robust, redundant queuing mechanism, in a fashion that is ignorant to leasing and locking of the work items provided. In other words, the leasing and locking functionality is removed from the worker which can concentrate on the work to be done, and the queue guarantees that no work item enqueued will ever be dequeued more than once.
As a developer I’ve worked on a lot of large systems and have often found myself dealing with the problem of resource contention. Whether multiple threads are trying to access a resource for the same reason, or perhaps two different tiers want the same piece of information for two different reasons, sharing resources can be hard.
Imagine an event that occurs as the result of some interaction with a website. That event might require some data to be saved, an email to be sent, a log service to be called, and a bunch of other things. We never want this to happen all in the original request; we like our UI to be responsive, otherwise the user is just going to press the submit button again right?
To get around this problem we create a WorkItem class and our UI thread now saves a work item. Running on a Windows Service in the background (probably on another server) we have a work processor whose job it is to check the work item table every 15 minutes and pickup any work items that need doing and process them. We sit back and put up our feet, comfortable that our separation of work items from the UI has made our application extremely responsive, and added some robustness to boot.
A month goes by and all of a sudden the sales team lands three massive clients and our site traffic has increased ten fold! Our web front end is doing great though, especially since it can just hand off work items and return control to the user very quickly. However the backend Windows Service is choking under the pressure and work items are coming in faster than it can process them.
No problem, we decide to add a second server and install the Windows Service there as well. But wait; this won’t work will it? Both services hit the database and get the next work item; they get the SAME work item! So now we need to consider taking a lease over a certain number of work items to indicate that they are being processed. We pick an arbitrary number; each service will pick off ten work items and put a flag next to them saying they are being processed. In doing so we realise we are polluting our data schema with information about how the data is being used, but we really have no other choice.
Of course we then ponder; what happens if they both query and get work items at the same time? They might not have the flag and could therefore still process the same records. So now we need a double verification. The complexity grows.
By providing a queue implementation that ensures that the ‘next’ work item cannot be dequeued by more than one requester, the workers can focus on the work that needs to be done and can remove complex code pollution required when worrying about leases.
The primary advantage of this approach is that it scales extremely well. In the problem scenario depicted above, adding another 20 windows services will result in each other service slowing down because more lease checking occurs when looking for free work items to process, and as a result less work gets done. But in the queue scenario, 20 times more services will mean 20 times more productivity.
In Azure the equivalent scenario would be worker roles with multiple instances. Windows Azure Storage provides a highly scalable Queue that is accessible via REST. In essence, the Windows Azure Storage Queue service was designed specifically for asynchronous work distribution/consumption. Each retrieval of a work item from the queue is guaranteed to be unique, except where the worker fails to notify the queue of successful processing, in which case the work item is automatically re-enqueued after a certain amount of time. This ensures the work item is not lost due to a worker failure. Also, Azure Queues are at least three times redundant, ensuring no work item is ever lost.
In some example code I’ve posted from previous presentations, there is an application that searches for images based on their colour content. The Asynchronous Work Queue Pattern is applied in this example application; a search is made against the Flickr API for a specific keyword and a bunch of results are returned. Each result is placed into a queue, and multiple workers listen at the other end, waiting to pick up an image that they will chop up and analyse for colour content.
To be honest I don’t care what its called; its just important that you are aware of the pattern and know why to use it.
It was just pointed out to me by Paul Stovell that this fits very closely with the Message Dispatcher pattern as identified in the book Enterprise Integration Patterns. The key difference is that the dispatcher pushes work to the consumers whereas workers will pull the work load from the queue instead. The message dispatcher pattern makes the assumption that the message channel is in fact dumb, whereas Windows Azure Storage Queues are smart and can ensure no message duplication, as well as reliable messaging, even in the event of consumer failure. Currently I believe these are still separate patterns however am happy to have the discussion over a beer or two.
Remix10 in Australia will be on June 1st and 2nd in Melbourne. This “love fest”, as it is being advertised, will see the best of the web and of course that means Azure will play a prominent part.
The sessions have been announced and yours truly will be presenting in the first session of the conference on: Architecting For The Cloud. Here’s the outline:
All you hear nowadays is ‘cloud this’, ‘cloud that’. But what does it really take to write applications for the cloud? Are all applications even suited for the cloud? How are applications best architected for the cloud?
In this session we’ll explore these concepts as we take a scenario based focus on architectures that need to be scalable and durable, focusing on real world examples of companies already using Azure.
There will also be introductory Azure labs over both days; at this stage 4 sessions in total, so get in quick before all the seats dry up! To signup for a lab, email Kyle Price your name, job title, company, and contact phone number. Kyle’s email is: 
Hope to see you there!
Not a very interesting post in itself, this quick reference is a guide to explain some of the Azure terminology I use when writing posts. I thought it would be better to have this as a stand alone post that could be referenced from multiple articles as necessary.
This is the collective name for all the products in the Azure space. This includes Windows Azure Compute, Storage, Sql Azure, AppFabric Service Bus, Access Control Services, Azure Market Place, and Dallas.
This is the formal name for the collection of compute and storage services available in a scalable, distributed fashion. Often confused with the Windows Azure Platform and certainly makes life difficult in conversations. Runs on the Azure Fabric and includes management components such as the Fabric Controller.
High level container that represents a cloud project. A cloud project might contain multiple storage and compute services.
A project can contain any number of services however there may be some restrictions to this based on your project (ie as a CTP user I have a limited number of services I can add and cannot add any additional projects to my account unless I pay).
A service is either a compute or storage aspect of a project. A compute service can contain any number of roles (web or worker) while a storage service will contain all three storage types as endpoints (queue, blob, table) even if they aren’t all used.
Applications that you write will run on Windows Azure Compute. Web and worker roles that you write will be hosted on the platform and distributed throughout the data centre based on information you provide in your Service Configuration.
Primarily blobs, queues, and tables, all at least three times redundant, and able to be located near your Windows Azure Compute services. All available via REST API calls.
A special kind of storage blob that can be mounted as an NTFS drive.
Multitenant relational databases in the cloud. Essentially MS Sql Server with some restrictions including a throttle to prevent resource hungry queries.
The name given to a collection of services that can enhance your cloud application or help support hybrid scenarios. Currently includes the Service Bus and Access Control Services.
Formerly the .Net Service Bus, this is an internet service bus that can broker communication, provide stable end points, and various routing/broadcasting services.
A secure token service – designed to allow the separation of your authorization layer from your applications by trusting claims submitted from users that were encrypted by the ACS. Can federate with your Active Directory via ADFS version 2. Other providers will be supported in future such as Live ID, Open ID, etc.
Not directly related to Azure; contains services that can assist your applications hosted on-premise. Contains aspects of project code name Oslo and the distributed cache Velocity.
A place where you can list your application so that it can be found by consumers.
A public store of external sources of data, some free and some at a premium cost, available for consumption and visualisation via Pinpoint.
Sometimes I like to look at the types of traffic coming to my site. Somehow I managed to create a blog that gets some high rankings in various Azure searches, and as such a lot of people come to my site looking for answers. The title of this post is one such question that came in quite recently, and I thought it was a great question that deserved an answer (if only I had a way to go back in time to insert this post so that I could answer this person’s question!).
Before we continue, I’ll defer you to one of my earlier posts about what exactly a web role is:
The Web Role is similar to a ‘Web Application’ – it has aspx pages and code behinds, but can also server anything that uses the http protocol, such as a WCF service using basicHttpBinding. The Web Role is driven by UI – the user interacts with a web page or service and this causes some processing to happen.
Web roles can be scaled out by instance count. What this means is that when you create a web role you can have one, two, or thousands of that same web site running at a time. Think of this as having multiple web-heads running the same application.
In a non-Azure world, your Visual Studio solution might look like the left option below, and the equivalent Azure version would look like the option on the right:
A single solution with a single MVC web application serves the products for us to the masses. Of course a real solution would probably have some shared logic in class libraries and probably a unit test project as well, but lets forget about those for now. The Azure version is similar, having the main cloud project, and then a web role for the products website. One instance of our web role will cost us N cents per hour (N is the cost for your country).
Let’s say we also want to provide some B2B integration and create a set of WCF services for our partners to consume. You might add a new project for the WCF end points:
Once again we’ll ignore the other abstractions and unit test projects. We have a services project that hosts a WCF service over http on the left, while on the right we have another web role. Since we need both web roles hosted in Azure, it will cost us 2 times N cents per hour, even if both roles are under utilised.
Do you see the problem here? Traditional layout of our Visual Studio solution will actually cost us more money in Azure! The problem is easily fixed though; minimise your projects (where you can). In our example, this means putting all end points (whether WCF or MVC) into one project, then moving the other related code out into separate ‘code behind’ projects:
In this new design, we only have 1 web role with all the client facing information for the MVC pages (content contains CSS, scripts contains JavaScript and views contains the ASPX pages) and the WCF service (just the SVC file), while the web.config contains information for both components.
The rest of the content such as the controllers and models, as well as the service contract and implementation are hosted in class library projects.
This ensures only 1 web role which means only a base cost per hour. Then if there is heavy load in either the services or the web role, then adding a new instance covers you for both areas.
In this sense, there is no reason to have more than 1 web role in a project.
We’ll think about one more example. Service Oriented Architecture usually lends itself to a solution with multiple projects, where each project is a discrete, autonomous set of services. You might have one project for product information, another for authentication, a third for activity tracking, and another for managing shopping baskets. Each project may have one or more end points, and all the related code and data contracts would be stored in that single project.
In Azure, this would result in four web roles and immediately means a minimum cost of 4 times N per hour, even if those roles are all sitting at less than 10% CPU utilisation. Instead we should move all the service endpoints into a single web role, and then keep the implementation logic separate in discrete class library projects.
So generally, one web role is all you need/want. However there are always going to be situations where it is unavoidable. For example, you might have two web applications with very different forms of authentication.
But for green field projects, please keep the Azure pricing model in mind and try to minimise the number of roles you need, and scale out instances instead when more load needs to be handled.
CodeCampOz is a once-a-year event over the course of a weekend where code freaks gather from all around Australia descend on the small town of Wagga Wagga in central NSW.
The next one will be held on November 20th and 21st, according to this announcement. The call for speakers has also gone out. I’ve submitted five presentations, I’m hoping at least one will get accepted. I thought I would just quickly post the five submissions here for your review:
Title: Windows Azure Compute For Developers
Level: 300
Outline:
The barrier to entry of a new technology can often seem daunting at first. However the Microsoft hype is true: .Net developers ARE cloud developers! This session will demonstrate how cloud apps are just like apps you’ve already been writing. We’ll also go through some of the API functionality that you can use if you like to add more ‘cloudness’ to your applications and we’ll focus on some key abstractions to help make your applications hot-swappable between on-premise and Azure servers.
Title: Architecting For Azure
Level: 300
Outline:
Organisations are looking to Azure for two primary reasons: cost-reduction and elasticity. While it is easy to port your applications to Azure, it does not mean you will automatically reap the benefits of ‘running in the cloud’. This session will take a look at some key philosophies to keep in mind when architecting your applications to run on Azure.(this session is a rework of my Azure launch Philippines presentation and my upcoming Remix10 presentation)
Title: Hybrid Azure
Level: 300
Outline:
Don’t want to store your data in the cloud? Still looking to leverage from elasticity? Azure isn’t just about moving your whole world into a Microsoft data centre. There are many scenarios in which you will want to utilise specific features of the Azure platform without swallowing the whole pill, and this session will explore just a few.
Title: Building the Windows Azure Platform
Level: 200
Outline:
Windows Azure provides millions of compute and storage instances across multiple data centres around the world and manages all the applications that run on top if them, configuring load balances, VLans and DNS entries dynamically to meet the scalable needs of millions. And it does all this automatically! In this high level discussion we will peel back the layers of abstraction to reveal how Windows Azure really works under the hood to automatically provision virtual machines and applications in a highly fault tolerant manner.
Title: Azure By Example
Level: 400
Outline:
This no-slides presentation will walk through a sample application with high scalability and redundancy needs that utilises all the parts of the Windows Azure platform. Focusing on reusability and key points of abstraction, we’ll demonstrate how Windows Azure Compute, Storage, Sql Azure, Service Bus and Access Control Services all come together to form the architecture of a highly scalable application.
If you think of anything else you’d like to see around Azure at CodeCampOz, let me know and I’ll make another submission.
More Options ...
Categories
Tag Cloud
Blog RSS
Comments RSS
Void 
Life 
Earth 
Wind « Default
Water 
Fire Light Bad Behavior has blocked 260 access attempts in the last 7 days.
Last 50 Posts 
Back