Blogs

RedMonk

Skip to content

15 Ways I Am Wrong About Enterprise Cloud Computing

My post 15 Ways to Tell Its Not Cloud Computing has had a lot of play – 24 trackbacks and counting…

A lot of the commentary so far has generally approved of the angle I took, though clearly there are strong dissenting voices. Before I proceed to one of them I just want to point out that 15 Ways was always intended to take a strong position, though hopefully with some humour. That is, the post was somewhat rhetorical. Of course not all enterprises are going to suddenly drop enterprise IT and do everything over at Amazon Web Services. That would be a. absurd and b. impossible.

But on the flipside I see a lot of over-complication from major players – around something that originally simply spoke to provisioning architecture for developers without the headaches. Cloud started as a description of a web phenomenon, not an enterprise, phenomenon. Can enterprises learn from Web simplicity? Of course they can, and should. Can web companies learn from enterprise middleware scalability patterns? Yup.

However- whatever else the cloud is, it should not just be an excuse to try and rewarm technology that has already failed in the marketplace. It should not be an excuse to sell a new complexity.

And so to pushback. I am really happy that I got such a considered and thoughtful response from Eric Novikoff of ENKI Consulting, who does some work with 3Tera. You might want to read my original piece first, but I will leave everything inline, my original 15 points in bold.

I thoroughly disagree with this “backwards” definition of cloud computing. James Staten of Forrester defines Cloud Computing as “A pool of highly scalable, abstracted infrastructure, capable of hosting end-customer applications, that is billed by consumption.” This is a definition that is amenable and extensible to the enterprise. This list of “nots” is not.

> If you peel back the label and its says “Grid” or “OGSA” underneath… its not a cloud.

Cloud computing as defined by Staten can be delivered from a variety of architectures, including Grids or SalesForce’s Big Iron. That’s the point of the cloud: abstracted infrastructure.

> If you need to send a 40 page requirements document to the vendor then… it is not cloud.

More and more cloud vendors are offering solutions rather than cpu cycles. CPU cycles are great for programmers, but businesses want to solve business problems. Without a definition of what the customer’s problem is, and an honest and transparent reply from the cloud vendor, you are running on hopes and dreams instead of a known value delivery system. The result is that the companies most successful with Amazon have dedicated staff and management to ensure a successful cloud deployment and to make sure Amazon doesn’t change something underneath that breaks their app. Where is the savings in that?

> If you can’t buy it on your personal credit card… it is not a cloud

Businesses don’t like to pay for expenses on personal (or business) credit cards. In fact, they prefer a budgetable monthly spend which of course contradicts with consumption billing. Our customers *don’t want* to pay by credit card, by and large. Only the web2.0-in-a-garage startups are interested in credit card payment: possibly because they’re financing their business that way.

> If they are trying to sell you hardware… its not a cloud.

This seems like it should be true. However, corporate customers are reticent to send internal data out into a public cloud. Why wouldn’t they buy hardware from a cloud vendor to get similar advantages, delivered internally?

> If there is no API… its not a cloud.

You won’t get much disagreement from me on that, but most of our customers aren’t interested in an API, so they probably would disagree. They just want to deploy and go, not write their own cloud operating system.

> If you need to rearchitect your systems for it… Its not a cloud.

That would be nice, but I haven’t seen one cloud that doesn’t require some rearchitecting. Wholesale rearchitecting is often required to get around Amazon’s peccadilloes, and even the AppLogic system we deploy on, despite it’s virtual datacenter analogy, still has some characteristics that require minor architecture changes for some applications. Whether or not you have to rearchitect depends more on how much you encoded your expectations of the hardware environment into your code than it does the particular cloud you deploy to.

> If it takes more than ten minutes to provision… its not a cloud. If you can’t deprovision in less than ten minutes… its not a cloud.

Where are you measuring the time period from? We can bring up a virtual private data center in the cloud in 2 minutes. But our customers often take days, weeks, or months to figure out how they want to provision from the moment they decide to. For businesses, the time from decision to deployment is a better measure than time to provision.

> If you know where the machines are… its not a cloud.

This simply points up disagreements about the definition. Most customers who demand high performance (say, running Oracle) and certification (say, HIPAA) both want and need to know where the machines are. They are unlikely to deploy to clouds where the architecture is so opaque that they can’t meet their requirements.

> If there is a consultant in the room… its not a cloud.
This is false on two counts. First, those companies who have successfully deployed their entire operations to the Amazon cloud have dedicated staff to manage Amazon deployment. Call them “internal consultants” if you will – people whose job is to manage/consult on the cloud. Second, a large number of reseller/consultants have sprung up to facilitate the use of Amazon. Amazon is becoming something like a physical server: you need someone to run it for you. These consulting/reselling companies do that. They may not be “in the room” however, which is one of the benefits of Cloud Computing: it creates an internet-enabled ecosystem of knowledge workers you can use with your application without providing a cube for them.

