Observation: the power of simple (but sometimes ignorant) arguments.

Preamble #1: Warning – this post is long-ish, and as usual a little rambly.

Preamble #2  While this post is indeed triggered by something specific (a competitor’s blog post targeting EMC trying to wrap in the “david vs. goliath” meme – a trope that is an easy one to rally around), I think it’s generally applicable. 

In fact, it applies equally often against things I see EMCers doing (at HQ and the field) – so I’m not aiming this at anyone specifically, but rather “all of us”.

I wonder if perhaps it is intrinsic and the reason there is so much FUD in high tech:  

• We wrap complex technological arguments, architectural pros and cons (which have a real basis) into short “bullet lists” so that the message carries broadly in the marketplace (and our field organizations/partners).  
• People blur technology passion (yeah!) into fanaticism (boo!).   This is very true in startups, single product companies, and specialists within portfolio companies like EMC (or any portfolio company)
• Twitter and social media exacerbates this by compressing everything in time and space – hence many Twitpiss debates I’ve participated in (and recently I’ve tried to recuse myself from).

There’s great danger in this (IMO).   The “dumbing down” of the masses is something that is disturbing on a fundamental level.  

I’ll put it to you this way.   In Toronto, one of the great global metropolises – we’ve had this buffoon for a Mayor.   Pretty well everyone in the world knows of him – but not in a good way.

 

Here’s the amazing thing.  He’s running for re-election… and he actually has a shot (!)  Sigh.

How is this possible?   He’s been a TERRIBLE mayor.   Answer: He’s powering himself with an ignorant, but simple message, and this sways the “low information voter”.   His message is “I’m here to stop any and all things that involve spending YOUR taxes”.   This is patently stupid.   The purpose of government is to wisely spend taxes in the service of the public good (and Toronto needs this – from public transportation, waterfront development and more).  

Look, I’m not naive.  Is there waste?  Yup.  Is there corruption in government?  Yup.  Those are both things to be stomped out – everywhere.

But this idiotic (but simple) meme he uses of “all spending = bad”, well it “carries”.  

When asked about all the drug stuff, he applies this principle of “keep the message simple, regardless of whether it’s stupid” principle to great effect, in essence always answering with “wasn’t me”.  Until it WAS evidently him, at which point he said “it doesn’t matter”.  All logic in the world suggests this shouldn’t work, but it does.

Moral of the story – people use simple messages because it appeals to the innate human desire in a complex world to “make things simple”, particularly when you are scared, or your brain is full.

There is an ongoing chorus from some inside EMC (and I hear it in VMware also) where people look at the portfolios and solutions sets and go “whoa – this is complex, I remember when there was less in our portoflio… we must reduce complexity”.   Perhaps.  Actually, in some cases, we surely must.   But – in other cases, we simply need our people and our organization to become more dexterous.  More evolved.  More sophisticated.

It’s not easy, but it’s RIGHT.

To quote a colleague:

“if the employees’ personal behaviour is not to be self learning, self discovering and, or have natural curiosity about our I no amount of training and videos will help.

We are a portfolio company with a vision of what IT is, will be, and the where for all to deliver on it.  We can't let narrow minded engagements effect our success or it's speed.”

There’s another clear evident example playing right out there in plain sight for all to see in high tech land.  

I remember it wasn’t a long time ago where literally I couldn’t have a conversation with a customer or analyst asking “when will you at EMC take the approach of a single kernel/software stack like NetApp, and don’t you think all things will move to NFS?”. 

Our answer then, and now: “it’s likely that while we will continue to simplify and integrate some our platforms which serve the ‘swiss army knife’ segment that ONTAP FAS serves (VNX), we see more and more demand for architectural stacks for built for purpose.  AFA stacks are different.   Scale-out NAS stacks are different.  The high end RAS stacks are different.  The object/HDFS on COTS stacks are different.  The hyper-converged transactional stacks (think VSAN/ScaleIO) are different.”  It’s a more complex message than “one architecture, always”.

