Microsoft project code named "Velocity" : Velocity

Announcing Velocity CTP3 !

velocityteam — Wed, 08 Apr 2009 07:03:00 GMT

Velocity Team is happy to announce release of Microsoft project code named "Velocity" CTP3

For community technology preview 3 (CTP3), Microsoft project code named "Velocity" offers several enhancements and revised APIs. The enhancements include cache notifications feature, performance improvements, security enhancements, and new cluster management options. There have also been updates to the installation program. Please checkout Velocity CTP3 Help/Documentation for more details [Microsoft Project Code Named “Velocity” CTP3 on the Microsoft Download Center]

Cache Notifications

When using local cache to store data that changes infrequently, you no longer have to wait for the configured timeout before the client pulls the latest object from the cluster. Using cache notifications, the object in the local cache automatically invalidates as soon as it is notified that the object has changed. This greatly reduces the possibility that your application is working with stale data.

When caching data that changes frequently, you may want your applications to perform certain tasks based on various cache operations. For example, you may want your application to do something specific when a cached object is added, replaced, or removed. You might also want your application to do something different when a region is added, cleared, or removed from the cache. Specifying an event-triggered task is now possible with cache notifications.

Performance Improvements

Throughput, latency, and memory usage have been further optimized to improve performance for your applications.

Security Enhancements

The cache host Windows service now runs under a lower-privileged account: Network Service. To simplify deployment, the installation program now helps to configure the permissions of installation folders and the cluster configuration storage location. You still need to be an administrator on the cache servers and cluster configuration storage location in order to install "Velocity."

Note: Although these efforts help to secure the cache cluster; they are not enough to protect it from malicious activity. "Velocity" is designed to be operated in the datacenter, within the perimeter of the corporate firewall. Data transfer is not encrypted and is at risk of network "sniffing" and "replay" attacks.

New Cluster Management Options

Previously, only lead hosts could manage the cache cluster operations. Now, when using SQL Server to store the cluster configuration information, you have the option to let SQL Server perform the cluster management role instead of the lead hosts. This option improves supportability and availability of the cluster, eliminating the possibility of the cluster going down due to an insufficient number of (running) lead hosts.

Updates to the Installation Program

To streamline deployment, the installation program now supports automated installation for the cache host.

Cluster Configuration Editing Options Decoupled from Storage Options

Previously, how you chose to store your cluster configuration settings in the cluster configuration storage location dictated the options available to you for editing those configuration settings. Now, regardless of where you store your cluster settings, you can change those settings with the PowerShell-based cache administration tool or by directly editing an XML representation of the cluster configuration.

