Partager via

Introduction to Windows Azure AppFabric Caching CTP

  • Article

This blog post provides a quick introduction to Windows Azure AppFabric Caching.  You might also want to watch this short video introduction.

As mentioned in the previous post announcing the Windows Azure AppFabric CTP October Release, we've just introduced Windows Azure AppFabric Caching, which provides a distributed, in-memory cache, implemented as a cloud service. 

Earlier this year we delivered Windows Server AppFabric Caching, which is our distributed caching solution for on-premises applications.  But what do you do if you want this capability in your cloud applications?  You could set up a caching technology on instances in the cloud, but you would end up installing, configuring, and managing your cache server instances yourself.  That really defeats one of the main goals of the cloud - to get away from managing all those details.

So as we looked for a caching solution in Windows Azure AppFabric, we wanted to deliver the same capabilities available in Windows Server AppFabric Caching, and in fact the same developer experience and APIs for Windows Azure applications, but in a way that provides the full benefit of cloud computing.  The obvious solution was to deliver Caching as a service. 

To start off, let's look at how you set up a cache. First you'll need to go to the Windows Azure AppFabric LABS environment developer portal (https://portal.appfabriclabs.com/ ) to set up a Project, and under that a Service Namespace. Then you simply click the "Cache" link to configure a cache for this namespace.

With no sweat on your part you now have a distributed cache set up for your application.  We take care of all the work of configuring, deploying, and maintaining the instances. 

The next screen gives you the Service URL for your cache and an Authentication token you can copy and paste into your application to grant it access to the cache. 

 

So how do you use Caching in your application?

First, the caching service comes with out-of-the-box ASP.NET providers for both session state and page output caching.  This makes it extremely easy to leverage these providers to quickly speed up your existing ASP.NET applications by simply updating your web.config files.  We even give you the configuration elements in the developer portal (see above) that you can cut and paste into your web.config files. 

You can also programmatically interact with the cache to store and retrieve data, using the same familiar API used in Windows Server AppFabric Caching.  The typical pattern used is called cache-aside, which simply means you check first if the data you need is in the cache before going to the database.  If it's in the cache, you use it, speeding up your application and alleviating load on the database.  If the data is not in the cache, you retrieve it from the database and store it in the cache so its available next the application needs it.

The delivery of Caching as a service can be seen as our first installment on the promise of AppFabric - to provide a consistent infrastructure for building and running applications whether they are running on-premises or in the cloud. You can expect more cross-pollination between Windows Server AppFabric and Windows Azure AppFabric in the future.

We invite you to play with the Caching CTP and give us feedback on how it works for you and what features you would like to see added.  One great way to give feedback is to fill out this survey on your distributed caching usage and needs.

As we move towards commercial launch, we'll look to add many of the features that make Windows Server AppFabric Caching extremely popular, such as High Availability, the ability to emit notifications to clients when they need to refresh their local cache, and more.

Comments

  • Anonymous
    October 31, 2010
    Well, great work, We my need benchmark data for distributed enterprise applications to decide on its advantage

  • Anonymous
    October 31, 2010
    Great. Many Azure users have been waiting for this feature! A few questions:

  • Will this CTP become available for more data center locations?
  • Can you give a bit more insight on the pricing model you're currently thinking of? A price per transaction or a 'all inclusive price' for the used MB in cache?
  • If the pricing is per transaction: will you allow hosting the cache in a private worker role to avoid the price per transaction? Thanks