In the past, I would constantly get a negative response to this (customers, analysts, partners) – perhaps because NetApp was growing and filling gaps in the marketplace.   It’s also human instinct to WANT to consolidate, to reduce, to harmonize, to simplify.   I DO think that we can (and are) simplifying each category, and working on abstracting/pooling/automating across archictectures…   But – at the time, people were buying the “ONTAP for everything” argument, hook line and sinker.

Today, everyone goes “well duh – of course one architecture for everything is silly!”.   Even Jay Kidd (NetApp CTO), who I respect a great deal, commented at the recent Wells Fargo Securities 4th Annual Tech Transformation Summit that he sees the need for architectural diversity, and that ONTAP simply won’t make the AFA space sing on it’s own.   Engenio is used as a low latency, high bandwidth stack today and Flashray is coming.   It’s clear to industry folks that NetApp some folks who really deeply believed this “one architecture for always and all workloads” are having a crisis of confidence.  Some have dropped one passion/fanatiscm and picked up another single focused story.  

There is no schaudenfraude in my heart on this state of things when it comes to NetApp.  In my opinion, they are in crisis, and I sincerely hope they can lead themselves out of it.  It comes down to leadership – years ago they could have put a stop to the fanatical passion around “ONTAP always” and started to broaden out – but they didn’t, and there’s no time machine.   The hardest time to change is when you are NOT in the crisis and everything looks rosy, but that’s when you need to do it.   They have strong leaders in folks like Jay and Tom G. and many dedicated passionate employees who will work day and night to navigate the change now.

Now, if NetApp are indeed a company in crisis, but I think everyone is to some degree.  I think in high-tech, if you’re not feeling in crisis, you’re in a state of delusion.  Andy Grove was right: “Only the paranoid survive”.   For EMC II (the storage/backup/security part of the larger EMC Federation of companies) our “crisis” (and opportunity) topics are these:

1. The transition of the AFA and hybrid markets.   And – years ago we made a decision: we must “flash enhance VNX and VMAX, but that’s not an ‘designed for purpose’ AFA”, and hence XtremIO.
2. The shift away from “consolidate workloads as much as possible” to “consolidate what you can, but embrace built-for purpose storage architectures (including COTS) where you see fit”.   And – we made a decision: continue to broaden the portfolio, place more emphasis on integrating UI, look/feel, APIs – and ultimately make the ViPR controller a top priority.
3. The shift from “mix and match” open systems to more and more converged infrastructure.   And – we made a decision: double down on CI in the form of VCE Vblock, VSPEX – and all other forms of converged infrastructure.
4. The increasing use of software-only stacks on COTS hardware.  And – we made a decision: we will drive almost all products to be available in software-only and appliance form, and we’ll organically and in-organically innovate in software-only storage stacks of all forms (see ScaleIO, ViPR Object, ViPR HDFS, vOneFS)
5. The movement of workloads off-premise.   And – we made a decision: a huge double-down on the object stores that serve huge swaths of this, driving to be the industries best commerical cloud-scale object/HDFS offering, and a general focus on helping SPs including vCHS.

One thing I will vouch for strongly – there is broad understanding and embrace of all of these things from the top to the bottom of the company, and while I’m sure we have bad spots (no arrogance or lack of awareness around our gaps!), there’s zero delusion amongst the senior/executive staff, and we’re investing to win.

So – what the heck was the latest trigger for this emotional post?  What is the most recent version of “everything belongs on NFS” or “one architecture always” that’s got me all wound up?  

Answer: The trigger was the “Hybrid vs. AFA” debates which rage, coupled with day of FUD slinging in both “AFA land” and “hyper-converged land” (I’m sure bi-directional – these things never are one-sided) and lastly a specific competitor’s blog post.   If you want my opinion (disclosure, I’m surely biased) read on…

I won’t do the dignity/insult of linking to the blog post that was the trigger, but I’m sure you can find it if you so desire.  

