Presented by: Jon Flanders
This is my rock star. He arrived only minutes before the session was about to start and after a quick check he started pacing back and forth on the podium, like an impatient “kaiser”. Then he started the exact second the clock hit 16:30. You’ve got to love him just for that.
The presentation was about the caching feature in AppFabric that Jon did not say was called “velocity” before bundled in AppFabric. Note that AppFabric in the post means “Windows Server AppFabric”.
The caching in AppFabric is a really cool feature because it handles caching of in memory data but distributed over several servers and the more servers you add, the more data can be cached. The nice thing is that it has a level of abstraction to it so it’s easy to configure and to code against. All the examples regarding AppFabric cache is around a web application but it could also be used for other things such as storage of configuration-files for services, or maybe parameter names for stored procedures that the application access. The really is no limit to it as the cache can store CLR objects, xml-data or binary objects (like images on a website). Jon summarized this by stating that “Scalability is the reason to use caching”.
To fully understand the advantages of AppFabric caching, Jon showed showed a slide that lists the advantages per tier.
User-tier: No stick load-balancing needed, all servers have access to all the data. Once a server enters a cache cluster it is aware of all the data on all the servers, so there is no lag needed for a lookup, for instance.
Web-tier: Easy access to the cache cluster. Programming against the cache is no different than it used to be when you stored something in the SESSION object back in ASP. It’s just the same.
Caching-tier: Multiple machines means scale and potential for high-availability. More machines == more memory for cache objects. This was not possible before on a Microsoft product and I would also like to remind you that caching servers can be quite cheap. You just need lots of fast RAM in it and you are good to go. To scale out a database, you need much more than that.
Database-tier: Reduces load on database. This is a good thing as it means you can lower the amount of, often expensive, hardware needed to run the data for a particular application.
It is worth noting that even if you have a lot of servers in the cache you access them from code in the same way as you would if you had a single cache. It’s also worth noting that the AppFabric cache is slower then the standard “on machine cache”, but by surprisingly little.
There is a session object for AppFabric cache, which to me is good news. During my web dev days I often heard that you should avoid using the session object to store data because it does not scale over different servers and also that it consumed memory on the machine processing the request. From now on there is nothing stopping you from using the object and that’s the good news because it was (and is) such a useful object.
Currently there is a Windows Azure version of AppFabric caching in the making but it has yet to reach any public version. It basically does the same things for your Azure apps as for the local ones.
Lastly a funny side note: Every time Jon started entering code, the room went totally quiet as everyone concentrated hard on not missing one single thing. Once Jon stopped typing and said something like “let’s compile” people moved and in some cases exhaled as if they where holding their breath while Jon typed. I did the same of course.