What is the real thing stopping “Cloud in the Enterprise?” - RANT.

I firmly stand by “EMC SE Manifesto Principle #5”:  We are positive force.   Meaning “We think of the customer, our ‘tribe’, ONE EMC, the community at large, the world - and never go negative on the bad guy.”

Rants tend to be negative, and tend to break with this principle, but I have to get something off my chest.

I’ve met what’s stopping “Cloud in the Enterprise”.   Answer is: US – as in all of us.

If you’re an IT dude or dudette – this may make you angry.  I kind of hope so.

When I was in Sydney a couple weeks back – I had a ton of discussions with customers who were looking at Public Cloud options (Aussies tend to be early adopters of service-centric economic consumption models), and I was: a) encouraging them, and sharing examples, best practices and learning; b) asking why they weren’t looking at other workloads for cloud consumption models.

When I asked them why they were looking at Public Clouds, and for what workloads, they were all over the map.   The most common answer was wrong, which was: “because it’s cheaper”.   More rarely was it a “correct” (my opinion here) answer of: “it’s more agile than we are internally”, or “it gives us economics transparency that we can’t seem to get internally”.

Let me state this categorically: Amazon Web Services (and said more generally Public Cloud) are not “cheaper” than Enterprise IT for most enterprise workloads.    This is true even when compared with ‘Bad’ Enterprise IT.  The economic sweet spots of AWS today are workloads that are “compute high, storage low” and “variable load”.

If you think I’m high as a kite, or that it’s simply a matter of “economies of scale” – read on past the break.

Does my categorical statement sound hyperbolic?   It’s not.   Look, part of what AWS and other public/hybrid cloud options like the vCloud Hybrid Service folks give you is some clear transparency, and that’s useful here.   Check out, and take the next few minutes fiddling with the pricing calculator: http://calculator.s3.amazonaws.com/calc5.html   I’m curious whether I’m making a gross error somewhere (possible) -

What do you find?   Well a few datapoints for those too lazy to explore:

• a 50% utilized medium (2 vCPU ~4GB RAM) Linux EC2 instance is about $44/month.
• that same 50% utilized medium EC2 instance when using Windows is about $67/month.

Now – here’s the first thing – humans are bad at math.  That $44 example is about the AWS sweet spot right now, and translates to $528/year, or over a 3 year period (the “normal” TCO period) is $1584.    That’s pretty good.    (BTW – for those of you in different parts of the world, try different regions – they have different pricing models).

I mean, a moderate rack-mount server with virtualization could run about 10 of these, and would cost somewhere around $20,000 (including the RHEL enterprise + support, or vSphere licenses).   It also doesn’t factor in the cost of capital (i.e. you have it on your books, and that has some cost) or the more squishy “opportunity cost” represented by elastic pricing (i.e. that’s money over a 3 year period you could use somewhere else if you decide later you don’t want it there).   And of course – it doesn’t include the fact that the server consumes space and HVAC, and requires an IT opex cost in the humans to set it up and maintain it.

Try this next.     Let’s assume we take that “sweet spot” VM, and add the equivalent of 1 – count ‘em 1 – NL-SAS spindle of capacity and performance.   Add in the EBS column a 300GB EBS Standard 100 IOps EBS volume, and let’s say 20% rate of change, weekly snapshots.  What happens?  

The price increases to $141.  Try different values – for fun.   An interesting sidebar…  The difference between “standard” and “provisioned IOps” is that “provisioned IOps” is apparently provisioned to “Deliver within 10% of the provisioned IOPS performance 99.9% of the time in a given year” 

What is the moral of the story?   EBS is expensive relative to “classic storage economics”.   The other moral of the story is that once again – humans are bad at math.   If I tell you the following:

“$0.10/GB/month, and $0.10 per million IOs served” – that sounds pretty low-cost, right?   How about if it’s with an overall 99.85% availability?   That sounds pretty good, right?

How about if I tell you the following:

“$0.05/GB/month, and $0.04 per million IOs served, with an availability profile of 99.995% ” – that sounds even better right? 

Well – that’s the rough back of the napkin of a moderate VNX configured with NL-SAS, using iSCSI and NAS (EBS doesn’t use FC :-) and light on additional features (but still with the essential software stack), at list prices, on a 3 year TCO model.   Yup.   A VNX, at list pricing bands is about half the cost of AWS EBS or S3 – even at low scale.  Oh, and smokes it when it comes to performance and availability.  The same is true of VMAX Cloud Edition.