I’m sure that from the other side, they feel that they are being FUDed in return (and I can imagine it might indeed have happened).  I’ve seen internal EMC threads that echo my “simple ignorant arguments carry” observation.  People love battlecards.  People love “top 10 lists”.   They work.   Anyone that says they don’t have people advocating them/using them within their company is delusional.   Personally, I shake my head – and sometimes wonder if I’m tilting at windmills.   I do think it’s important to always try to elevate the dialog, and explain things simply -  it’s hard to do this without “dumbing it down”.  Many complex topcics don’t seem to “distill down”, and requires more mental investment.

Here are some specific observations – but warning, they are not in “simple bullet format”, and are absolutely my opinion (likely biased).   I respect my readers and ask them to think, reason, debate – educate me where you think I’m wrong.  But let’s raise the bar, not lower it.

NOTE: I want to keep re-iterating this point as people visualize “boxes”, not “architectures”.  The architectural statements below are true whether we’re talking about a software-only data services stack or a software/hardware appliance.   My point is to keep reinforcing that while there is a real customer/economic model difference in “software, bring your own hardware” vs “buy integrated software/hardware appliances”, but there isn’t an ARCHITECTURAL difference (in each of the given storage architectural categories).   Quick litmus test: 

• If you buy Nexenta as software, or as a pre-packaged appliance, is the architecture/core behavior the same?  YES. 
• If you have a vVNX, or a VNX – is the architecture/core behavior the same?  YES. 
• If you have vOneFS or an Isilon cluster – is the architecture/core behavior the same?  Yes. 
• If you have VSAN/ScaleIO and add your own hardware or have an integrated/packaged appliance – is the architecture/core behavior the same?  Yes.

Let the Q n’ A begin!

Q: What is the role of “traditional” high end storage arrays (think VMAX, HDS VSP) for transactional workloads in the era of All-Flash arrays?  Aren’t those “enterprise storage” platforms all about performance? 

A: Tightly coupled scale-out storage models (Type 3) in my “storage architectures” category that focus on “ultra consolidation” have not been the fastest (latency or IOps), or densest in a long, long time. 

If someone is trying to sell you up to a (or keep you on an) enterprise category array on the basis of pure performance alone, walk away slowly (I know some rare EMCers that still use this mantra, and if you see yourself in this, you **might be** a dinosaur).  

Things like VMAX don’t have a design center around the word “fastest”.  Their design point is this:  support a very broad set of workloads and host types very well, expect a lot of diverse workload consolidation, and do it in a way which focuses on Reliability, Availability, Serviceability (“RAS”) because by definition you have a lot of workloads consolidated - a lot of “eggs in one basket”. 

Things that compete with VMAX focus on very robust end-to-end availability, replication, failure behaviors.   They evolved during an era where the bulk of “dealing with IOps and performance” came from cache which fronted very slow magnetic media, and mastering cache behavior with mixed workloads was of the essence (and therefore have shared memory models at their core).   They are evolving quickly to shift to more and more of a flash mix.   They are coupled with support models that are very “white glove”.  They are mature – and by definition perhaps – complex (this tends to come with being very feature rich).    If you need low latency, dense, cost effective IOps, and are looking at a focused workload (rather than a single platform that does everything you might need moderately well) – but don’t need these very high-end RAS data services, in the EMC portfolio the strongest answer is XtremIO, not a VMAX.

Q: If “high end enterprise arrays” aren’t the “performance kings”, why would EMC have XtremIO and VMAX in the portfolio then?

A: This is one of the arguments in the blog post I read from the competitor that was a trigger for this long post.  It’s a silly argument that only “stands up” for someone with a single-product worldview (if the customer doesn’t fit, they don’t exist).   This is the epitome of the “power of simple (but sometimes ignorant) arguments”.   A single sentence triggers this long blog post on an airplane :-)   It’s also illustrates how silly “talking points” lower the average intelligence in the debate.