Along with this paradigm shift, the option to store the cluster configuration settings in XML (the cluster's "working copy") has been removed. Now you can export and edit (and import back) the configuration settings in XML when you choose to store your cluster configuration settings in a SQL Server database or a SQL Server Compact data file in a shared network folder.

With this change, your decision for the cluster configuration storage location can be based on application availability requirements and the resources available to your application (that is, how challenging it would be to procure an instance of SQL Server that your distributed cache cluster could use).

Revised APIs

To minimize changes in the following release, the "Velocity" APIs have been changed to enhance usability and more closely resemble the naming conventions of other Microsoft namespaces. The namespace of "Velocity" has been changed to Microsoft.Data.Caching from System.Data.Caching. Additionally, all class and delegate names have been renamed to include the prefix DataCache. Along with the name changes, many overloads have also been changed. For more details about the CTP3 API changes, checkout Velocity Online Help Section: CTP3 API Changes (Velocity)

Velocity MSDN Link : http://msdn.microsoft.com/en-us/data/cc655792.aspx

Velocity CTP3 Download Link: Microsoft Project Code Named “Velocity” CTP3 on the Microsoft Download Center

Velocity Team

Are you going to PDC? We are...

dpblogs — Fri, 03 Oct 2008 19:35:00 GMT

Come meet the Velocity Team in the pavilion and learn about Project "Velocity" in our 2 breakout sessions.

Project "Velocity": A First Look presented by Murali Krishnaprasad, Architect

It is predicted that all large applications will use a distributed data cache as the initial tier for all data access. This session presents an overview of "Velocity," Microsoft's distributed in-memory cache, and shows how it works with IIS, ASP.NET, ADO.NET and SQL Server Data Services.

Under the Hood: Velocity Architecture and Future Roadmap presented by Anil Nori, Distinguished Engineer

Velocity is an explicit, in-memory distributed cache. In this talk, we present Velocity's architecture to meet the high performance, scale, and availability requirements of web and enterprise applications. We will discuss mechanisms for data placement, data distribution, and data replication for performance, scale, availability respectively. We will describe mechanisms for providing database capabilities like LINQ support, indexing, concurrency control, and data consistency. We will also present the feature roadmap for Velocity.

More Information about PDC 2008 - Los Angeles, CA - Oct. 27-30
Microsoft's premier developer event, the Professional Developer Conference, is just over 3 weeks away. PDC 2008 will feature more than 160 sessions covering a wide range of topics for professional developers and architects. Each session is delivered by Microsoft engineers, so attendees can expect to receive a high-quality in-depth technical understanding of Microsoft’s future platform along with practical guidance for helping plan the evolution of products and technologies. Microsoft's Chief Software Architect, Ray Ozzie, is set to kick off the event with the keynote. With all the excitement around Visual Studio 2008 and Windows Server 2008, and with SQL Server 2008 just released, this PDC should prove to be a very exciting event. Don't miss it! Here's the link to register.

Creating Multiple Velocity Instances on a Single Machine

velocityteam — Tue, 10 Jun 2008 12:50:00 GMT

This article will guide you through the process of creating more than one instance of Microsoft project code named "Velocity" (henceforth referred to as "Velocity" for the remainder of the article) on one standalone machine. All such instances created on this machine can form a cluster (or multiple clusters), just like it were installed on different machines.

Currently "Velocity" runs as a 32 bit process (even on 64 bit OS) with address space limited to 2GB. So, by creating multiple instances of "Velocity" you will be able to leverage the capabilities of a machine with lot of memory and CPU power.

By default "Velocity" will be installed in "%Program Files%\Microsoft Distributed Cache". This directory contains

"Velocity" DLL’s / EXE’s
Configuration file DistributedCache.exe.config
Other supporting files

The “default” installer that we ship can only install one instance of "Velocity" on a given node. In order to install multiple instances, follow these steps.

[Each "Velocity" instance is referred to as a cache host which is actually a windows service. We will create multiple "Velocity" windows services and add them to the "Velocity" cluster.]

Make sure that you have "Velocity" installed on the machine where you want to run multiple services. Stop the cluster (if it is already running) from the Administration Console (e.g., MyCluster> stop cluster)
Create directories for each of the hosts to be set up in this machine. E.g., If you want to create two more instances other than the one installed, then create directories like "Microsoft Distributed Cache Instance-2" and "Microsoft Distributed Cache Instance-3". Copy all the contents from the installation directory (default: %Program Files%\Microsoft Distributed Cache\V1.0) to these directories.
Create a new Windows service for each of the instances using following command
sc create <serviceName> binPath= "<newCacheHostDir>\DistributedCache.exe" DisplayName= "<displayName>"
Where,
- serviceName – Name of the service to run the new instance.
- displayName – Service name displayed on the services tab.
- newCacheHostDir - Full path of the directory for new cache host.
C:\>sc create DCacheHost2 binPath= "C:\Cluster\Microsoft Distributed Cache Instance-2\DistributedCache.exe" displayName= "My Cache Host 2"

C:\>sc create DCacheHost2 binPath= "C:\Cluster\Microsoft Distributed Cache Instance-2\DistributedCache.exe" displayName= "My Cache Host 2"
Each newly created Windows service will represent a cache host in the "Velocity" cluster. Modify the 'DistributedCache.exe.config' file in respective directories using notepad as follows
1. Modify the cacheHostName to match the “serviceName” specified during the “sc” command above.
2. Set desired log location for new cache host.
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<configSections>
        <section name="dcacheConfig" type="System.Data.Caching.LocalConfigReaderWriter, CacheBaseLibrary, Culture=neutral, PublicKeyToken=null" allowLocation="true" allowDefinition="Everywhere" />
    </configSections>

    <dcacheConfig clusterName="MyCluster" hostName="IMDBSTRS01" cacheHostName="DCacheHost2">
         <config location="C:\ConfigStore\MyCluster" />
        <log location="C:\Cluster\Microsoft Distributed Cache Instance-2\logs" />
    </dcacheConfig>

</configuration>
Modify the clusterconfig.xml file to configure the cluster for these newly created cache hosts. The clusterconfig.xml fill can be found on the network share you specified during installation

Update the 'ClusterConfig.xml' by adding entries for the new cache hosts in the hosts section. You can copy the existing entry and modify following parameters
- hostName – Modify the hostname to match the “hostName” in the DistributedCache.exe.config
- cacheHostName – Modify the cacheHostName to match the “serviceName” specified during the “sc” command above.
- clusterPort and cachePort – These ports should not conflict with other ports on the network (or other cache hosts)
- hostId – Unique identifier for the cache host in the cluster.
- You can choose to edit some of the other parameters for experimenting with "Velocity".
E.g., if you create a cache service with name "DCacheHost2" and "DCacheHost3", example entries would be like:

<hosts>
    <host name="IMDBSTRS01" hostId="1552752876" quorumHost="True"
          cacheHostName="DistributedCacheService" cachePort="22233"
          clusterPort="22234" size="2048"
          lowWaterMark="70" highWaterMark="90" />
   <host name="IMDBSTRS01" hostId="1552752877" quorumHost="False"
         cacheHostName="DCacheHost2" cachePort="22333"
         clusterPort="22334" size="2048"
         lowWaterMark="70" highWaterMark="90" />
   <host name="IMDBSTRS01" hostId="1552752878" quorumHost="False"
         cacheHostName="DCacheHost3" cachePort="22433"
         clusterPort="22434" size="2048"
         lowWaterMark="70" highWaterMark="90" />
</hosts>
Now all the services should be available as part of the windows services.
You can start the services using start cluster command from "Velocity" Administration Tool.

Your 3 node cluster is now up and running! Happy Testing!!!

Sudhir Jorwekar, Arun K S
(Microsoft project code named "Velocity" Team)

How to Use Session State Provider (Microsoft Project code named Velocity)

velocityteam — Thu, 05 Jun 2008 17:15:00 GMT

Microsoft Distributed Cache code named Velocity ships with a custom Session State provider that use distributed cache to spread session objects across the cluster; thus, providing scalability to your web applications.

To configure SessionStoreProvider in your web apps:

1. Add <sessionState> element to your app’s web.config file:

</providers>

</sessionState>

This means, instead of using default session state provider that ships with asp.net, SessionStoreProvider will be used to read/write session state objects for the app.

2. As the session store provider is a client to distributed cache, it needs to have Velocity client configuration elements. After adding these client configuration elements, “web.config” should look like:

<?xml version="1.0"?>

<section name="dcacheClient" type=" System.Configuration.IgnoreSectionHandler"

allowLocation="true" allowDefinition="Everywhere"/>

</configSections>

<hosts>

<host name="<serviceHostName>" cachePort="22233" cacheHostName="DistributedCacheService"/>

</hosts>

</dcacheClient>

<system.web>

</providers>

</sessionState>

</system.web>

</configuration>

Note : “serviceHostName” is the hostname where distributed cache service is running on cache port “22233”(default setting). Configure these 2 parameters appropriately. Further, this configuration uses a “simple” deployment. By using “routing”, you can further improve the cache performance. For more information on client configuration, please refer product help documentation.

3. Add Reference to dll’s that the session store provider uses , easiest way to do that in a web app is to copy dll’s to the “bin” directory of your web app. Following dll’s need to be copied: CacheBaseLibrary.dll, FabricCommon.dll, ClientLibrary.dll, CASBase.dll, CASClient.dll .

And now your web application is ready to run with the Velocity SessionStoreProvider.

Important:

1. For Velocity Session State provider to work, Cache cluster should be up and running. To learn about to how to deploy Velocity Distributed Cache Cluster, please refer the product documentation.

2. As the provider stores the session objects in out-of-proc distributed cache service, objects that you put in Session should be serializable.

Further Configuration Options:

1. Session objects can be stored on a custom created Named Cache. Using the Administration Tool (Velocity) a Named Cache can be created. Modify the <sessionState> element in your web.config file to use this new custom created Named Cache.

</providers>

</sessionState>

2. Similarly you can configure to store all the session objects in a region under a Named Cache. Configure the <sessionState> element in the web.config as illustrated below:

<add name="SessionStoreProvider" type="System.Data.Caching.SessionStoreProvider, ClientLibrary"

cacheName="<YourNamedCache>" regionName="<YourRegion>" />

</providers>

</sessionState>

<YourRegion> will be created automatically. Now all the session objects will be stored in <YourRegion> of the named cache <YourNamedCache>. Objects stored on a region will not be load balanced across cache hosts, but will be located on that cache host where the region was created. For this reason, it is not a general recommended configuration and should be used when there is a special need to locate all session objects on a single node.

3. To enable logging on client side, following section needs to be added to your app’s configuration file “web.config”.

<customType

className="System.Fabric.Common.EventLogger,FabricCommon"

sinkName="System.Fabric.Common.ConsoleSink,FabricCommon"

sinkParam="" defaultLevel="-1"/>

<customType

className="System.Fabric.Common.EventLogger,FabricCommon"

sinkName="System.Fabric.Common.FileEventSink,FabricCommon"

sinkParam="<CacheClientLog>" defaultLevel="1"/>

<customType

className="System.Fabric.Common.EventLogger,FabricCommon"

sinkName="System.Data.Caching.ETWSink, CacheBaseLibrary"

sinkParam="" defaultLevel="-1" />

</collection>

</section>

</fabric>

<CacheClientLog> is the name of the file where logs will be created.Your application should have privileges to write in the location that you specify.

As we know, before any section can be used in an application config file, it has to be introduced in the <configSections>, so following needs to be added to <configSections> element in the app’s “web.config” file:

<section name="fabric" type="System.Fabric.Common.ConfigFile, FabricCommon"

allowLocation="true" allowDefinition="Everywhere"/>

Example “web.config” File:

Now let’s see how a “web.config” looks like for the app which have all the configuration elements described above. In the example below, we show the "web.config" file for an application that contacts a cache service running on a local host on port “22233” and has logging enabled.

<?xml version="1.0"?>

<section name="dcacheClient" type=" System.Configuration.IgnoreSectionHandler"

allowLocation="true" allowDefinition="Everywhere"/>

<section name="fabric" type="System.Fabric.Common.ConfigFile, FabricCommon"

allowLocation="true" allowDefinition="Everywhere"/>

</configSections>

<hosts>

</hosts>

</dcacheClient>

<customType

className="System.Fabric.Common.EventLogger,FabricCommon"

sinkName="System.Fabric.Common.ConsoleSink,FabricCommon"

sinkParam="" defaultLevel="-1"/>

<customType

className="System.Fabric.Common.EventLogger,FabricCommon"

sinkName="System.Fabric.Common.FileEventSink,FabricCommon"

sinkParam="CacheClientLog" defaultLevel="1"/>

<customType

className="System.Fabric.Common.EventLogger,FabricCommon"

sinkName="System.Data.Caching.ETWSink, CacheBaseLibrary"

sinkParam="" defaultLevel="-1" />

</collection>

</section>

</fabric>

<system.web>

</providers>

</sessionState>

</system.web>

</configuration>

Let’s know if you face any issues and have any suggestions.

Project "Velocity" CTP1 Features

velocityteam — Wed, 04 Jun 2008 20:53:00 GMT

Hi,

I hope you got a chance to visit our velocity page, download the bits and try it out – We are waiting to hear your feedback and you give it us by commenting on this blog page or by visiting us on our velocity forum.

I want to talk about our CTP1 features in this post.

Our CTP1 features spanned the following areas – I have one line descriptions for these to keep this entry short, if you need to learn more about these areas please read our whitepaper or our documentation that comes with the velocity install

1. Support for different cache types

a. Partitioned Cache

This allows the data to be partitioned among all of the available nodes on which the named cache is defined.

b. Local Cache

This allows for very frequently accessed items to be kept in the object form within the application process space.

2. Support for different client types

a. Simple client

Simple client does not know about any routing and always contacts one node which will forward the request as needed

b. Routing Client

Routing Client knows the routing table so it can contact the node that has the object directly thus saving a network hop.

3. Deployment topology

a. Cache Service

In CTP1, you can configure a cluster of servers to host your cache and provide a cache Service. Any number of clients can access this cache service.

4. Concurrency Models

All cache operations are atomic and we provide the 2 models below when working with updates.

a. Optimistic concurrency model

“Velocity” supports version based updates and with this model when you retrieve an object you also get its version. When you add the updated object back to the cache, you pass in the version and if it is the same as the version you retrieved, your update succeeds.

b. Pessimistic locking

“Velocity” also supports for explicitly locking an object to perform updates

5. Expiration by TTL & Eviction using LRU

“Velocity” allows you to deal with stale objects by setting expiration policies using TTL and maintain available memory capacity through eviction.

6. Load Balancing & Dynamic Scaling

With “Velocity”, you can add new nodes to your cluster if you need to either increase the data that you want to cache or increase the throughput or decrease the response time. “Velocity” will do implicit load balancing and new data will be cached in the new machines and existing partitions may also be migrated to the new machines to load balance.

7. ASP.Net Integration

“Velocity” provides a session store provider that allows you to store your ASP.Net Session object in “Velocity” cache – This enables non-sticky routing allowing scaling your application.

8. Key based Access

“Velocity” supports simple key-based access. The cache access methods take in a key that uniquely identifies the object.

9. Tag Based Access

You can also associate tags with each object to describe it and you can retrieve objects based on tag values.

What’s beyond CTP1 –

1. Availability – support for Failover when machines go down

2. Replicated Cache – another cache type

3. Embedded Topology – run the cache embedded within you application instead of as a cache service

4. Notifications – Get notified when a object in the cache is updated

5. Consistency Models – Support for both weak and strong consistency when doing reads/writes

6. Native client access to the cache service (E.g – PHP, C++ etc)

7. Manageability & Administration

We are working on our next CTP plans and if there is a feature that is really important to you in the list above or if there are features that you expect to see but is missing from this list, let us know –

Thanks

Nithya Sampathkumar

Program Manager

Microsoft Project Code Named "Velocity" - Followup

velocityteam — Tue, 03 Jun 2008 22:51:00 GMT

Yesterday, we announced the first CTP of Microsoft Project Code Named “Velocity”. This post is a follow-up to clear up a couple of points that we’ve seen in forums.

First, the usage scenarios. Velocity is intended to provide distributed caching (in memory) for all .NET applications – from enterprise scale to web-scale. We believe that there are many applications that need a distributed caching mechanism, and that there is, therefore, a need for distributed caching as a core part of the .NET platform. We expect to have more integrated support for this functionality with other parts of the .NET platform in our upcoming releases.

ASP.NET applications are an important class of applications that we expect will benefit significantly from Velocity. The current CTP of Velocity includes a Velocity SessionState provider that leverages Velocity to maintain session state in a scalable (and in the future, available) fashion. Velocity can also be used to manage application data (ASP.NET Application Cache) for ASP.NET apps; however, the application patterns there need to be more explicit, unlike in the SessionState scenario.

Our support for ASP.NET is part of the integrated .NET platform story. Rest assured that we are not focusing exclusively on ASP.NET applications alone. As an example, we plan to integrate with plain .NET applications (windows service, for example) or IIS applications that may not involve ASP.NET.

Now onto upcoming functionality. The current CTP features support for scale-out, local caching and ASP.Net SessionState integration among many others. We have a full bag of work items we’re looking at for our subsequent CTPs and RTM – including support for availability, replicated caches, notifications, better management support etc.

Push-based notifications is a request we’ve heard from many folks. This is certainly an area we’re looking very deeply into. While our current CTP does not have this support, this is very likely to be remedied in our upcoming releases. In the interim, if you’re using Velocity with a local cache, we have some workarounds for this with APIs like GetIfVersionMismatch() to help deal with potentially stale/out-of-date objects in the local cache. (You will need to use a combination of Get() and GetIfVersionMismatch() to get the right behavior)

We will post a full description of CTP1 functionality later today. In the meantime, stay tuned for upcoming updates.

Let us know what you think. Would you use this functionality, and how/when ? What kinds of data would you like to cache? What features do you think will make this a better story? What pieces of functionality are completely missing?

S Muralidhar

Architect

Introducing Project Codename "Velocity"

dpblogs — Tue, 03 Jun 2008 06:29:00 GMT

The advances in processors, memory, storage, and connectivity have paved the way for next-generation applications that are data-driven, whose data could reside anywhere (i.e. on the desktops, mobile devices, servers, and in the cloud) and that require access from anywhere (i.e. local, remote, over the network, from mobile devices, in connected and disconnected mode). This trend has led to the development of distributed, multi-tiered, and composite application architectures for the web and for the enterprise. A typical enterprise application accesses data from multiple data sources, integrates that data, re-shapes (or transforms) that data into a form most suitable for the application (typically into object form like C# or Java object), and writes application logic. The same is true of web applications – consider social networking apps or mashups – they access data from multiple web sources, over the internet, aggregate it, execute application logic, and generate pages for web interaction. As these styles of multi-tiered web and enterprise application are becoming main stream, the demand for application performance and scale is increasing. End users become less tolerant and more frustrated when a web application cannot respond in milliseconds; web applications that cannot scale, as the number of concurrent accesses increase, lose traffic and thereby business. Fundamentally, we have all begun to expect high performance and scale from every application. And let’s not forget application availability. For similar reasons to those I describe above, an application cannot be down. We cannot imagine the MSN portal or the Amazon web site, or the corporate SAP financial application being down when we need it. We expect to access our personal information on MSN at any time; consumers do business with Amazon at any time and from anywhere. Fundamentally, applications need to be available all the time to support access at any time, and from anywhere. Another major expectation, especially from application developers and from application hosters is that of scalable and available applications at a low cost. A decade ago, only mission-critical businesses could afford to invest in large and expensive infrastructure (both hardware and software) to support scale and availability of their applications. But, now with web hosting, everyone expects and demands high scale and availability at low cost. Extending this even further, not only developers want cheap scalable and available applications, they want the ability to develop (and deploy) such applications very rapidly.

To cope with competitive pressure, both from an innovation and a deployment perspective, rapid development and deployment of these applications is critical for application vendors. In turn, application developers are looking for application infrastructure that enables them to build highly performant, scalable, and available applications using commodity hardware and software, at a rapid pace. Traditional application platforms like the .NET and Java platforms, which are known for rapid multi-tier application development and deployment, are required to provide the scalability and availability infrastructure.

Distributed cache is becoming the key application platform component for providing scalability and high availability. In-memory caching has been traditionally used primarily for meeting the high performance requirements of applications. By fusing caches on multiple nodes into a single unified cache however, the distributed caches offer not only high performance, but also scale. By maintaining copies of data on multiple cache nodes (in a mutually consistent manner), the distributed cache can also offer high availability to applications. Distributed caches are especially ideal for applications with the following characteristics:

There is a considerable number of data requests that are mostly read (e.g. product catalogs)

Large concurrent access to such data can be provided by replicating the catalog data on multiple cache nodes. Since updates are infrequent to such data, maintaining consistency (synchronously or asynchronously) is not very expensive

Applications that can tolerate some staleness of data

Such applications can provide better performance and scale by not requiring immediate updates ore refreshing of caches

Applications that can work with highly partitioned data (e.g. session data, shopping cart)

High scale and performance can be supported by partitioning and distributing data across multiple cache nodes, and thereby distributing data processing across the cache nodes

Applications that can work well with eventual consistency

Consider a flight inventory application, which must satisfy a large number of concurrent read/writes to the inventory of seats. To support large scale, the distributed cache may replicate the inventory value on multiple nodes; however, the inventory values on different nodes have to be made consistent in some fashion. Requiring immediate (also known as strong) consistency will require updates to be synchronously propagated to all the copies. Such action would impact the overall performance and scale of the application. However, instead of immediately making the copies consistent, allowing them to eventually (in an asynchronous manner) become consistent will provide low latency, high performance access to inventory.

As distributed caches become more widely deployed, I believe over the next few years, distributed cache will be used as the first tier of all data access. Multi-tier application architecture will include the cache tier as a data access tier between the application server tier and the backend data tier.

Today, Microsoft is announcing the first CTP of a distributed caching product to provide the .NET application platform support for developing highly performant, scalable, and highly available applications. The project code named “Velocity” is a distributed cache that allows any type of data (CLR object, XML document, or binary data) to be cached. “Velocity” fuses large numbers of cache nodes in a cluster into a single unified cache and provides transparent access to cache items from any client connected to the cluster. http://msdn.microsoft.com/data provides additional information about project code named “Velocity” as well as links to download our first CTP.

Distributed caches are not new – during the last couple of years several caching products have emerged to address the performance and scalability needs of applications. Most of these products are point products, primarily supporting key-based access. Other than memcached, which is an open source technology, most others target enterprises and enterprise workloads and scale. I think the web workloads require considerably large scale, with 1000s of cache nodes in a cluster. The web scale distributed caches not only require mechanisms that can scale and provide availability in very large clusters, they must be easy to manage or self-managed. In the Future, “Velocity” envisions being an integral part of the .NET application stack targeting both enterprise and web workloads (and scale). As applications start using the caches for data access, I also believe, they will demand richer data services like query, transactions, analytics, synchronization etc. For example, we believe .NET applications will require LINQ queries on the distributed cache, the same way they query the backend SQL Server database. We envision “Velocity” becoming such a comprehensive distributed caching platform. The performance, scale, and availability functionality of “Velocity” along with its rich data services will allow for rich web and enterprise applications development and deployment.

Anil Nori
Microsoft Distinguished Engineer