What!?!?   Well – all I did was express a VNX in utility terms instead of capital terms.  That’s a real difference, to be sure – but it’s fascinating when you compare apples to apples.

BTW – S3 (which is lower price than EBS) is still far more expensive than a VNX – which I’m sure competitors will pile on this post all claiming to be even better :-)

What about the fact that S3 (and EBS, EC2 and the other PaaS AWS offerings) are continually lowering their prices?  Look at S3 – it’s dropped about 17% per annum!   Yes, and the cost of on-prem storage has been dropping at 20% per annum too.

Oh, and BTW – all of this didn’t include any network ingress/egress costs.

So – what’s the point?   The point is that with the AWS cloud model you get something that is a REAL, AND MATERIAL value proposition, but with the exception of the “compute heavy, storage light” loads (think transcoding like Netflix, or MapReduce with small datasets, or HPC with small datasets) – it’s not about being “cheaper than IT”, it’s about:

• Being more agile than traditional IT.
• Being more elastic economically than traditional IT.
• Being more more price transparent than traditional IT.
• Being more “frictionless” than traditional IT.

So – the question of the day then becomes the following:   A) What is the place for traditional IT?; B) Can IT get out of it’s own way and be more agile, more elastic, more economically transparent and more “reduced friction” than ever before?

My answers:

• The place for traditional IT?   IMO - Internal IT are shifting to be more of “IT services brokers”, and less about “operators”.   This is why we need more cloud architects. 
• Enterprise software that is relatively standard is moving to SaaS as fast as possible – and that’s inevitable and good.
• Community Clouds are being built that target different workloads and different envelopes (performance, application, security, economics).   There’s a cool example of one built for the finance vertical – NYSE Technologies.   Think 7 Million updates per second, billions of transactions per day.   Click on the link below for the NYSE Tech example in their own words (and those of their own customers), and own experiences.   If you want to understand their architectural design and security model a little more – you can find out here.

• … and IT better get on to the business of proving a similar model with the same agility; elastic economics; transparent pricing; and frictionless model for their “steady state load” and for workloads that for a variety of reasons aren’t a fit for Public and Community cloud models.   If you find solutions, but they require you to change, don’t view that as bad, but ask “should we perhaps think about changing that?”

That last point is where my rant is.

The next time I hear a customer say: “I want a private cloud, and need it stat!”, but then quickly say: “I want to build it the way I do today, with the operational model I do today, the organizational model I have today, and using the tools I do today” – I’m going to push back, and do it relatively hard.   It’s a face-palm moment.

As an example, I often hear someone say “how do I zone the storage in a Vblock into my fabric?”.   BTW the technical answer is “you can”, but the RIGHT answer is “NO, DON’T”.   This ends up exposing the root issue at stake here.   Storage (and Network) can be two of the least “software defined” things in the datacenter today.   Often their processes are painfully slow.   This isn’t intrinsic.  Amazon EBS would be less expensive if they didn’t architect it the way they do, but rather they just bought VNX’s or VMAX Cloud Editions and automated them using puppet, the existing APIs or the new Openstack plugins :-)

My point here is if you look at the first part of this post: This isn’t about technology, and the COST is not the benefit of the IaaS model of AWS EC2, it’s that the OPERATING MODEL that is the benefit.

Making this point in another way, centered about something not related to storage – I talked to another customer looking at HP Matrix, but because they didn’t want to “break” their networking team’s operating model and tools, they wanted to replace the HP networking fabric with Cisco.    First thing first – it makes me laugh that the team said “it’s converged, we just want to get a core component provided by someone else, and supported by someone else – oh, and that isn’t integrated into the system APIs, oh, and isn’t engineered together – but yeah, it’s converged”.  The HP sales team started with a  whole bunch of FUD on the Cisco/EMC partnership.   I asked the open socratic question in return: “what happens to converged from HP if they divest their server business?”

The point is that if the customer just want “converged infrastructure” to be “marketing on how we’ve always bought and operated”, then I get asking for and expecting to be able to mix and match however they see fit, I suppose.   CONVERSELY - IF they want to accelerate “creating an ITaaS option in the enterprise” (and perhaps get out of their own way), the fact that a solution bends/breaks their operational silos and tools is a FEATURE, and suggests it might be more likely to end up delivering IaaS than one that doesn’t… And it also suggests that if they chose HP Matrix, at least have the courage to go all in and make it converged (and yes, not manage VLANs/SAN elements inside the platform – you don’t in AWS EC2 of course).