The answer is implicit in the above, but I’ll spell it out (because some seem to have trouble here).  The answer is NOT about performance-centric transactional workloads.  The answer is for transactional workloads that have specific, and very high-end SLA and RAS requirements (data services), particularly when blended with other workloads that target lower $/GB scenarioes.   Here is an example:

I recently visited a customer that has a lot of VMAX (and some HDS).  They primarily support transactional Oracle workloads.   They wanted to move forward with a refresh of their “stack” (while they also explore next-gen in memory data models and a next gen application stack), and determine how they could get a lot more dense, more IOps, lower latency.   I started to work down a design using XtremIO with them.   Very quickly, it became clear as we did solution discovery together that they needed things like T10DIF (end to end integrity model from the Oracle stack down through the storage layer).   They needed things like hundreds (in some cases thousands) of remote replication sessions – some synchronous, some async.   There is currently no AFA in the world that is a fit for this customer - none.  The closest thing would be XtremIO fronted by VPLEX and Recoverpoint (which supports huge replication loads, thousands of devices and consistency groups, all sorts of topologies) and even that wouldn’t meet the requirements.

For that particular customer, the answer is “what are we doing in the VMAX roadmap to support denser flash configurations, more system IOps, changing the architecture to support many more IOps per storage engine, and changing the caching algorithms” (in other words, we need to do for Enginuity what we did with MCX on VNX).   There’s great things going on here, stay tuned.

So, if there’s great stuff coming for “more flash” and “dedicated flash pool economics” on VMAX, why XtremIO?  

The answer is that you live and ultimately die with the design center you’re born with.   Pick your bad metaphor: “If you’re born a cat, you don’t die a dog”; “If you’re a leopard you don’t change your spots” (this is why you should BEWARE anyone saying they will “bolt on” scale-out, or “inline dedupe”, you MIGHT be talking to someone dangerous :-)

VMAX, like VNX has a “mixed workload” design center.  This means that they need to support more and more flash proportionately – but at their heart, they are hybrids.    They assume you will turn around and ask them for:  “I need a $1/GB transactional tier”; and then turn right around and say “I need a $0.5/IOps tier”.    They expect some block, some NAS.   But think back to that customer and why the want to keep that workload on VMAX – it was for the RAS behaviors and RAS data services (and other operational factors – which are material) – not the “all flash configuration” per se.   If these RAS requirements were not a hard customer requirement, we as EMC would be doing them a disservice if we didn’t actively cannibalize the workload from VMAX to XtremIO.  

If you are a customer reading this and feel like you’re getting pushed into VMAX on “performance” centric arguments push back.   If you’re an EMC rep or account SE reading this and you are “protecting” the customer on VMAX, you are doing them a disservice.  

Likewise, if these RAS requirements ARE a hard customer requirement, we as EMC would be doing them a disservice by pitching XtremIO, or a flash-dense VNX (which has much better $/IOps and $/GB values than a VMAX) – and rather should build a solution about a VMAX with a dedicated Flash Virtual pool.

If you are a competitor who would ram an AFA without meeting these requirements down the customer’s throat, I would argue you would also be doing the customer a disservice.   But hey, if you only have one thing to sell, it’s a zero sum game, so I suppose you would sell around the requirement – damn the customer.

Q: Hybrid vs. AFA – which is better?

A: Facepalm.  This is the first example that echoes the stupid (utterly wasted time!) debates over the years over protocols (usually driven by “block-heads” or “NAS-nut” fanatics who really need to find something better to do with their time).   Answer on “Hybrid vs. AFA” is: “it depends by customer”.   We have hundreds of thousands of customers who depend on a small VNX to do almost everything (NetApp has similar for FAS platforms).  In this type of customer, this is what they typically ask their infrastructure to do:

