Levelling the EMC Lightning playing field
Another way to avoid lock-in
Opinion Here's a blogger saying an open industry standard will not be the best way to level the storage array/server flash card playing field and prevent EMC locking in Project Lightning customers, writes Chris Mellor
Certainly he has his own interests here but the general argument is worth paying attention to, in my view. If you disagree flame me, not Ted Sanford. Here's his blog:
Levelling the LIghtning playing field
EMC's Project Lightning will shake up the business because flash-based caching, integrated with underlying storage, can drive a very big shift in the technology landscape. But EMC’s proprietary stack could lock out innovators that don’t have a seat at EMC’s table (or with one of the other big vendors as they follow EMC’s lead).
The open standard you suggest could lead to a different future, without the lock-in (or lock-out) of a proprietary stack. Customers and vendors alike would benefit from a more level playing field.
But an open standard is not the only way to avoid the drawbacks of a closed server-flash-to-storage-array interface. For example, a third party provider with proprietary software but open APIs to storage arrays could deliver the same level playing field. In fact, FlashSoft is delivering this product today.
From our experience, I can tell you that a vendor-neutral software solution can achieve the end result you describe: a more open and larger market. It can do it now, and it can provide an open platform for server-to-storage integration based on enterprise flash.
In the long term, industry organisations may develop interface standards for a “Project Lightning-style” architecture. In the near term, however, the solution will come from a commercial software offering with open APIs. Here are a few reasons why.
1. Time (now): Project Lightning is coming fast. Server and storage competitors need a response now, not a couple of years down the road when a specification has been agreed.
2. Time (future): Rapid technology developments typically outpace standards. Given a choice between maintaining standards compliance and keeping pace with the state of the art, vendors will follow the money.
3. Scope (technology): Project Lightning isn’t just about an interface; it’s about extending the core IP of FAST outside the FAST array. Can an interface standard support diverse data hierarchy models without being too restrictive or to general to be useful?
4. Scope (applications): It’s very early to say how flash in the server will evolve. Should an interface standard support both data tiering and data caching? Read-only and read-write? Low latency storage networks only, or just the high end?
5. Compatibility: We’ve focused on performance, but do we also account for how server-tier memory will support “storage features” like backup, compression and de-dupe?
In short, I would argue that a standard alone will not solve the problem, and that by the time one were ready, the ship will have sailed. But that’s no reason to panic. ®
Sponsored: DevOps and continuous delivery