Pure opens XtremIO, VMAX swap shop as Dell EMC party kicks off

It's a good ploy

I wandered into my manager's office the other day and told him he had permission to beat me with a tire iron until I stopped spouting idiocy if I ever recommended buying EMC again. Over the past several years, every EMC purchase has turned into an unexpected boondoggle, from logistical fulfillment to cost to the sudden axing of critical features. Even if a particular product is nominally the best in class, I'm still loath to do business with them again.

25%? Really?

Talk about late to the party.

(Dell) EMC has had a similar program for years, and has traded in multiple dozens of Pure arrays under it, mainly from customers would found they just couldn't scale to more than a single workload. And at a much higher trade-in value than 25%...

(Yes, I work for Dell EMC)

Pure is SMB at best, not worthy of mention in the same article as VMAX.

//x isn't GA or even DA yet. Evergreen is a Ponzi scheme for Pure to stay in business for now. It’s an expensive tiered “subscription” that’s essentially three years of prepaid maintenance and NOT a program. Other than that, Pure hit the enterprise mark ans is ready to pick off VMAX!

I see Pure limited the 25% to capacity only, “trade in and consolidate a portion of their existing installed XtremIO or VMAX capacity”. A PORTION…..Not surprising as 25% of VMAX's max 4.4 PB usable may be a flock of Pure's dual headed active-passive arrays, and that’s ONLY considering capacity. What is Pure missing in their 25% trade in deal? Many customers buy VMAX not only for capacity but for scale in other dimensions that Pure can't meet 25% of (at least based on their max system limitations they publish in the public domain, which is none).

For instance, what’s the max number of hosts that can attach to a Pure array? What is Pure’s maximum supported number of provisioning groups, LUNs or vVol's per system? How about per port? VMAX is 64K volumes. How many Pure arrays would it take to equal just a single of VMAX’s 256 potential max ports, who’s architecture supports 1,024 WWN (HBA's) logged in PER PORT? Or 4,096 max LUNs per PORT? Again, that’s one out of a potential 256 front end interface ports at 16 Gb/sec. But don’t limit your options to 16 Gb/sec Fibre Channel (or 8 Gb/sec, for that matter). How about customers who use have 1 Gb/E ports for NAS or iSCSI in their VMAX? Many VMAX customers have 10 Gb/E in their VMAX for integrated replication.

And some BIG enterprises use a large host called a mainframe that attaches via FICON. Yep VMAX supports those ports and devices too! Some of these customers have both Open Systems and Mainframe on the same array! This provides them Enterprise Consistency across their entire shop so that they could restart thousands of hosts at the same point in time during a system wide DR. How about Pure? How do they handle a single host that spans two of their dual headed A/P arrays? What about several hosts across many arrays that need to be restarted at the same point in time and an RPO of zero or even seconds?

Could the 25% trade in be from capacity from VMAX's externally virtualized LUNs (called eDisks) from either EMC or Non-EMC storage (2,048 max eDisks per engine)? Can Pure even virtualize external storage? What about 25% of the customer's CIFS and NFS capacity native on the VMAX? Or iSeries? Or zSeries? No, no, no and no. I wonder how many luns, max WWN’s Pure supports? Per port and per system? They really don't say. Unlike EMC which publishes VMAX's system maximums.

How many dual headed active passive Pure arrays it would to equal 25% of VMAX's resources? Like 16 TB of cache using the latest high-speed DDR4 memory? Or how about 576 of Intel’s latest Broadwell cores? Why doesn’t the 25% trade in count toward those things, after all they’re more expensive than capacity. Is it because 25% of VMAX resources is far beyond any Pure config that ever existed in a single array?

Customers buy VMAX for availability which is why many of them run SRDF, and many of those are synchronous and some run both synchronous plus asynchronous concurrently in 3 site configs. VMAX customers have been moving from Disaster Recovery to High Availability across data centers with stretched clusters and active/active SRDF-metro (RPO=0 & RTO-=0). Since synchronous replication is table stakes in the enterprise, I'm sure Pure will have a good road map story if asked about synchronous replication (along with some other 'innovative' stuff they're as if it were GA already). Not too sure what story they’ll spin if asked about active/active HA across two arrays and two sites though, as one may invariably ask, "If you could figure out active/active between two arrays across two sites, why can't you get off of your active/passive dual headed architecture that won’t scale and is common in the smallest of SMB shops"?

