Storagebod Rotating Header Image

Tiny Frozen Hand

So EMC have finally announced VMAX Cloud Edition; a VMAX iteration that has little to do with technology and everything to do with the way that EMC want us to consume storage. I could bitch about the stupid branding but too many people are expecting that!

Firstly, and in many ways the most important part of the announcement is around the cost model; EMC have moved to a linear cost model; in the past, purchasing a storage array had a relatively large front-loaded cost in that you have to purchase the controllers etc; this meant that your cost per terabyte was high to start with, it then declined and the potentially rose again as you added more controllers and then declined again.

This led to a storage-hugging attitude; that’s my storage array and you can’t use it. A linear cost model allows IT to provide the Business with a fixed cost per terabyte whether you were the first to use it or last to use it.  This allows us to move to a consumption and charging model that is closer to that of Amazon and the Cloud providers.

It is fair to point out that actually EMC and other vendors already have various ways to doing this already but they could be complex and used financial tools to enable.

Secondly, EMC are utilising a RESTful API to allow storage to be allocated programmatically from a service catalogue. There are also methods of metering and charging back for storage utilisation. Along with an easy to use portal; the consumption model continues to move to an on-demand model. If you work in IT and are not comfortable with this, you are in for a rough ride for quite some time.

Thirdly, the cost models that I have seen are very aggressive; EMC want to push this model and this technology.  If you want to purchase 50Tbs and beyond and you want it on EMC, I can’t see why you would buy any other block storage from EMC. It is almost as if EMC are forcing VNX into a SMB niche. In fact, if EMC can hit some of the price-points I’ve had hinted at; everyone is in a race to the bottom. It could be a Google vs Amazon price-battle.

Fourthly and probably obviously; EMC are likely to be shipping more capacity than an end-user requires, allowing them to grow with minimal disruption. If I was EMC, I’d ship quite a lot of extra capacity and allow a customer to burst into at no charge for a fair proportion of the year. Burst capacity often turns into bought capacity; our storage requirements are rarely temporary and quickly temporary becomes permanent. Storage procurement is never zipless; it always has long term consequences but if EMC can make it look and feel zipless…

I’m expecting EMC also to move to a similar model for the Isilon storage as well; it is well suited to this sort of model. And yet again,  this leaves VNX in an interesting position.