• They usually have one, maybe two datacenters – so “small” matters.
• Support NAS  (with rich enteprise NAS features), Block (iSCSI, FC, FCoE) and object (for content/archive use cases mostly) models.
• Support everything from all-flash pools with 1ms latency and huge IOps, to huge dense (think 240TB per 4U with $/Gb in the $0.5/GB range), and everything in between (and therefore expect auto-tiering like FAST, and things like FAST Cache).  They expect dedupe, compression, snapshots, file-level operations, tight AD integration (and a very, very long list).
• Support B2D because they use might use the dense-low cost tiers as a B2D strategy because they can’t justify purpose-built backup appliance (which Data Domain leads as a category).
• Support super-rich integration with a very, very broad ecosystem of enterprise applications (Exchange, SQL Server, Oracle Enterprise Manager, SAP, etc) mangement tools and frameworks.  (vCenter/vCOPs, vCAC, Openstack, Puppet, Chef, SCOM)
• Hyper-integrate with vSphere, but also with Hyper-V and hey, the physical hosts they have as well.

In other words – they need a swiss-army knife.  The VNX product team may get angry at me saying it (they shouldn’t be angry be – this is a great category, one they proudly rock at!), but this category is defined not about doing any ONE thing super awesome (specialization), but doing a decent job of of all sorts of different things (generalization)… and doing it in packages that are simple, and start small.    Yes, VNX gets placed into many of “Tier 2” use cases in huge customers.  Yes, it gets used for high bandwidth workloads like backing Lustre and HDFS.   That’s not it’s CORE design center.  It’s core design center is to be the best swiss army knife storage thing.  It is a “Type 1” clustered architecture that is a hybrid is to be “decent (hopefully more than just decent) at many, many things”.

Is there ANY (literally ANY?) AFA which could do all of the above?   Bueller? 

This highlights the insanity of the “one architecture always” passionista world view.  I get digging your tech and being passionate (this happens in our specialist SE teams who focus in one area or another).  It’s part of doing your job well.  within our Specialist SE team, they subscribe to the Manifesto principals, but also the “right solution, all the time”, which means that in spite of their focus, we WANT them to say “no, this isn’t the right thing for this widget”.

For some customers it makes sense to have a VNX for the NAS workloads and a AFA, and in those cases – the right thing to is to build a solution using both.

If the description of a “general purpose” “do it all” hybrid isn’t what the customer needs, or if they are ok with non-integrated/bolt on NAS, or if they don’t need all the degrees of application integration, or if they don’t need dense capacity use cases – then they can use just an AFA.

Likewise, if these requirements ARE a hard customer requirement, we as EMC would be doing them a disservice by pitching just a solution using XtremIO, and should build a solution around a VNX with a lot of flash in pools and as Flash Cache.

If you are a competitor who would ram an AFA without meeting these requirements down the customer’s throat, I would argue you would also be doing the customer a disservice.   But hey, if you only have one thing to sell, it’s a zero sum game, so I suppose you would sell around the requirement – damn the customer.

Q: Scale out vs. Scale Up – which is better?

A: Facepalm #2.   There’s one basic litmus, and then it gets detailed.  Basic litmus test: if the performance requirements of a single LUN/filesystem/VVOL exceed that of a single “scaling unit/brain” (everyone does this differently) then you need a true scale up system, where true means that the front end IO is dispersed, the brains are dispersed, and the data is dispersed.   BTW – IMO, if you can “scale up”, but a SINGLE host/LUN/filesystem doesn’t scale up – then it’s trapped in a scale up system “feigning” scale-out (usually through some federation/management).

There are other much more variable aspects of this (scaling performance linearly, management complexity as you scale, etc).   There are other topics too – which are the “failure modes” of scale-up systems, which is the next question.

Q: Passive-Active, Active-Active, and Scale-Out – what’s right?

A: This is an area where so much has been changing, the traditional “categorization” of storage design don’t reflect where the new ones land into precise buckets.  Historically, you had “active/passive” systems and “active/active” systems. 

