Observations from the Flash Memory Summit 2014, Part 2, beyond the feature checklist

At the Flash Memory Summit, Josh Goldstein (our VP marketing and products management) was on a panel discussion with some of the other AFA vendors.  Attached is what he presented and you can download the other vendors from the FMS webpage below

Part 1 of the series which you can read here: http://volumes.blog/2014/08/18/observations-from-the-flash-memory-summit-2014-part-1/  was a reflection about being chosen as THE market leader.

this post is a reflection about the storage panel that was held during the summit..

let’s start by saying that it’s interesting how the lack of a proper (some may call it “true”) AFA specific architecture is being compensated by some clever marketing pitch

 

• Overemphasis on 100% performance all the time.  some vendors will try to make a big deal of losing performance when a controller fails.  while they are active/passive – a VERY simple implementation that does maintain the same performance with a failed controller, but which doesn’t deliver close to XtremIO’s performance the other 99.999% of the time.  Which bring us to….

http://www.xtremio.com/a-tale-of-two-architectures-engineering-for-the-99-999-versus-the-0-001

• ….1M IOPS – some competitors will try to say this doesn’t matter and that you should focus on consistency.  Well, we wholeheartedly agree you should focus on consistency and predictability of performance.  And that you also need 1M IOPS for where applications are heading and for workload consolidation.  Just attend my upcoming session at VMworld to hear about real world customers who put in a PO in order to  give every developer a high performance database sandbox.  Can’t do that on a limited Active / Passive architecture that is limited in intself and that is before we are even talking about scale – out!

• “Adaptive I/O” – because some competitors can’t compete with always-on, always-inline, consistent and predictable performance and data services.  So they’ve changed their messaging and now say their array is “adaptive”.  You know what that means?  It means the more load it contends with the less CPU time is allocated to process data services like deduplication and compression.  That leads to inconsistent and unpredictable performance.  Don’t let the nice marketing to sway you the customer away by proving out their array under low load situations.  We encourage people to hammer XtremIO and this is the reason some competitors hates when customers actually put the pedal to the metal with their array.  Insist that they do.

• Defocusing scale-out.  some competitors will try to tell customers that nobody needs scale-out because customers prefer fault domains in cloud environments with multi-array management instead of scale-out.  We know this isn’t true.  Customers are pushing us for larger and larger cluster sizes TODAY! .Yes, there is a point about fault domains – but the domain size is much larger than what a single active competitive  controller can handle.  You still need scale-out, even with reasonably small fault domains.  Remember – other Storage arrays designed to run today’s workloads with some more IOPS.  XtremIO is designed to change the entire way you deploy applications and give you the power to run tomorrow’s workloads.

• A competitor calls 4KB benchmarks “unicorn IO” and wants to focus the attention on I/O sizes of 32KB or larger – what they call the “real world application IO zone”.  BRING IT!  We will win over them on any benchmark at any IO size – especially on cost-equivalent systems.  We’ve proven this in POC after POC.  A fully populated $1.5M competitive product is no match for two X-Bricks.  And we still have the headroom to add 8 more active controllers!

• some competitors  likes to say “not all data reduction is built the same” – WE AGREE.  Customers should demand inline all the time.  There’s no other way to get consistent and predictable performance and superior flash endurance.

• competitors are now trying to steal our “Architecture Matters” tagline.  Remind youself whose message that is and why we say it all the time, as well as the numerous architectural disadvantages other products have – active/passive dual controller, post-processing data reduction, cMLC and system level garbage collection, metadata only partially cached in RAM, etc.

• most of the other competitors  will try to say that there are many garbage collection strategies and that system level garbage collection isn’t bad – that customers should focus on results, not implementation.  WE AGREE.  We’ve proven in POC after POC that other vendors system level garbage collection wreaks havoc on their performance and consistency.

 

 

 

In summary:

Flash array designs vary widely.

Things that sounds the same aren’t.

If your’e only thinking of flash arrays for performance, you are missing much of their value.

Edcuate yourself and make informed decisions.

Don’t be fooled by hype or hero numbers.

Look for true innovation.

Test, test, test