The fact of the matter is that a Vblock is NOT primarily about the fact that the ingredients are good (although I would argue they are), but rather that it is a FORCING FUNCTION that break the operational silos of a customer – BTW, very timely – here’s a customer with a blog post on their first Vblock experience.

If they want to get on to the business of creating an ITaaS model in the datacenter, the optimizations around capital efficiency are all well and good – but if they trade off against “forking the operational model” or better yet “layering on vCloud Suite on Vblock and getting onto more important things”, then all they are doing is getting in their own way.

BTW – this is true of both types of “converged stacks” – aka those that are appliances that package engineering+warranty+support for virtualization/server/network/storage (like a Vblock) OR those that are servers with DAS/SSD + software that deliver VM-based storage (like Nutanix/Simplivity or vSphere.next with vSAN and NSX) both have this characteristic of “busting the operational silos”.   If someone tells you can get the value without breaking the operational silos – they are dancing around the point.  The benefit is that done right, they FORCE breaking the operational silos.

Could you build it all using whatever server/network/storage you want, then picking Openstack, Hyper-V or the vCloud suite?   Sure.   I would point out that if you think that it’s the selection of the giblets which will accerate your deployment, or provide the benefit – over just going “whatever, this is a commodity, I’m just getting a Vblock” – well, have fun I suppose.   Just look yourself in a mirror every few days and ask: “do I have agility, elasticity, price transparency, and the ‘frictionless’ nature of AWS and other public/community cloud options when I look at the Private Cloud I’ve constructed?”

I’ve met what’s stopping “Cloud in the Enterprise”. Answer is: US – as in all of us.

As always – comments & critiques more than welcome!

Comments

[Brett]

finally someone else did the maths. Yes our VNX has come in allot cheaper than AWS/S3 and just moving our email or ERP servers to cloud costs my 80% of my IT budget per year just in compute costs. I look at it as a challenge to remain more agile, cheaper and more available than AWS and so far has been great!

I could write lots on this but never quite find the words to explain the change in culture that is needed and it certainly seems only those who know it understand it. In saying that its not even about cost its about business value and success.

[Paul Lembo]

Chad,

Rant or no, the heart of your argument is sound. Agility and transparency are not marketing buzzwords, they are not just "nice to haves" on an approved projects list.

Its this simple... so called Shadow IT is more than just a shadow today and its not there b/c its actually cheaper.

Have you decided to act on that? Do some math? : ) Try new things even if they are initially uncomfy?

Let me end with a quote from my favorite three wise men, a call to fence sitters not yet motivated...

"If you choose not to decide, you still have made a choice!"

Stay well,

Paul

[Theron Conrey]

Awesome post. This perfectly highlights the procurement costs of storage while still highlighting the trouble in napkin math. One thing that you didn't mention are the two most expensive costs is storage over time. Power and People.

[Brian Gracely]

@Chad - you and I discussed some of this offline, but I'll throw out one other "cost" consideration if you're trying to make an apples to apples comparison. I wrote about it a little bit here (http://www.cloudsofchange.com/2013/03/the-changing-feel-of-vmware-pex.html), in the vCloud positioning section, but it goes something like this:

CAPEX COSTS - The cost to buy assets. Everyone understands these (IT, Finance, BUs)- they show up on the balance sheet. The cost to buy assets.

OPEX COSTS - The cost to operate assets (or services). These are understood by some, but harder to quantify since they are variable based on usage, efficiency, etc. And to improve them, it doesn't mean a change to a CPU, it often means a change to a person(s) or process(s).

OPPORTUNITY COSTS - The potential cost to lose out on another opportunity (cost-savings or added-revenue) because a dependent choice was made. These are difficult for many people to understand because they are theoretical, don't show up on the balance sheet and are strategic vs. tactical.

Right now too many traditional IT companies (and IT organizations) are trying to make a cost comparison without factoring in OPPORTUNITY COSTS, or the timeframes of the groups demanding cloud services (eg. Business Units needing to make quarterly numbers).

So unlike other big promises like VDI (where technology has been a true bottleneck), Private Cloud is failing to gain traction because the groups that are supposed to be the "new service providers" (eg. IT groups evolving to IT-as-a-Service) don't know how to go to market in a competitive environment.

[Randy Weis]

@Chad, as usual a dead-on discussion of the business value of technology. This is very timely as my company is re-making itself as a broker of cloud services. I've been struggling to make the case to shift to service-oriented IT from the technologist point of view, but I am relieved to know that my frustration is shared. I feel somewhat vindicated that I have come to many of your conclusions, but I haven't done the math the way you have.
@Brian, please repost your Clouds of Change blog, as it has been taken down.