Simplicity. That’s part of what has made memcached popular for bringing “fast” to web applications. The usage pattern is simple to understand, it’s simple to install the server, and of course it’s simple to get the client going with your application. In this last case, all you need to do is install the client, set up the server list, and start using it.
Could it be simpler? Sure. Any application deployment is not static.
Needs change over the course of time, which may mean you need to add servers, remove servers or deal with failed servers. Consistent hashing is one way people solve this, as originally proposed by Richard Jones and in use at Last.fm. Nearly all of the clients now have consistent hashing and can deal with unexpected server failures. However, this doesn’t address reconfiguration cases where you may add a server. You also need to come up with your own scheme for distributing changes. In many cases, rather unintentionally, this ends up either coded into the application or in some kind of configuration file which requires maintenance and when making changes to your farm of memcached servers.
With the NorthScale Memcached Server, we’ve made this even simpler.
Along with a client based on the non-blocking IO spymemcached client for Java, we’ve added a very small, open, simple, REST interface based layer which allows any to interact with the memcached servers for management and observation.
How do more APIs make it simpler? With the client shipped in the NorthScale developer kit, in the simplest usage mode, the only thing required is a single URI to bootstrap into the REST interface. Using that the client will walk the URIs, determine which servers exist in the “cluster”, and begin to use them.
Need more? You can feed the client the entire list of servers. They all represent the same state of the cluster. The client uses a comet-style interface to quickly react to changes when they occur. Need even more? You can specify which “bucket” you want to connect to, allowing for multi-tenancy with memcached. This means no more needing to come up with namespaces for shared systems across multiple applications.
If you want to cook up your own client to use the REST interface, create “buckets” and so forth it’s all there for you and documented.
In fact, we’ve already been working with Attila Kisk??, the author of the Enyim memcached client and Evan Weaver of Ruby’s fauna client. We’re looking forward to working with these guys and many others.
The servers have a coherent state, they provide simple HTTP/JSON REST services, providing fast and simple information about and access to the memcached services provided across the cluster. Clients and applications can leverage this in any number of ways to simplify the way they bring speed and scalability to their apps.
I’m glad to be back out with a public presence and persona again, after being stealth for a bit. If you happen to download and give it a shot, please post some feedback or give us some ideas on where you’d like to see things go next!
