Why Pure Storage?

I’m excited to say that earlier this month I made the decision to join the Pure Storage team as a Systems Engineer.   Since sharing my decision, I have been asked by friends, fellow architects and customers:

Why Pure?

Before I get into why I decided to join Pure, you first need to understand my view on an equally important topic:

Why All Flash? 

Flash Will Consume the Primary Storage Market Within 5 Years

I’ve been watching the evolution of solid state in enterprise storage systems since caching and tiering became mainstream in the late 2000s.  I believe this adoption is now at critical mass for a few reasons.

  • The cost of solid-state storage is dropping and is already less expensive than disk for moderate to high I/O workloads.  Data reduction capabilities such as deduplication and compression can provide significantly greater affordability and open flash to a wide variety of enterprise use-cases.
  • The user experience and business benefits of flash are undeniable.  Once a customer experiences flash for a single use-case, they immediately want those benefits expanded to the rest of the business.

Just as data reduction capabilities made disk an affordable and superior alternative to tape, the same capabilities have now made solid state an affordable and superior alternative to disk.  Disk is the tape of today.

Legacy Hard-Disk Arrays are Dying

More compelling is that customer interest in all flash arrays is skyrocketing.  Just as performance and complexity issues drove customers away from tape in the early 2000s, customers are now struggling with the same types of issues in hard-disk arrays.

  • Hard disk storage arrays, even with updated software and faster CPUs are far from realizing the full potential of flash storage.  Just as hard drives have remained largely unchanged since their inception, storage arrays designed for those drives are comprised layer after layer of archaic, hard-disk centric programming.  Legacy RAID layouts and fixed data structures are not easily updated.  If they were, the major storage manufacturers wouldn’t be buying or building new flash arrays, they would continue modifying the legacy platforms.
  • Solid-state tiering and caching has run its course. It is complex to properly size and the tiering logic is not magic—it frequently leaves the business exposed to unpredictable performance, and occasional serious slowdowns.  As drive capacities increase, pool performance becomes even less predictable.
  • Further issues such as nickel-and-dime licensing models, complex cloning and replication implementations and generally awkward management will give customers little hesitation in moving to new, simplified, all-flash arrays as quickly as possible.

Flash is a quantum evolution in enterprise storage that is long overdue.   It has been enterprise-ready for years and now it is finally enterprise-affordable.

So, Why Pure?

In my prior position as a solution architect, my job centered around advising customers as they considered, selected and implemented storage solutions.  As part of this, I spent several months researching flash technology, the market trends and the major players.  Pure impressed me in two major areas.

First, they weren’t trying to fill a niche’ in the market—they want to build a better storage company.  Flash provides the opportunity for a market reset—a new beginning in storage.  Pure is positioning itself to seize that opportunity by providing a genuine storage experience customers are hungry for.

  • Support that is actually proactive (not just parts replacement and bug fixes)
  • A storage lifecycle and maintenance approach that allows much longer useful life, without maintenance extortion and forced refreshes
  • All software is included and controller refreshes are free with eligible maintenance renewals
  • Non-disruptive architecture that enables perpetual, online upgrades and refreshes without multi-month, rolling-downtime, storage migration efforts
  • Transparency in customer realized data reduction rates (dedup ticker) and the only manufacturer to quote IOPS with larger, 32K block sizes; instead of smaller sizes to make IOPS look higher
  • A passionate, focused culture where customer experience is king—I’m blown away by how the company rallies to put customers first

Second, they have great technology.  Sure, they have flash performance and sub-ms latency; those are table-stakes in the flash realm.  However, they combine performance with innovative enterprise features, which are still not common, even in market-leading storage arrays.

  • Adaptive Block Sizes:  Processes block sizes from 512B to 128K as a single IO, which eliminates any possible alignment issues and provides much more consistent performance with real-world I/O.
  • Data Reduction: 5 forms, most significant are inline (insanely granular) 512B deduplication, inline compression and an aggressive background deep-compression.
  • Highly Reliable: Cached writes are stored in 4 locations before acknowledgement (2 controllers and dual NVRAM Banks). Deduped candidates are byte-level compared to avoid corruption due to hash collisions.  Multi-dimensional and dynamic RAID protection enables recovery from most flash failures with little disruption while still providing at least double drive fault protection.  The arrays even provide 100% performance during a controller failure.
  • Data Protection: Space-efficient snapshots, clones and replication all-included
  • Non-Disruptive Everything:  As mentioned above, perpetual online upgrades and refreshes


Since I have joined Pure I’m very glad to see that the culture, customer focus and technology is even better than I expected.  I’m really looking forward to sharing it!