> If you need to specify the number of machines you want upfront… its not a cloud.

This is an assumption that Amazon has catered to. If you do the math, you’ll see that Amazon bought it’s cloud business by selling under its costs. Especially in the early days, keeping huge reserve capacity up and running was a cost that was not passed on to the users. Many of today’s cloud providers manage their inventory of physical hardware to reduce their costs, by offering discounts on usage to customers based on contracts. This will (and does) lower the prices for customers over the “big daddy in the sky with infinite computing power” cloud model. You’re going to see more of it. If cloud computing is a commodity with perfect competition, like air travel, you’re going to see vendors deploying intense strategies to manage their unused capacity.

> If you need to install software to use it… its not a cloud.

Cloud computing and open source seem to go hand in hand. My experience is that each of my customers wants a different version of their operating system, database, etc. Cloud vendors typically provide a library of code images, but they cannot custom-configure to meet an individuals’ needs. The trick is not avoiding installation, but making it easy.

> If you own all the hardware… its not a cloud.

There definitely are cloud providers out there who have their customers lease the underlying hardware, which defeats the concept of usage-based billing. However, your statement would get puzzled looks from many large enterprises who run their own clouds.

Its funny I get such strong reactions from consultants like Jeff and Eric. I just can’t work out why that is ;-)

So what about these “puzzled looks” from folks that Eric says have built their own behind the firewall cloud. An enterprise guy is welcome to call the infrastructure they’ve been building out a cloud. Everything is a cloud these days, right (one of the reasons I wrote 15 ways of course)? An end to end VMWare shop is going to be in pretty good shape for rapid provisioning, for example – which is why VMware is certainly in the running as a CloudOS player.

When I say that IBM lacks a cloud strategy what I mean is that its cloud strategy is currently too diffuse, too complex, and not closely enough managed. Where are the simple on ramps? We currently have such a bad case of definition sprawl that some segmentation is required.

I like Tim O’Reilly’s recent three leg definition – Utility computing, Platform as a Service and Cloud-based end-user applications. But we need more segmentation on the Utility side, to take account of “enterprisey” concerns and mores. To get a little bit goldilocks about all of this the 451 has done an awesome job of cloud segmentation with a report I… can’t find on the internet, mind the firewall guys -but its actually too granular as a I remember it.

Its not my intention to put forward my own segmentation at this point but I do want to point to a recurring theme from Eric, about my missing the point – we could call this the Hidden Costs of Amazon Web Services argument. Or AWS TCO Smackdown or something. I will refer at this point to another post by Novikoff, where he talks about his experiences as an SDForum Cloud Event.

Each of the companies using EC2 had developed intense internal expertise on Amazon’s service. That’s right, you read correctly: on Amazon’s service. Not on Cloud Computing in general (though there are those who argue that EC2 and Cloud Computing are the same thing) but rather on the intricate technical and organizational details of dealing with Amazon and its service as well as optimizing their use of it.

It wasn’t a surprise to me that these companies, dependent on Amazon for their success, would get to know the service well. What did surprise me was the lengths to which they went to mitigate the risks. Generally, if you have doubts or fears about something, you want to learn all you can about it. These companies showed incredible technical depth at understanding EC2′s characteristics and peccadillos. They asserted that it was critical to their success. But this seems to me to be in direct conflict with the ideal of Cloud Computing, which is the democratization of information technology; in other words, lowering the barriers of entry. I think this is an admission that Cloud Computing technology in any form is still not polished enough for completely casual use. At ENKI, we realized this early on and decided to strive to be the “onramp to the Cloud” by providing all the services necessary to use our cloud without having to know anything about Cloud Computing.

At Redmonk we tend to think low barriers to entry don’t require consultants to navigate – but that’s just us. As is clearly the case right now the turbulence surrounding the cloud conversation is a barrier to entry, which is where people like Eric and RedMonk come in.

The truth is I am probably half right, and half wrong. I leave the reader to decide to turn the dial to parse Eric’s comments and my own. What do you think?

Categories: Uncategorized.

Comment Feed

