![\"\"](\"http:\/\/farm4.static.flickr.com\/3191\/2824768030_90baeb6fea.jpg?v=0\")
<\/p>\n<\/p>\n
\nMy post 15 Ways to Tell Its Not Cloud Computing<\/a> has had a lot of play – 24 trackbacks and counting… <\/p>\n 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. <\/p>\n 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<\/em> phenomenon, not an enterprise<\/em>, phenomenon. Can enterprises learn from Web simplicity? Of course they can, and should. Can web companies learn from enterprise middleware scalability patterns? Yup. <\/p>\n 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.<\/p>\n And so to pushback. I am really happy that I got such a considered and thoughtful response from Eric Novikoff of ENKI Consulting<\/a>, who does some work with 3Tera<\/a>. You might want to read my original piece first, but I will leave everything inline, my original 15 points in bold. <\/p>\n I thoroughly disagree with this \u201cbackwards\u201d definition of cloud computing. James Staten<\/a> of Forrester defines Cloud Computing as \u201cA pool of highly scalable, abstracted infrastructure, capable of hosting end-customer applications, that is billed by consumption.\u201d This is a definition that is amenable and extensible to the enterprise. This list of \u201cnots\u201d is not.<\/p>\n > If you peel back the label and its says \u201cGrid\u201d or \u201cOGSA\u201d underneath\u2026 its not a cloud<\/strong>.<\/p>\n Cloud computing as defined by Staten can be delivered from a variety of architectures, including Grids or SalesForce\u2019s Big Iron. That\u2019s the point of the cloud: abstracted infrastructure.<\/p>\n > If you need to send a 40 page requirements document to the vendor then\u2026 it is not cloud.<\/strong><\/p>\n 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\u2019s 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\u2019t change something underneath that breaks their app. Where is the savings in that?<\/p>\n > If you can\u2019t buy it on your personal credit card\u2026 it is not a cloud<\/strong><\/p>\n Businesses don\u2019t 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\u2019t 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\u2019re financing their business that way.<\/p>\n > If they are trying to sell you hardware\u2026 its not a cloud.<\/strong><\/p>\n This seems like it should be true. However, corporate customers are reticent to send internal data out into a public cloud. Why wouldn\u2019t they buy hardware from a cloud vendor to get similar advantages, delivered internally?<\/p>\n > If there is no API\u2026 its not a cloud.<\/strong><\/p>\n You won\u2019t get much disagreement from me on that, but most of our customers aren\u2019t interested in an API, so they probably would disagree. They just want to deploy and go, not write their own cloud operating system.<\/p>\n > If you need to rearchitect your systems for it\u2026 Its not a cloud.<\/strong><\/p>\n That would be nice, but I haven\u2019t seen one cloud that doesn\u2019t require some rearchitecting. Wholesale rearchitecting is often required to get around Amazon\u2019s peccadilloes, and even the AppLogic system we deploy on, despite it\u2019s 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.<\/p>\n > If it takes more than ten minutes to provision\u2026 its not a cloud. If you can\u2019t deprovision in less than ten minutes\u2026 its not a cloud.<\/strong><\/p>\n 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.<\/p>\n > If you know where the machines are\u2026 its not a cloud.<\/strong><\/p>\n 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\u2019t meet their requirements.<\/p>\n > If there is a consultant in the room\u2026 its not a cloud.<\/strong> > If you need to specify the number of machines you want upfront\u2026 its not a cloud.<\/strong><\/p>\n This is an assumption that Amazon has catered to. If you do the math, you\u2019ll see that Amazon bought it\u2019s 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\u2019s 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 \u201cbig daddy in the sky with infinite computing power\u201d cloud model. You\u2019re going to see more of it. If cloud computing is a commodity with perfect competition, like air travel, you\u2019re going to see vendors deploying intense strategies to manage their unused capacity.<\/p>\n > If you need to install software to use it\u2026 its not a cloud.<\/strong><\/p>\n 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\u2019 needs. The trick is not avoiding installation, but making it easy.<\/p>\n > If you own all the hardware\u2026 its not a cloud.<\/strong><\/p>\n 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.<\/p><\/blockquote>\n Its funny I get such strong reactions from consultants like Jeff <\/a>and Eric. I just can’t work out why that is \ud83d\ude09<\/p>\n 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<\/a>.<\/p>\n 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.<\/p>\n I like Tim O’Reilly’s recent three leg definition<\/a> – 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<\/a>” concerns and mores. To get a little bit goldilocks about all of this the 451<\/a> 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<\/em> granular as a I remember it.<\/p>\n
\nThis 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 \u201cinternal consultants\u201d 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 \u201cin the room\u201d 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.<\/p>\n