EMC launches Project Lightning (now VFcache) with immediate availability.
We preview a near-term follow-on technology -- Project Thunder.
The web then reverberates with reactions from extremely positive to somewhat negative to occasionally "meh".
It was a pretty interesting show if you watch this part of the tech industry closely.
Now it's Friday.
What have we learned?
I'm Only Gonna Use One Chart
... and here it is.
It's from Pat Gelsinger's launch deck, and it's one of the better ones.
And, as always, where you stand has a lot to do with where you sit.
A quick tour?
It's an easy representation of "where does flash go in the storage hierarchy?".
Let's start at the bottom -- we've got our familiar spinning disks. They aren't going away anytime soon. They typically live in storage arrays. They're getting cheaper per unit of capacity, but they aren't getting much faster.
Above that, we've got flash that lives in the array. Flash in an array can play one of two roles: act like a disk, or act like a cache. If we say "acts like a cache", we have to take the time differentiate between read-only (volatile) cache and read-write (non-volatile) cache. The difference is meaningful.
Much more performance from arrays that can intelligently use a mix of flash and disk for both reads and writes, obviously. In the EMC world, this is FAST.
I just can't imagine anyone buying an enterprise storage array these days without this sort of functionality, but it does happen :)
Now, skip up to the top, where we have PCIe server cache. Fastest of all, but can only be used for reads and writes you don't care about being persistent. Expensive in terms of $/capacity, a relative bargain in terms of $/IOPS.
That's the currently available VFcache.
One step down is the relatively new notion of "shared server cache", e.g. externalize the PCIe-based server cache so it's a shareable and managed resource. The interconnect is a server-to-server approach (think RDMA over IB or fast ethernet) vs. a more traditional server/storage interconnect -- latency matters. Basically, a pool of shared I/O performance.
That's Project Thunder. You'll see more of it before too long.
Got the picture? Flash in the server as a volatile cache, shared server flash caches, and flash in arrays acting as either a non-volatile cache or a storage device.
Now, let's have some fun ...
What Is The "Best" Approach?
There's a natural human tendency to look at various options and argue what the "best" approach is. Like any good vendor with a broad portfolio, the notion of "best" is entirely dependent on the specifics of the situation. It's not hard to imagine ordinary workloads that would benefit from one, two or all three of these technologies.
If you're providing shared storage services for a wide variety of workloads and applications (as many IT shops do), you're not going to want to land on one approach to the exclusion of all others. More tools in the toolbox is a good thing. And up-front requirements have this nasty way of changing once you get into something :)
In this week's web chatter, there were strong opinions that the "best place for flash" was either (a) in the server, (b) as a shared server resource, (c) as a volatile read cache in the array, or (d) as a disk replacement.
Our answer? All of the above.
Isn't That A Lot Of Data Moving Around?
People look at charts like this, and their heads can start to hurt. What data goes where? How does it get there? Who decides what's optimized? How are writes handled? Reads? What if the cache gets full? Etc. etc. etc.
Ideally, really intelligent software would just take care of all of that. Indeed, if the technology is going to be widely used, it's got to be dead-simple to deploy and operate.
During our announcement, we really couldn't say that our FAST software technology did that end-to-end -- at least not yet. FAST software works in the array today (the two bottom layers), and there's a separate bit of caching intelligence in VFcache -- so the end-to-end optimized view isn't quite there yet.
But it's coming, sooner than many people might expect. And, in our defense, we do a pretty good job of evolving our products in the timeframes we set out for our customers.
The end result is a fully-integrated and fully-automated storage optimization layer that allows individual applications to be either dynamically optimized for your preferred combination of performance (use more caching closer to the server) or capacity (use less caching everywhere, prefer spinning disks instead).
Infrastructure admin sets storage policy, the software does the rest. Same sort of dead-simple model that's working on today's FAST-enabled storage arrays from EMC.
Wow, All This Looks Expensive!
Care about cost per unit of capacity? Bias towards rotating rust. Care about cost per unit of performance? Bias towards shared flash resources -- starting at the bottom of the hierarchy -- and working your way up.
Since flash storage technologies are silicon electronic devices, they tend to follow Moore's Law vs. Seagate's Rule. The costs associated to accomplish XYX using flash are moving in the right direction quickly, meaning that -- as component costs and performance do their inevitable thing -- you're probably going to want a decent amount of flexibility in what you use, and where you use it.
The Competitors Weigh In
For starters, I've got to hand it to David Flynn, the CEO of Fusion I-O. He did a yeoman's job of talking to anyone who would listen his side of the story. If I were in his shoes, I'd certainly be doing the same thing. Must have been a very long day for him.
One point he tired to make was that the VFcache didn't offer the capacity of his product. True, but -- as you can clearly see from the discussion above, our goal was performance. Capacity? That's handled by the tiers underneath :)
For some reason, people were sort of expecting killer VMware support on Day 1 -- after all, that's what we've been doing in the past. In all fairness, the VFcache team was targeting large, more monolithic traditional applications that are starved for performance vs. larger VMware farms.
BTW, despite what you might read, no PCIe flash card vendor has meaningful VMware integration today -- a clear opportunity for us to innovate in the near future.
There was an interesting amount of "me too" from various folks. IBM just announced using SSDs for the XIV as (presumably) a read-only storage array cache. Someone showed me a nice "unbiased" comparison they did vs. VFcache. Obviously, the correct comparison would have been EMC's array-based FAST implementations, but that wouldn't have looked so good :)
One of the NetApp folks offered that they have been offering array-side read-only cache for quite a while. That's true, but not exactly a reasonable comparison, given the discussion here. I didn't hear a lot from the other storage vendors, e.g. Hitachi et. al.
There's more, but I think you get the picture. Competitive vendors were targeting one specific part of this picture. No one was showing the whole picture.
There was also a rather strange theme around people wondering how EMC could somehow "sell inside the server". Huh? Never mind that we've been selling and supporting gazillions of HBAs into servers successfully for many, many years -- or that our PowerPath technology is the de-facto standard in all sorts of enterprise storage environments.
Maybe we should have pointed that out to people.
Forgive my crankiness, but I was tired of hearing this 20 years ago, and I'm just as tired of hearing it today. It's one of the more distracting forms of intellectual onanism practiced by technology types, as far as I'm concerned.
Look, everyone wants choices, but there's no denying value derived from integration, support, etc. And, in modern IT discussions, it's more about value delivered vs. the cost of the components.
OK, I'm Done
If you watch this storage stuff closely (as some of you do), it was hopefully an interesting week on multiple levels. If you somehow missed that disks were quickly being augmented and replaced by flash storage technologies, you got another reminder.
If you somehow thought that storage belongs in one box, and servers in another, you got a preview of what's to come quickly here: a continuing convergence of server, storage and network. The technology is changing fast, as are the operational models.
On a personal note, I suppose I should have expected all the flak. After all, EMC is a big company that's moving fast on multiple fronts these days.
I would expect a few reverberations :)