11 Responses

  1. awesome article. I think you touched on several of the big misconceptions of cloud computing.

  2. Excellent article highlighting how the term “cloud” is being overused. I like your pure definition and the three leg definition you cite as much of Eric’s comments are really talking about ASPs, hosted providers, or just applying lessons learned from cloud computing to the enterprise.

  3. Excellent post, James.

    Listen, I think the cloud very quickly outgrows the “proof of concept” stage of super simple demonstrations of the cloud’s power, and moves into a technology advancement phase, where more advanced solutions are possible, at the cost of more complexity. Typically, this game is played by both consultants and start ups, resulting in plenty of cr*p, but also the occasional revolution.

    Its all a complex adaptive system, James, and we are all just agents along for the ride.

  4. I am reminded of the days when relational database was new. Every Tom/Dick?harry (remember Dbase anyone) DBMS vendor leaped onto the bandwagon. The best excuse being, well it manages relationships so it is relational.

    Now I look at Cloud with some of the same jaundiced eyes. ASP models can deliver terrific value, but somehow they have become cloud based. All with no significant changes. I wonder how they managed that?

    Behind that lightness there is a serious comment. That is, that for all computing that we need to have done, we need to select the most cost effective platform for it. Sometimes it is in-house and hosted. Sometimes it is ASP, where the functionality and the platform are externalized (think Domain as a Service), and sometimes it is cloud based where a couple of forks occur. We can develop applications specifically for the cloud – so the cloud is just the base platform, or we can run purchased apps in the cloud – essentially ASP with a different deployment model.

  5. Ok, this was pretty amusing to me. And it pointed out a weakness of the Internet. People read a URL and think it defines a company. ENKI was founded as a consultancy to assist companies in data center consolidation. We rapidly realized that companies preferred just offloading the whole datacenter rather than the consolidation. So today, we offer self-service cloud computing together with operations services that companies may want to outsource together with the cloud computing. You don’t need “consulting” to use our cloud. (However, the cloud can be a great place for an ecosystem of consultants, as we are seeing one form around Amazon.) However, by now a squatter is sitting on the “ENKI” URL and we’re in the process of rebranding. But if you don’t go into the web site an look, you can make the mistake that we are a consulting company. We’re not. Want a different face? Go to http://www.computingutility.com/ However, I digress. The labeling of myself as a self-interested consultant obscures the possibility of a productive discussion of how the enterprise can be served by Cloud Computing. And who in the IT industry isn’t self-interested? Self-interest is a red herring. What’s more interesting is, who actually practices win/win business relationship?

  6. Eric – come on man. If posting all of your critique here isn’t pointing towards a productive discussion i don’t know what is. If I didn’t go in and look at your web presence – how do you think I found the blog entry I pointed at? Like many consultants before you, you’re repositioning as a supplier of repeatable services. i respect that. self-interest i respect.

    But in the final analysis you’re trying to make a virtue of complexity, and i would argue that I am trying to make a virtue of simplicity. Somewhere in the middle is the value statement.

    Honestly- I did’nt find Staten’s definition to be all that compelling, its a very data center centric view – and the cloud is going to shape that up. its not all going to be on premise private clouds.

  7. James, I’m posting the mail I sent you today on your request. However, before I do that I must say that I’m a great appreciator of simplicity, but I acknowledge that I don’t always get things my way.

    Thank you for the spirited discussion and the opportunity to rebut.

    A lot of the hype around the Cloud is energized by the myth of “something for nothing” or nearly nothing. Do you really think Amazon isn’t “in it for the money?” The “dirty” secret around cloud computing is that cloud providers make their money off base load while hyping the savings of peak load, and that most users are base load users, not peak load users. Companies with instant 10x peaks or hockey-stick grown are the extreme minority, only about 2-3% of our customer base. How do you think that Amazon had the ability to charge a fraction of a dollar per instance hour when they had a huge inventory of servers standing by – much larger than the actual servers making money, at least in the early days? They did it by buying the market and setting their prices below their costs. I know this because I do the costing for ENKI and no economies of scale could possibly lower Amazon’s costs to 1/10th or less of my costs if I kept that sort of inventory (just the power is a killer!). They were investing, expecting a return, just like any publicly held company. And the expected return is determined by the stock market, not their altruism or even their profit motive. They expected the return to come once a large percentage of their resources were *not* idle, but supplying base computing load to customers. I hope, for everyone’s sake, that this is happening for them because it would be bad indeed for the cloud market if their gamble didn’t pay off.

    The issue I was bringing up with my comments is that the price-based cloud which Amazon pioneered is focused on the developer. Go to any cloud computing conference and it’s all about the developer. As a result, there’s no end-to-end consideration of how to provide value to the enterprise, most of which don’t develop but rather purchase and deploy software. And there’s no discussion about how Amazon’s opaque architecture creates up to 200ms latencies between instances (and S3) that completely eliminate the ability to host whole classes of applications, or about the continuous stream of customers who I see coming to ENKI that just can’t get enough service from Amazon to get them over the hump to getting an application deployed. That isn’t any way to capture the interest of the C-level folks who are concerned with the value cloud can provide to their enterprise, not dollar cost per instance or even whether provisioning is automatic or manual. It’s not that Amazon is wrong or even bad, it’s just that the cloud market is separating and segmenting into different types of clouds aimed at different customers. Which is why I took issue with your one-size-fits-all definition.



Some HTML is OK

or, reply to this post via trackback.

Continuing the Discussion

  1. [...] James Governor’s Monkchips 15 Ways I Am Wrong About Enterprise Cloud Computing … whatever else the cloud is, it should not just be an excuse to try and rewarm technology that has already failed in the marketplace. It should not be an excuse to sell a new complexity. [...]

  2. [...] we had 15 Ways, then we had 16 Corrections, then 15 Ways I am Wrong, and now we have 3 Ways. What would Martin Luther have [...]