You may be thinking of migrating to Windows Azure to take advantage of the tremendous scalability and on-demand processing power which it offers. That’s great, but you are likely considering this because you have a service that experiences a lot of demand, and serves a lot of bandwidth heavy resources to your users. Enter the Windows Azure Content Delivery Network (CDN), a flexible and convenient way to cache your “heaviest” resources and serve them to customers with increased efficiency and speed.
Heavy resources are typically objects such as images or videos, conventionally referred to as Blobs (Binary Large Objects). When you enable Azure CDN caching, your Blobs will be cached at strategically located points around the globe.
There are currently eighteen global cache nodes, and the network is still expanding. The benefits of caching are realized when users are located far away from the original source of the content. Ask anyone in Perth, Australia how much fun it is downloading a 250 MB file from a server located in Chicago, IL. Now imagine ten thousand Australians requesting the same file within one minute. Now consider that around 80% of a website consists of static files such as CSS, JavaScript, and Images. This situation could engender negative attitudes towards your site. The Azure CDN will allow you to better serve a global clientele.
When you setup the CDN for a storage account, Azure provides you with an alternate domain name of the format http://<guid>.vo.msecnd.net/. This domain will be used to access cached content. As an example, if you have a public container (all cached Blobs must be in containers with public access) called “images” and your GUID is 12345 (however unlikely that is), the Blobs can be access with the URL http://12345.vo.msecnd.net/images/.
The first time a Blob is requested in this manner, the request is redirected to the CDN node closest to the location from which the request originated. Since this is the first request, the Blob will not be found at that node, and will be retrieved from the standard Blob service. It will also then be cached at the CDN node, and given a time-to-live (TTL) setting. This specifies how long the Blob should be cached until it is refreshed by the Blob service. You can pre-specify the TTL length by specifying the HTTP Cache-Control header for your Blobs.
This technique really should only be used to cache content that is as close to static as possible. Caching of dynamic content will affect network performance, which for a cloud environment means a spike in cost.
Using the CDN to cache your static content gives you the power to leverage a global network of delivery mechanisms that is simply unavailable to an organization with an on-premise infrastructure. The Azure CDN gives you all the power without the crippling up-front costs. Being cognizant of high volume Blob requests in your application, and using the CDN to cache those Blobs, will make your site more user friendly to customers from around the world and spare them the personal irritation and loss of productivity that accompanies high latency data transfers.
At Credera, we have experienced an exciting increase in both the breadth and depth of our Windows Azure background as we work with clients to help them leverage this powerful service, as well as increase our own focused R&D efforts. If you think the on-demand flexibility, robust security, and global reach of Windows Azure might serve your business needs, feel free to reach out to us with any questions or concerns.
Contact Us
Ready to achieve your vision? We're here to help.
We'd love to start a conversation. Fill out the form and we'll connect you with the right person.
Searching for a new career?
View job openings