Out in the cold, with a tiny frozen hand….dying of consumption.



  1. Charleyp says:

    You mentioned “There are also methods of metering and charging back for storage utilisation.” Are you describing some sort of product that handles chargeback modelling?

  2. Chad Sakac says:

    Disclosure – EMCer here.

    ‘Bod – as always, a great perspective. May I suggest, however, that like everyone – you see the world through your eyes, your experience. You are at a HUGE shop.

    Don’t underestimate the market need for things in the sub $100K band, for things that are only a few U not a few racks. This are things that often also exist within large enterprises, but perhaps not in the core datacenter. Ultimately, this market for “swiss army knife” or “utility storage” that isn’t perfect at any one thing, but really good at many things is the market that VNX, and for the most part NetApp FAS serve. And it continues to grow, and there is continual innovation (expect more shortly).

    That said – I think your POINT is right – I’m only disputing the, shall we say “dramatic” conclusion 🙂

    At large enterprises like yours and service providers – there is a tendency towards things that have a scaling model, economic model, and architectural model that looks more like VMAX Cloud Edition and Isilon than like “lots of swiss army knives”.

    There is another factor at play too – Keith Norbie wrote a blog on it here:

    Abstraction layers that automate underlying stuff (think Openstack, think VMware’s SDDC plans) are also a pressure towards “have a couple purpose built things that are automated, rather than a couple sporks that are automated” (i.e. have a VMAX Cloud Edition, VPLEX, Isilon, DD under an automation layer that controls placement policy). Again – this is true in my experience – but it forgets the “yeah – what if this thing is the ONLY thing I need (and have budget for).

    I don’t think this is SMB – I think it’s a much bigger set of customers and use cases than that.

  3. Martin Glassborow says:

    I think VNX continues to exist to keep some kind of differentiation for EMC’s offerings. I believe that it would be possible to build a VMAX Compact Edition which would serve the market that VNX supports and an Isilon Integrated Appliance which would give it the file services. I don’t think that is a huge stretch for EMC’s engineering teams. And I think it should be possible to do this at a very attractive price point.

    So I reckon you could build a better Swiss Army Knife…

  4. […] (Martin Glassborow) who is an architect at a very large enterprise chimed in with his opinion here.  It’s worth checking […]

  5. Disclosure – EMCer (and one of your fellow EMC Elect) … and the EMEA lead for VMAX Cloud Edition. 🙂

    You are, as ever, the honest and forthright ‘Bod and for that, no one could ever fault you. And if they try, point them my way … I’ll happily have a robust conversation with them.

    Now … a very interesting point you make (several, actually) about ‘very little about technology and more about how EMC want you to consume storage’ … well yes, and a big NO.

    Yes, it isn’t about the ‘nerd knobs’ of traditional storage balancing and perf tuning as, well … we’ve automated that for you and made it orchestration ready via REST API. Not that’s there anything wrong with someone wanting to be under the bonnet fine tuning every last widget, TDAT, BIN file, and engine harmonisation … but /*most*/ people would like to dispense with that and get to how the technology benefits the business and so I would describe VMAX Clou Edition as a business solution powered by EMC technology. No house points for giggling at my marketing speak, I honestly believe this to be true.

    NO, it isn’t how EMC want you to consume storage … it’s how EMC customers have stated (often quite loudly) how they want to consume today, tomorrow, and twice on Sundays. ‘Give me price per gig, predictive performance against the price, and an ability to ‘dial up, dial down, dial in’ the service bands. So we did. We listened. And VMAX Cloud Edition is the first result.

    The remainder of your blog had me smiling from ear to ear … then abruptly saying, ‘Erm … not quite.’

    Would that everything a conspiracy, we would just be able to listen the the conspiracy theorists and then avoid the places/things/people they tell us are conspiracies … although I remain unconvinced I’d look fetching in a tinfoil hat.

    There’s a reason why there is a broad portfolio in EMC, and I have to respectfully disagree with you just now on pushing VNX into niche SMB via the emergence of VMAX Cloud Edition. If anything, the emergence helps to more clearly define the use cases for each platform.

    What if I don’t want/need the horsepower of a VMAX for a remote site? What if I want multi protocol support? What if I don’t want to reinforce my ageing datacentre floors?

    If any thing, one could make a strong argument for linearising other areas of our portfolio to continue to help customers more effectively solve the cost to serve not just a cost to acquire before we look for any supposed strategy of killing or marginalising VNX.

    As for your challenge re building a better Swiss Army Knife … I’m all ears. How would you have done it? 😉


  6. Martin Glassborow says:

    I’m currently very much of the opinion that dual-head-traditional-storage-arrays must die…VNX was/is a great product but the scale-out model is simply better. The ability to scale my storage across the various axes can be much better met with scale-out. And I’ve yet to come across anyone who is not increasing the size of their estate, refreshing their storage and coming across corner cases which might be better met by a slightly different model. The flexibility of scale-out means that I can meet nearly all my demands with a single array with little compromise.

    You talk about horse-power, you talk about reinforcing floors; build a lighter and less powerful VMAX. There’s a VMAX virtual appliance…okay, it has a stupidly large memory foot-print…I’m sure that can be resolved and memory is coming down in price. I can’t believe that even the current ‘baby’ VMAX has manufacturing costs very much above a VNX. And are you telling me that you couldn’t run a virtualised Isilon appliance inside a VMAX and provide multiprotocol support? And with the exception of Ficon; there is nothing that a VMAX does that any IT shop would not want; apart from a few edge cases, if you were given the choice and all costs being equal; you’d take the VMAX.

    There is no conspiracy theory, I just think you’d be mad not to consider simplifying your engineering effort.

    As for building a better Swiss army knife; if you look at a Swiss Army knife…they are pretty much all built on a common design basis. Then you start layering on top of that; I’d start by building a common storage platform…then building on that. I’d obviously make it a scale-out; I might even make it a scale-out which started with two engines. Three is better but two might be enough to start with.

    And I absolutely understand why you’ll all sit there with poker-faces saying that VNX has a long healthy future….HP said the same about EVA. But deep-down in your heart of hearts….how many really believe it?

Leave a Reply

Your email address will not be published. Required fields are marked *