Commodity off the Shelf… Cheaper?

It’s an interesting thing that I’ve been seeing more and more – customers looking to leverage commodity off the shelf hardware and opensource software stacks. 

Personally, I LOVE this idea.   I think that “Software Defined” means that whenever you CAN do something with software on commodity hardware, you should (and have said this publicly for years – see this here: “Where the physical stuff that does work (data plane) can be software on commodity hardware, do it that way.”   Even earlier in 2012 here)

While EMC is associated “mentally” with big arrays dressed in “death star” black with kick a$$ Cylon LEDS (and we do indeed do that :-) like VNX and VMAX, we completely embrace the “software on COTS hardware” market – with ViPR and ScaleIO.

What HAS surprised me is how many customers say “I was software + COTS… but I want YOU to provide the COTS hardware, at COTS HW + Software economics and bundle it, and support it as an appliance”. 

It’s a little counter-intuitive, because by definition it narrows the hardware (from the whole ecosystem or all of OpenCompute options).   However, it makes sense when one thinks of many enterprises who lack the “bare metal as a service” organizational function that the Hyper-Scale folks have.   This resulted in things like EMC ECS (more here)

I got a really interesting email from one of my EMC SE colleagues yesterday on this topic (non-edited but censored to protect the innocent):

“I can totally vouch for the ‘Customer Service’ aspect for anyone wanting to run COTS.  Perspective might be useful…  My last role, I ran Development and Engineering for _________________ (service provider) – we got pushed into a bad place.  We ran a private and public cloud service for _____ (customer) internally, and for enterprises in EMEA and APJ.  Despite our awesome network, and DC’s, the support function was bulky, inflexible and stuck in the old ways.  Add to that a Product function that spent more time in ________ (a city) than where our market was….  Anyway the Product function wanted the lowest cost storage as was possible for the market in Asia – we deployed Supermicro kit, with ________ (a vendor SDS block storage stack) and ______ (a vendor SDS object stack) providing Block and Object.  On paper, it was excellent, well designed and it scaled, and worked well with Cloudstack and Swift (we were right in there at the beginning….).  On the balance sheet, we came in significantly less on the cost of EMC or NetApp – which with hindsight – I saw the EMC Sales guys do their best impression of a rabbit in headlights, before pitching the wrong kit – they didn’t understand SP’s back then.  (Ed: :-) )

Even then ‘Customer Service’ aspect we believed we had covered – the software was robust, designed with the Chaos Monkey in mind, we kept spares onsite in ____ (city in the americas), _______ (city in EMEA)  and _______ (city in APJ) – easy, right? 

If Ops staff could be consistent in following processes, they’d be engineers…  but they weren’t, they never followed process, never marked things, we ran out of spares, chasing SM for replacements, organizing pickups and deliveries, monitoring of the backend ended up with us having DC staff doing a floor walk every 3 hours – the bundled software was so unreliable. 

I ended up having ___________ (a vendor SDS block storage stack) hire guys to leave onsite in ________ (city) to keep their eye on operations.  It was a management headache, a support nightmare, and despite it being cheap to procure, and 99.999% uptime, we realized the issue was with our ‘success metrics’. 

What cost on freeing up my architects from chasing this nonsense, to doing ‘real’ work on the platform? We were ahead of the game in cloud – a flag bearer with _______ (one of the first mega IaaS offers), and this stunted our growth for 12 months while we sat on this and struggled to move forward.  Good architects ended getting frustrated and leaving – disruption, rehiring, etc.  All to save $0.25 per GB.  By the time we got back on track, we’d lost our technical edge in the market.

It is the reason why I always keep this picture (below) in my slide decks when talking about COTS – it is a great option to have, when you go in with your eyes open – and ECS is AWESOME.  I talk to SP’s all the time about it – COTS without the risk.”

Interesting… I would argue that EVO:RAIL shares the model with ECS as well – software + COTS hardware packaged as appliances.    There are rack-scale efforts down the hyper-converged paths within VMware (EVO:RACK) and EMC (still top secret) that also follow a similar path.

Curious for people’s thoughts of course!

Comments

[Wade O'Harrow]

Once again, well said my friend!
Just because you can, doesn't mean you should.
As somebody who has always tried to find ways to make great solutions scale, you undoubtedly already know that Scale at some point will eventually break everything. It's very interesting to see you point out that what broke with Scale in this case was not the technical solution, but the business operations capability.
More and more applications are pushing the need for platforms which not only need to be Dynamic, but Automatically Dynamic. Pointing to a future of rapid-scaling infrastructure, where COTS+SW capital acquisition economics are going to be balanced with the business operations issues tied to support structures of vendors.
The vendors who master this reality will have a market advantage over those who do not.

[Terafirma]

While I generally agree and am glad to see the changes at EMC I do wish it would flow to the greater company around the world. Essentially as a customer what I am looking for is COTS hardware (the knowledge it is standard and supportable with generally available kit and people) something I already know the value of. Then a software solution applied on top they can both come from the same supplier but I should have the choice. What I don't want to hear is software licenses tied to hardware appliances or frames. Hardware fails and needs upgrading so why do I have to re license? This is where EMC needs to change.

These are the times of converged infrastructure a path we have already been down and one COTS hardware was born out of. This is why I as a customer work to ensure I don't return to a hole were only just climbing out of.

The other thing I want is data in place it's 2014 and no software update should be destructive all that shows is inexperience and lack of vision in development, no way would my customers stand for that.

[Terafirma]

Hi Chad, A follow up to the last sentence in my last comment. This was nothing to do with the XtremeIO post (while timely) is born out of VNX and while EMC has done what they need too to help I am not sure it flows to partners (possibly out of fear of lost sale).

As a customer I am happy for work with a vendor as long as I am respected and stepped through a process, I understand innovation I have to do it for my customers.

To use the analogy of the car doing 200 mph while it is rebuild and replaced. If I have to change to new hardware (VNX -> VNX2) then the car is not being upgraded I have to climb out the window and into the new car while doing 200mph. Then following this I am told that my drivers license is not valid for this car (frame licensing) and must be re-purchased I get stuck in a decision loop of:

a. Need new features to deliver improvements
b. Existing kit was a large expense still need to get paid value form it

This is where I praise your efforts to get EMC to a software base with simple licensing of you want support or not.