All at once I saw a crowd

Last week James Governor of Redmonk published a blog entry entitled “15 Ways to Tell Its Not Cloud Computing”. It drew some very interesting commentary from Mark Cathcart, John M Willis, Chris Petrilli and Gerrit Huizenga.

James was kind enough to acknowledge my input in his blog entry and in return I’d like to offer some views on why I substantially agree with his blog post. Please note that this is an emerging space and the idea of a cloud remains nebulous. So what James is really saying, I think, is: let’s ask what we want from cloud computing in the next few years.

Clouds are all about delivering a “retail like” experience to users - even within the enterprise. Here is an analysis what this might mean.

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

Clouds are about offering compelling economics for infrastructure as a service instead of as on premise servers or big desktops.

Clouds offer a fundamentally different abstraction than Grids. If there is a metaphorical ‘label’ then you should not be able to ‘peel it away’ at all. Grids provide a mechanism for running processes that implement a specific API, across multiple compute resources. Clouds provide a service for users to run whole applications by deploying them to a virtual data center.

Of course clouds can use a grid technology under the hood, for example to schedule slots. But the point is that many complexities are hidden from the user in order provide a clean and simple service. Whether the cloud is “public” like Amazon EC2, or in some sense an “enterprise” or “private” cloud, it delivers a “retail experience”. You should not need to read and understand multiple long documents to use it. I know of several hedge funds running grid style compute farms on EC2 using map/reduce on Xen images - it’s easier that way.

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

In my opinion a cloud should offer “self service” capability. The cloud should not itself need to be customised by the provider, for individual customer use cases. This is not just about “productising” for the retail market. Consider an enterprise with two data centers. Clearly it saves money and time if applications can be migrated between data centers without refactoring. An enterprise knows it has implemented a cloud, when this is possible. Achieving this requires a certain abstraction.

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

Well - sort of. This is about managing cost when multiple users share common server infrastructure. Without a means to capture costs of use and attribute them to users, explaining where value comes from becomes a matter of guesswork. This hampers investment in new enterprise projects by staff who want access to shared infrastructure, and commonly leads to ‘guerilla’ use of things like Amazon EC2 by staff on their own credit cards.

At CohesiveFT we meet customers who tell us that, as they migrate to ever larger pools of shared infrastructure services, they are unable to understand which business units are using which resource and when. Individual business units are unable to calculate cost/benefit. Costs get aggregated to maximum granularity and have to be justified by the CIO and CTO to the CEO and COO. In practice this makes it impossible to get things done.

The solution that I think the cloud model enforces is based on the discipline of a retail model. If data center providers made all users attribute costs as if they were paying by credit card, then everyone would know how much they were paying and for what. This would break down barriers to financing and starting new projects however small.

If they are trying to sell you hardware… it’s not a cloud.

Clouds represent a way to separate ‘opex’ from ‘capex’. People making investment decisions about cloud resource needs should not need to factor in any amortised capital investments in hardware, because they only pay for what they need, when they need it. When a business case is being made for a new enterprise project, if hardware purchasing costs do not appear in the ROI calculation, then you probably have a cloud. Then, the data center managers decide how much hardware to buy and at what price to offer their cloud services to business units. An internal market may be used for dynamic pricing.

If there is no API… it’s not a cloud.

If there is no API then it is not a service. Clouds virtualize resources (e.g. CPU, storage) as a service. Hence clouds must have APIs, e.g. a means to load and start up an application, or to stop it.

If you need to rearchitect your systems for it… it’s not a cloud.

The key word here is ‘need’. What we are discovering is that virtualizing whole compute environments may be the right way to ‘do’ utility computing. Whether computers are delivered as bootable images or as VMs, this means that people are not required to completely rewrite their application to run it in the cloud. Do we need to explain why this is more attractive than the alternative? I didn’t think so.

Note that people surely will come up with new ‘green field’ applications that depend critically on the cloud infrastructure. These ‘virtual stacks’ are very exciting too.

If it takes more than ten minutes to provision… it’s not a cloud.

Is this controversial? As John M Willis points out, the whole notion of provisioning is being replaced by autonomics and elasticity for managing running systems. At CohesiveFT, we also argue that elasticity really means provisioning includes built-to-order system assembly.

If you can’t deprovision in less than ten minutes… it’s not a cloud.

This is really critical. Being able to stop something and clean it up, is much more important than being able to start it. Anything else just adds friction which translates into less incentive to use the service in the first place and hence less agility and other benefits.

If you know where the machines are… it’s not a cloud.

Location matters for many applications such as trading systems, and complex clusters, because location impacts latency. But then the latency properties of a service ought to be exposed as part of its contract with the user. Then, perhaps users are willing to pay more for lower latency, or for better bit throughput.

What clouds ought to do, however, is get us away from any ‘my rack, your rack’ thinking because that breaks the retail model by recoupling opex to capex.

If there is a consultant in the room… it’s not a cloud.

Of course if you want to build your own clouds and work out the business case for moving system administrators over to new roles such as “virtual sysadmin” then get a consultant.

For actual use of a retail-like service by the enterprise, or within the enterprise, you should not need a personal shopper unless your use of clouds is a vanity project.

If you need to specify the number of machines you want upfront… it’s not a cloud.

The point is that you can increase your load whenever you like, so long as you can pay for it. Hence it does not matter if you start with zero machines or ten thousand. This is not the same as saying “you cannot request how many machines you need”.

If it only runs one operating system… it’s not a cloud.

This is about cloud providers not forcing end users to adopt their particular operating system distro and build. It characterises the difference between the new ‘self service’ clouds based on virtualization technology, and the CPU-rental model of a couple of years ago.

Generally the people we meet have their own ideas about which O/S to use on their computers, so why not extend this to the cloud? The alternative is to offer a data center service which only runs a particular O/S build - this kind of Linux, that distribution, and that build. In an enterprise, this simply does not scale across multiple data centers over time. For a retail cloud, it’s out of the question. This is why it is hard to see retail and enterprise clouds working commercially unless the compute unit is a virtual image or bootable image.

If you can’t connect to it from your own machine… it’s not a cloud.

Clouds are about consolidating resources in order to benefit from economies of scale. When a service is inaccessible or unavailable, then that diminishes its value to the service provider as well as the end user. We have found that people want to do things like spread their loads across their own machines, and data centers, or across multiple clouds securely. We call this ‘multi-sourcing’. Obviously some degree of secure accessibility is a prerequisite for this.

If you need to install software to use it… it’s not a cloud.

“You” means the user - clouds are about making life easier for users. If you are an enterprise with a cloud, or using clouds, then you may have teams all over the world, including folks coming and going all the time, or working from within IT suppliers or at customer sites, then your cloud will have a lot of users. You want to reduce any costs that you are currently paying for them to access your IT resources. This is why a ‘retail experience’ is so essential. Cloud means service.

If you own all the hardware… it’s not a cloud.

Because you don’t want to own all the hardware. It eats up power and space, gives off heat, and needs people to look after it. As more and more “green tape” appears in the form of environmental regulation, and if oil prices go higher, trust me you won’t want to own and be responsible for owning and managing hardware.

If you need a three page blog post to explain it ... it’s not a cloud

Enough already!