But… What do you call a dual controller architecture where you have an active-active device presentation model (not ALUA – all ports are active), and you ensure the customer doesn’t drive the system past a total of 50% utilization?  Is that an “active/active model” (I would say yes).   BTW – If you think I’m going to name the other guy here, I won’t :-)   That’s a VNX (and some of the other hybrids and AFA players)   Today, the VNX can behave exactly like that for FLUs (basic LUNs).   In the future, that architecture will be able to do the same for rich data service devices (DLUs and TLUs).  

In the VNX case, you CAN drive it past 50% utilization, which means you can have impact during non-disruptive upgrades (NDU).    I’m of two minds on whether we should “restrain” the users from driving past 50% SP utilization (it’s certainly a best practice) – this is critical because when an SP fails (or is upgraded), there’s a period where a single SP is carrying the system load.   These days, modern VNX platforms have a lot of horsepower… But, there’s always a customer who hurts themselves by driving the system to 90%, and then during an NDU upgrade, sees the system performance hit a knee.   There’s an argument we should limit, or restrict the user some how.   Some customers dig this “safety feature”, some absolutely detest it.  

There’s one other thing… Without bending over backwards, the back-end bandwidth (not IOps, not latency, but system bandwidth) is not totally symmetrical in the scenario I describe.    While it’s “active active” on the front end for a given device, all the IOs are going out one backend.   This is how it works on a VNX.   I **SUSPECT** that this is how it works on the other guy – but I would read their blogs and specs to learn more.

Now – IMO (**IN MY OPINION!!**) there is a world of difference between that and a scale-out system in failure behavior and scale-up system behavior.    But – I would be more curious for YOUR opinion.  Is the failure of a node in an 2-node active-active scale-out system (front to back – front end ports, back end connectivity, brains – everything) the same as a 2-node active-active scale-up systems (not completely symmetrical from front to back)? BTW – I tend to think “yes”, but think that the steady-state envelope is not the same…   Do you think the difference is more material if it’s an 8-node system?   What’s the right nomenclature here for this new thing (“not entirely symmetrical, but active active”)?

Q: Is it true, Chad, that you’ve publicly said that the AFA valuations don’t reflect the “total addressable market”, and that we should see some fall out amongst all the new players?

A: Yes, and BTW, I don’t view this as FUD.  I’m NOT suggesting that the AFA market TAM is somehow “limited”, or “don’t trust startups!” (heck, I came from one!).  Rather I think it’s reasonable to say it’s something like $1.6B-$2B of AFA market in 2014, with the big players doing north of $100-$200M in revenues (though only some are break-even on profitability).  In that space, EMC are of course working hard to extend our share leader position. 

Over the fullness of time – this TAM will continue to expand as AFAs continue to mature, add more data services, flash economics continue to change and broaden economic envelopes.

My observation about “AFA Armageddon” is that the market valuations of companies that are loosing money (without a very concrete plan on how to shift into profit mode), in a highly contested/competitive market (which is only getting more competitive, which means cost of sales/marketing goes up not down)… well, it’s a recipe for: step 1)  bubble; step 2) fallout; step 3) a period of “Armageddon” were the capital markets will dry up and get very hard for AFA startups – versus the easy state that exists today. 

IMO – this applies to Box and the sync n’ share space as it does to the AFA space.   The market (and analysts) tend to “froth” a little bit (and sometimes more than a little!)

Now – beyond broad Q n A, let’s talk about one AFA versus another.

I’ve shared in the past what EMC thinks (and I agree with) are key critera for a true AFA (versus a hybrid which is really good at lots of flash). I’m SURE some out there disagree.  It’s up to customers to decide what is important for them.

