Pure Progress: Leaping Forward

I’ve been looking forward to elements of today’s announcement from Pure Storage for a couple months now, and I’ll be even more thrilled when bits and box hit the floor over the summer. Just last Thursday, I saw another orange victory (re)tweet and I was chomping at the bit to comment on the 1U gaps in between the controllers…

…Now the wait is over. The evergreen, ever-evolving, never-disruptive power of the FlashArray//m is being whispered loudly from those 1.75 inches of rack space. And it’s backed by the best support that’s somehow getting better!

pure_evergreenEvergreen Storage. It has a nice ring to it, doesn’t it? Makes me think of pine trees, my grandparents’ house as a child, and freshness. I’m pretty sure that is Pure’s goal, and it isn’t just marketing bluster.

Nearly everyone in the IT field has been through the 3-year upgrade cycle. Mine looked roughly like this (some concurrent):

EMC CX-300 :: EMC CX-3 40 :: NetApp FAS3040 :: 3PAR T400 :: HP 3PAR V400 :: EMC XtremIO :: Pure FA420

While we sometimes stayed within the same vendor, we always had to shift everything off and on in order to move forward. Thankfully technologies like Storage vMotion and Live Migration make it a lot less painful than some might paint it, but it’s still a big change, even for a small shop like mine.

Pure aims to change that. In fact, the only product in the list above that doesn’t require a “forklift” to move forward is Pure. We bought the FA420 this spring and the only planning required for the m-series upgrade later this year was to leave 1U open to make room for the new consolidated controller pair.

One concern I and others had when we first saw “Evergreen” was how Pure was going to achieve it without becoming “ever-old” and anchored in some ways to the past for legacy and compatibility (i.e. Infiniband interconnects in the current models). They obviously saw that as well and planned for it in the new controllers. As you’ll see in the next section, Pure left spare I/O slots open in the new design to temporarily accommodate the legacy cards for the controller refreshes. Once migrated, the cards come out (non-disruptively).

pure_mseriesFlashArray//m. For the last few years, Pure has innovated on software alone, while OEM’ing hardware from others. They’ve done quite well within the bounds of that design, but would never be truly “pure” without handcrafted hardware to match. The //m brings that.

You can read back to other posts of mine and see that while I have favored Pure, I have also been honest about my ability to throw certain rare workloads at it that cause Pure’s latency meter to spike momentarily. I emphasize that last word, because it didn’t persist, and it actually never flagged at a host/guest level. Talking with Pure’s support and product teams, they will tell you that their choice of metric reporting intentionally disadvantages themselves. They start and keep accounting for the I/O from end to end, regardless of whether any hold-ups are waiting on hosts. I can’t speak for other vendors, but I’m guessing everyone’s metrics vary in method, and I wouldn’t fault others for wanting to choose optimistic reporting. Kudos to Pure for laying all the cards out, even if some are dealt from outside their control.

Anyways! I said all that because the FlashArray//m is designed to level the latency playing field without compromising on data reduction. Pure designed it for much more than that–even greater rack density, faster fabrics, and perpetual lifespans–but I’m talking about the Haswell procs, the PCIe/NVMe connectivity, and the bigger, faster NV-RAM modules. I think this aspect is the diamond-in-the-rough game changer.

Pure already wins today on deduplication and compression. I’ve tested it myself and haven’t run into anyone who can argue otherwise. Pure also leads out with granular, flexible expansion, on the fly and without rigid building blocks. Now Pure can wipe away any competitive caveats on performance (even if they are merely reporting figures). Unless you’re in that 1% that truly does need 1 million IOPS to source from a single array (not me), the choice seems simple.

One closing note on the //m scale: the competition often tries to stand above Pure in capacity density per array. While that is true, Pure didn’t choose its design as an act of helpless resignation, but rather as a strategic decision toward web-scale and smaller failure domains. In the majority of enterprises, incremental and granular growth/change is an asset to the infrastructure, not a liability. For me, I’ll have a lot less fear and trepidation stepping through array software upgrades in pieces rather than jumping all in for one massive change, sink or swim. Just my two cents; feel free to comment otherwise.

pure_onePure1: Great support gets even better. It’s encouraging when vendors with inhibitive support take strides to reduce the pain points, but it’s inspirational when those with already easy support spend time and resources to make it awesome. That’s Pure1.

Since our POC in 2013, Pure Support has been simple to reach, quick to attain, and non-disruptive to execute. Pure1 will take that to the next level with globally-accessible array insights, even smoother support interaction, and community collaboration. I heartily agree with Chad Sakac when he says about ScaleIO, “don’t be stupid – I personally would never deploy something in production, any software, anything open source – without a clear support model” (link). That applies to everything in the enterprise–hardware and software. In fact, in many ways the strength of any product is only as solid as the support organization behind it.

Support was one of the leading reasons I pushed for Pure (and away from others) in our latest expansion, and if Pure1 is any indication of the future, it’s a reason to keep choosing Pure.

More to come when it I get hands-on with these announcements…

Be First to Comment

Leave a Reply