Microsoft Introduces Project "Velocity", Distributed Caching for .NET

This morning at Tech-Ed, Microsoft unveiled a new product. Traditionally Tech-Ed hasn't been where Microsoft has unveiled new CTPs and betas, they typically reserve that for PDC while Tech-Ed focuses on training Microsoft developers on how to use the existing, current-version stuff. This kind of balance is required because developers need to know whether they're going to Tech-Ed or whether they're going to the PDC when they're both happening in the same year.

Before I continue with Velocity, I should re-iterate here that networking and back-end stuff like distributed caches isn't just up my alley, that's what my alley is made out of. So when I see stuff like this, it's difficult not to get giddy.

Anyway, on to Velocity. This is a distributed cache system that Microsoft has unveiled. It comes with a Windows Service that you start up on each of your DC servers. This windows service has a configurable amount of memory that it can consume and you can do some other things like configure the TCP ports (yes, it's using TCP not UDP/P2P) and set the cluster name. There are some fairly complicated details about how the cluster works, but to keep it simple here are the cliffnotes: You can blindly store objects in the cluster or you can give them a region. By giving them a region, items with the same region will be homed on the same physical cluster server to allow for more rapid access of related items. This shouldn't be new to that many people - it's basic distributed caching technology.

So what does Velocity actually do? In short it gives you Add, Put, and Get (with obvious extensions and overrides) methods on a distributed cache. You can fetch and retrieve any serializable CLR object. This should sound pretty familiar to those of you who have used the out-of-process state servers for ASP.NET like the SQL session state or the ASP.NET Session State Service. The main difference is those out-of-state servers are not distributed, they're just singleton services.

Tags

Tags are cool. I really like the notion that in addition to a simple dictionary key, you can supply an arbitrary list of tags that belong to a given item. Using those tags, you can retrive arrays of objects (also cool) from the distributed cache by providing intersection, union, or difference of tag lists. In other words, you should be able to retrieve all items from a distributed cache that have both the tag customer and the tag ohio (completely fabricated example, I don't vouch for the practicality of such a scheme).

I realize that this thing is just a CTP, but already I can see a huge, gaping hole in the implementation that I think Microsoft needs to fix if they hope to have real adoption of this thing. Right now, if you read the blog post from the Velocity team, they are very much marketing this thing as a distributed state cache for large-scale web farms... Which is fine, but that is far from the only reason people use distributed caches. .NET is an awesome back-end technology framework, and leaving out back-end features of the DC just because you think people are going to be accessing it only from ASP.NET is shortsighted.

What Velocity is missing is push. If you look at the API reference (yes, I know it was only released today... and yes, I am that obsessive about new networking technology) you'll see that while there are concurrency methods available, there's nothing to indicate that push is available. By push, I mean that the cluster needs to be able to tell the cache clients when a change has occurred in the cash. I absolutely must have the ability to be notified when a cached item's version number has changed. Period. No exceptions.

In a distributed cache obviously I need the ability to Add, Put, and Get. Those are the basics. Velocity has this, and has some really interesting twists on getting (like tag-based fetching). But, it's missing Push. I cannot write software such that ClientA will be notified when ClientB has modified the cached item with a dictionary key of "customer101". Given that all of the major distributed cache vendors and people operating in the Grid space have some form of monitor/push functionality, Microsoft needs to implement this if they want people to use their DC (which right now is very "me too" and not offering anything innovative) over other DCs. The fact that Microsoft's is (currently) free won't make any difference when people see a DC without push.

I will be writing some code samples and playing with this more, but I'll be doing that after my WWDC presentation. I've got slides to prep and code to tweak so I'll have to put off my Velocity research until after WWDC.

tags: distributedcache  cache  velocity  microsoft  teched  

links: digg this    del.icio.us    technorati    reddit