As for asynchronous replication requirements in the enterprise? Provide a guaranteed RPO (usually 30 seconds up to 5 minutes) with ZERO impact to production performance. Business Unit’s don’t express RPO’s in “Best Effort” or “We’re willing to sacrifice production response time, if the array can maintain anything close to a 5 minute RPO”.

Customers choose VMAX for DETERMINISTIC performance & RPO at scale. Not one or the other. Not best effort. And all at high utilization levels. VMAX customers don't consider 100% 4K random reads to be "performance". These customers don't want to manage balancing workloads across the heads and monitoring to see if they’re more than 50% utilized. Enterprises don’t want to be oversubscribed on performance and sacrifice application response time when a head failover takes place. Enterprise customers don’t want to worry about what the impact to response time will be for their critical applications when post process garbage collection, dedupe, etc, kicks in (which may run at various times and not during others, like when I/O picks up). They want consistent performance that they could plan for.

For VMAX customers performance means max throughput and max bandwidth at min response time. Performance is based on their hundreds or even thousands of enterprise applications' workloads running on the VMAX and not some script based on a DD or iometer in POC lab where the array is less than 40% utilized. VMAX shattered the SPC-2 benchmark at 55.6 GBpS (that's a big B, as in 55.6 gigaBYTE per second). How many of Dual Headed A/P Pure arrays would it take to get a consistent 55.6 GBpS? And is the answer based on the array being highly utilized? And were post process tasks like Garbage Collection running at this time, like they certainly will be in production? I don't know, as Pure doesn’t publically publish nor submit GBpS performance results to SPC-2, like EMC does with VMAX found here: http://www.storageperformance.org/results/benchmark_results_spc2_active

As for Pure being a true AFA and claiming that VMAX is a retrofitted hybrid array………….. Well, that’s just laughable. I suggest Pure read up on Orion, which EMC GA'd in 1987. It was an external solid state array with no disks with sub-millisecond response time (even all the way back then), the same sub-millisecond response time Pure is boasting about almost 3 decades later (at least when the workload is the right block size and the post process data services aren’t running on the dual headed active/passive SMB array).

Pure markets their Evergreen ‘Program’ to solve the problem of “Disruptive Fork Lift VMAX refreshes”. Seriously? VMAX customers enjoy and have been enjoying Non-Disruptive Migration (NDM), which allows them to refresh their VMAX non-disruptively (as the name would imply). Let’s say (for arguments sake) that a VMAX refresh was disruptive (which again it ISN’T), with Evergreen you’d have to take an outage today (to get on Pure) so that you wouldn’t have take an outage years from now (assumes Pure is still in business years from now). And even then, it’s blurry as to what you can upgrade based on your level of “Evergreen Subscription”.

On the //x “spec sheet”, in a 6 point font that’s very light gray colored text, buried at the bottom there’s verbiage like “post //X general availability” and “specifications are preliminary until GA”. So let’s be clear, is any of this even GA yet? Is pricing even available on the //x yet? Is it going to GA or DA? And when? If Evergreen’s Subscription is priced as a percentage of the //x price, then can anyone really solve for X? As in, if a customer trades in their current EMC array, they’ll receive 25% off the //x (but the //x price is unknown currently).

VMAX customers are pretty smart and put a premium on being available and stability (which is why they chose VMAX). I wouldn’t want to be the Pure Rep or SE that stands in front of an enterprise storage savvy customer and propose they swap the storage array they’ve trusted for years to run their business and cite “Fork Lift Upgrade” and “Evergreen” as the compelling reasons for wasting their time.

Now the real reason of the Evergreen SUBSCRIPTION should become apparent, it’s a great way to mask the fact Pure’s architecture is not built to scale up AND scale out. Unlike VMAX AFA where resources like CPU, Cache, front end interfaces can scale independently of the backend capacity. With Pure, when more capacity is added (usually by 50% capacity utilization if maintaining a consistent response time is desired), someone’s got more cleaning to do (e.g. Garbage Collection) and since the array doesn’t scale beyond a single ACTIVE controller and there’s a finite amount of CPU, the only thing to do is sell another array or hopefully the next generation of controller head has come out.

Evergreen is a good way for Pure to get desperately needed money now without increasing their costs of goods sold (as they’re basically selling nothing now). So who would fall for this “Evergreen Subscription” using today’s money for something that has absolutely no value on day 1, or year 1 or year 2? Someone who slept through accounting class when they covered “The Time Value of Money” and “Cost of Capital” and / or “Opportunity Cost” in Economics. And someone who doesn’t realize the price of storage deteriorates at ~20% per GB per year.