• You’re looking at an AFA because you want a simple, low latency, dense, IOps centric persistence layer.  So:
  • It’s really important that your AFA choice has behavior that meets those criteria (including the operational simplicity element – which is material).
  • It’s really important that your AFA choice meets those criteria under a broad set of circumstances and workloads.
  • There are real world scenarios where a single device exceeds the capability of any of the non-scale-out AFA’s out there.   This isn’t everyone – it’s rare to need more than tens/hundreds of thousands of IOps for a single device, but if it happens - your choice is either use a scale-out design, or do some sort of host-side LVM/ASM.   One of the reasons we acquired XtremIO was that it was one of the only architectures (only still?) with a full end-to-end symmetrical scale-out design (any port, any brain, any persistent layer).  Our experience has been that fundamental architecture wins over features in the mid and long term.
• You expect the latency and IOps behavior to be predictable, since after all, that’s why you are chosing the AFA in the first place.  So:
• If you were ok with some latency variability, you would use a hybrid with a little flash, FAST VP, and FAST Cache, which delivers a broader set of functions/application integration/NAS, etc – and of course things like B2D and archive targets too.
• Latency variability under various conditions is not FUD, but a real industry thing. 
• Customers can determine for themselves what they think is “reasonable” testing.  We point to the IDC AFA testing framework (click on the below) not because they fit us particularly well – but rather they correspond with what we think is actually healthy.

• I will tell you that IMO a quick light load without pre-filling the array with data, then loading your workload, churning the data over a period of hours/days is NOT accurate (though fast and dirty) and not reflective of real-world.  
• This isn’t about ANY one vendor.  Through our M&A process, I’ve seen a TON of flash stacks of all types.  They ALL have to deal with flash media’s inherent characteristics in some way – and the differences are real and material.  Some handle it well.  Some not so well.  Some, well, really not so well. 
• SLC, MLC/eMLC, cMLC, and TLC all have different targets in writes/day cycle targets.   It’s not about the media per se being “good” or “bad” – or even the media as the main point - but rather the overall system envelope and behavior.   This is due to the fact that every AFA software stack and architecture targets a specific way of dealing with this inherent flash media characteristic of garbage collection and limiting write amplification.
• The economics of AFAs is dominated by the cost of Flash media still (and will be for some time to be sure), which means media type, and density matter, but the topic of what efficiency data services are offered and how they are implemented is material.   So:
  • In our view, the key is that if you can’t COUNT on the dedupe (and in the future compression) always to be inline, and always there, it makes it really hard to count on as a critical part in the economics.  If we were to add compression (which we will), and if it’s an inline but not always on behavior, you’ll see us note the capability but we won’t be as pointed about it’s effect on the economics – precisely because it won’t be something that can be DEPENDED on.
  • To help with this point, I’ll make an example many people understand.   NetApp clearly innovated and lead on the primary storage dedupe function (in our industry invariably each of us are first on one thing or another) – but like many of the other very feature rich, flexible hybrids that now have this feature now (VNX as an example) – this is a post-process, and operational constraints and considerations.   People using these have said clearly “thank you, this is great, but I would love it to be inline/always on – kind of like how Data Domain does it for backup to disk streams… If it doesn’t – it’s a great bonus, but I can’t count on it always”.  Answer – with these AFA stacks, and unless inline, always on dedupe is designed in on the front end, it’s nearly impossible to add after the fact.
  • While some out there suggest that there is a “XtremIO with dedupe off”, I’ll say it firmly, and loudly – dedupe on XtremIO is global (across all nodes in the cluster), and ALWAYS on.  It’s not a feature, it’s an architectural property.   EMC will stand behind this firmly.

Lastly – I really encourage everyone out there to push back on people who talk about what vendor A does or doesn’t do.  Personally, I’ll always try to focus on what I think we do well and how we help customers.

I have a great deal of respect for all the other startups out there.  If they think we as EMC will put a shoddy technology in the hands of our customers – well, let them think that.  If they want to caricature us as a slow-moving “goliath” – well, let them think that.   Reality is that for ANY individual customer choice there is no “david” no “goliath” – everyone is equal – there is no big, no small.  

If you are one of the many hundreds of thousands of happy VNX/VMAX customer supporting transactional workloads and think that some of your workloads would be better served on all-flash, talk to your EMC team and EMC partner.   They should NEVER “play defensive” or “protect the base”.  

