The Other Side Of The Discussion
So, my view is somewhat different. Chris wanted to get the pot boiling, so I'm going to help him here. But I'm going to come at it a bit differently.
If we think about "workloads" instead of "applications" (just for a moment!), a different picture emerges. Let's start with a familiar workload: storage replication. You can run it at the server layer, or you can run it within the array. Having it "close to the data" provides some advantages, and you see plenty of array-based replication in the market.
Now for another example: anti-virus scanning. You're free to run it on the desktop, or all of your servers -- but many people prefer to run it as close to the data as possible.
So if we think in terms of which workloads don't use a lot of CPU, but use a lot of data, perhaps a different picture emerges? Let's see: backup, search, some forms of big data analytics, etc.
I don't think anyone is proposing using today's storage arrays as a general-purpose compute platform. But it's not hard to see that there are certain workloads that can benefit from being very close to the data and not having to traverse a network to get their work done.
Now for the neck-twister: in a near-term world of commodity components and software stacks -- what *exactly* is a server, and what is a storage array? They're starting to look awfully similar in many regards ...
So the discussion morphs a bit: when is it appropriate to have dedicated roles (compute nodes, storage nodes), and when does it make sense to have nodes with combined roles (server and storage). A familiar Hadoop cluster is an example of the latter -- it runs applications right on the storage.
My two cents
-- Chuck
chucksblog.emc.com