4 comments to Why Pure Storage?

  • Disclosure: I work for HP Storage

    Congrats on the new gig and hope the best for you.

    I’ve seen the “arrays even provide 100% performance during a controller failure” marketed as a benefit but the part missing from that discussion is that Pure drives all backend IO (to SSDs) through a single controller. So sure, lose a controller and no one notices. However, customers are paying for dual controllers and 99.9% of the time when both controllers work they only get 50% of the performance. I’m not sure I’d call 100% performance during a controller failure a benefit given what that really means.

    We in fact just published a blog to set the HP 3PAR record straight based on blogging by your new colleagues. See http://hpstorage.me/1reHqAn

  • Calvin,

    Thanks for the comment and the well-wishes. There doesn’t seem to be much dialogue on blogs these days, which is disappointing, considering competing views are a lot more valuable to customers than marketing monologues.

    In response to your question about idle CPUs, customers I speak with consider this a good thing. Here are a few points as to why:

    – My customers don’t care about idle CPUs. They care about consistent performance, even through failures. When they make a purchase, they want the spec’d performance they paid for 100% of the time.
    – CPUs are cheap. Storage is expensive. Customers I speak with are far more interested in what we do to lower the cost of flash through deduplication, compression and deep-optimization. Reserving a few inexpensive CPUs to make sure the flash always performs to expectations, is a good thing.

    Coincidentally, I just returned from a customer performing fault resiliency testing on Pure this morning. We failed a controller, 7 drives, and SAS cable without any impact to the host IOPS or Latency. Did the customer whine “But some of the CPUs were idle?!”

    No, they said “Unbelievable!”

  • J Maestre

    I totally agree with you Mike. Idle CPU’s are irrelevant. In fact, a good architecture will do everything it can to keep CPU utilization waaaaay down so advanced features can run unfettered. An even better architecture is able to introduce new features on the existing hardware platform and STILL keep CPU utilization down. Heck, I think we can agree that the “best” architectures would not only introduce new features and keep CPU utilization down BUT also take advantage of new, updated hardware–such as newer SSD types/sizes–into the existing frames on the floor without impacting those same CPU’s or requiring outages or anything outlandish like that. **We all know that last one isn’t something Pure is going to be able to do but hey they’re young and impulsive! 😉

    Here’s where I’m lost in this whole thing and please don’t hesitate to call me crazy:

    Pure’s architecture is interesting. There’s a lot to be said for ‘scale-up’. The controllers being active/standby is a good thing, not bad. While memory may still be faster than SSD, any kind of up front processing may add latency to the IO path. No IO processing could, in theory, be a good thing. Where I’m lost is in how Pure manages metadata from DRAM to NVRAM. What happens should NVRAM fail for whatever reason? It happens, we all know. What happens if the controller fails with metadata in DRAM? Is the DRAM just essentially “read cache” for the busiest metadata with nothing ever being written to it?

    Assuming the response is going to be the latter then doesn’t that beg this question: If leveraging NVRAM at the shelf level is better…if writing to the SSD directly is better…if all of that is lower in latency…aaaand if there is zero penalty on reads from SSD…then why use DRAM at all? It’s contradictory to the marketing message.

    I digress…

    My other issue with your response is around the “customer” who was wowed at resiliency test. You failed a controller. Awesome! You failed 7 SAS drives. Awesome! You failed a SAS cable. Awesome! Did it all at the same time with no impact to performance. Awesome! So why not just go ahead and fail a shelf? The likelihood of a controller, SAS cable, and 7 drives all failing at the same time is drastically lower than the likelihood of an enclosure failing. Why not fail something more practical? What happens to Pure when an enclosure fails?

    I get that Pure’s marketing is darn good. I also get that Pure’s software is simple and easy. BUT I don’t get where the actual substance is. Why won’t they publish an actual technical white paper? Everyone else does. Why not publish something that shows the architecture and how everything works so that these questions–which we hear in the field ALL the time–can be answered and we can all see for ourselves.

    • J,

      Thank you for the note. I can very much appreciate your desire to know the depths of the architecture, I’m the same way. And, particularly in the all-flash space, there is A LOT of ambiguity in the architectures. The purity user guide goes into great depth on the architecture. So as long as your are open to an NDA, the information is available. I’ll try to answer some of your questions here, though.

      To your point on being able to continuously upgrade and refresh the platform without outages; that is already possible, and customers have already seamlessly migrated from 300 series platforms to the 400 series platforms. That is what the non-disruptive everything architecture is all about.

      In regards to the DRAM vs NVRAM question. Data written is stored in DRAM and copied to nvram for protection. Under normal operation, there are at least 4 copies of cached writes; one in each controllers DRAM and 2 stored on separate NVRAM modules. This is an important differentiator as some competitors ONLY cache in controller DRAM and protect the controllers with UPS. This protects against power failures, but doesn’t protect data against dual controller faults/panics–which are far more likely. In that scenario a dual controller panic results in data loss. In the Pure architecture, controllers are entirely stateless. NVRAM protects acknowledged writes in the event of both controllers simultaneously faulting. If all NVRAM modules should fail (highly unlikely), the controllers will flush data to SSD and halt new I/O. Data integrity is always priority.

      DRAM is critical to performance in any flash array. Flash get its performance from a parallel architecture. Individual SSDs distribute new I/O in parallel to many flash dies within each drive. Arrays should also distributes I/O in parallel across all SSDs. This parallelism is what gives all flash arrays their IOPS potential. Flash is also slow on individual writes, which is why it is bad to write directly to. Caching in DRAM (and protecting in NVRAM) provides a safe buffer to hide the write latency of flash from hosts. Hosts receive their acknowledgement as soon as the write is in cache. Once enough data is in cache, it is written to disk. With Purity, data reduction is also applied and writes are scheduled as to not interfere with the latency of concurrent read operations.

      Shelf failures are highly unlikely. The intelligence in disk shelves are in the redundant, hot-swappable I/O Modules in the rear. Between the modules and the drives is a passive, redundant mid-plane. However, should we lose redundancy in the mid-plane, the shelf can actually be replaced non-disruptively. If double failures bring the shelf down, data is still preserved.

      I hope this helps. If you are still interested, I would recommend you reach out to your local Pure team for more details and, perhaps, a POC. I can help get you connected, if you like.

Leave a Reply




You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>