If your support team is “playing defensive”, or not bringing the full portfolio to bear, please comment/email me directly with their info.   This defensive posture doesn’t reflect the EMCers that I know.   EMC is a portfolio company.   It requires more sophistication, more finesse from our field team than being a single product company – but there is NO room for people who don’t know the portfolio, use their specialist support teams and partners to build the right solution.  

The EMCers I know are always looking at “what’s the right solution we can build for a customer” – and frankly we’re pushing those hardworking field folks and partners to think far, FAR beyond the storage/backup layer to think about SDDC, think about PaaS and Data Lakes and analytics.

To customers – I would suggest that your parnters should support you and bring a broad portfolio of solutions for transactional persistence layers:  

• The answer may include one architecture we didn’t talk about which are transactional SDS stacks with servers loaded with flash (think ScaleIO clusters co-resident with compute doing 5M IOps with >1ms latencies, per device QoS, snapshots and more).  
• The answer may be a dedicated (non tiered) flash pool in your VNX Hybrid that is placed in multiple duties.   The answer may be a dedicated (non-tiered) flash pool in your VMAX Hybrid that is placed in multiple duties.   
• The answer may be an All-Flash Array.

If the answer is the AFA category, XtremIO is on version 2.2.   It is GA, and has the full support of EMC behind it. 

It is now the volume shipment AFA leader in the industry, and a ton of happy, referenceable customers if you want to talk to someone (always smart).  

If you need an AFA with the industries richest local and remote replication and active-active model – XtremIO with VPLEX and Recoverpoint is very compelling.

The XtremIO team is working very hard to keep up their rate of great innovation and delivery, we listen to what people love, and what people want more of - and will keep bring additional things XtremIO doesn’t do today.  EMC World is right around the corner :-)

Stay positive friends, and let’s be a force for good!

Comments

[Trey Layton]

Well said Chad!

[Cris Danci]

Well worth the read. I think you’ve hit the nail on the head. Everyone depending on the flash technology wave is pushing flash from a product centric viewpoint as the solution to everything. Realistically it’s not; it’s just another component that we use to design systems to meet requirements. Systems designed without other considerations other than ‘fill it will flash’ to gain performance will be short lived and in the long term AFA are likely to only like address specific use cases. This will become more apparent as we mature from application development perspective. At the moment most applications are designed around traditional programming constructs and frameworks, designed to service a limited users base and are tightly coupled - designed to run on dedicated resources (with some consideration of virtualisation and short distances (loosely coupled clusters) because of this scope. As the shift occurs with application consumption (we are already seeing this in mobile markets) it will forces development to mature and this maturity will evenly change everything. Applications will be designed on mature programming frameworks to address a large user base on a large/global scale. Applications will be designed around systems that operate on shared pooled resources and they will be highly decoupled (this is why PaaS->SaaS is the future). Such applications will have vastly different performance requirements and characteristics. Simply backending a system with a faster version of an existing component will fail miserably.

[Kartik]

My favorite quote on the perils of simplification:

"For every complex problem there is an answer that is clear, simple, and wrong."
- H. L. Mencken

[DennisFaucher]

Chad, thank you once again for being passionate plus reasonable plus objective. Those qualities can be hard to find in IT and are exactly what our customers need and respect. Thanks also for the chuckle at the TwitPiss term.

[virtual geek follower]

well said! thanks for the great read Chad!

[CentralMidTier]

Soild. EMC is a storage portfolio company with a product for EVERY customer, not just specific workloads. Oh, and would class service and support.

[John Lavallee]

Thank you Chad! This emotionally charged and COMPREHENSIVE blog is greatly appreciated. For years your blogs have been a welcomed part (and cornerstone) of my technical "EMC Education" and this one is right up there with other gems you have shared over the years. Thank you for taking the time to go into such detail.

[Andriven]

What's this vVNX you speak of? ;-)