The Three Faces Of Cloud

Going out to the GigaOm Structure09 cloud event gave me an opportunity to reflect on "what is cloud" and, more importantly "what is not cloud".

While many of the discussions were interesting, I did feel that there were way too many contrived arguments needed to support thinly-veiled product pitches.

At the event, a journalist I know stopped me, and begged me for a very short, understandable description of what this cloud stuff was all about so she could better understand what everyone was talking about.

Needless to say, I was very sympathetic.

I did my best to oversimplify -- let me know how I did?

Cloud Is Different -- But How?

Someone joked once that the definition of a cloud was roughly similar to the definition of pornography -- you'll know it when you see it.  Yes, that example is mildly inappropriate, but it makes the point regarding the subjectivity of the whole discussion.

I started my discussion by saying that cloud represents a departure from traditional approaches to IT in three important aspects: 

• architecture (how things are built),

• operations (how things are run),

• and consumption (how things are paid for).

Each is probably worth a short discussion.

Cloud as An Architectural Model

Clouds are built differently than traditional IT.  All resources (server, network, storage) are ideally pooled at scale and dynamically accessible. 

Large numbers of workloads are aggregated -- they come and go, applications take what they need from the pool when they need it, and give it back when they don't.

Compare this with traditional IT approaches, where each application usually gets its own dedicated server resources, and sometimes its own storage.

The goal here is not only efficiency through sharing, but to deliver responsiveness -- the ability to give an application or workload more resources quickly if needed, without having to pre-allocate. 

It's interesting to note that -- generally speaking -- today's networks are run exactly in this manner.  And the word "cloud" was first used to describe networks before it was used to describe compute environments.

Cloud As An Operational Model

Clouds are generally run differently than traditional IT. 

The first thing you notice is that there are far fewer people required to run a given environment of a certain size.  A lot fewer.

How is this achieved?

The supporting technology platform is relatively standardized and uniform.  Compare this with a traditional IT operation that might have different kinds of servers, networks, operating systems, storage, etc.

This standardization of platform makes standardization of process that much easier.  Standardized processes make automation much easier, and -- if done right -- require an absolute minimum of IT interaction.

Because it's all about the processes, work is organized using a process (or service) centric model, rather than the standard "cylinder of excellence model" we usually find in IT: server, network, storage, database, etc. 

Sure, we find that sort of expertise in cloud environments, but their involvement isn't part of some sequential workflow process to get anything done.

As a result, the organization charts for cloud IT operations look very different than traditional IT. 

Cloud As A Consumption Model

Everything in life has to be paid for one way or another, and IT resources are no exception. 

The dominant theme you'll hear in cloud discussions is "pay for what you use", or metering.  I think this is misleading. 

Paying for what you use is nothing new -- use of IT resources, whether internal or external, have always been metered -- and paid for!

What really changes with cloud is getting comfortable with oversubscription of resources.  In typical IT environments, server resources and storage bandwidth are provisioned to near-worst-case levels, which results in a lot of resources being wasted on the average, since near-worst-case doesn't happen so often.

In a cloud, you provision to the average, rather than the near-worst-case.  If you need a surge of resource, it's presumed to come from some shared pool.

As long as demands are uncorrelated, this scheme works well. However, if resource demands end up being correlated (e.g. all the cloud users are retailers during the holiday season), this scheme doesn't work out so well.

Indeed, use networks as a historical example of clouds that we're all familiar with.  Generally, shared network schemes work well.  There are even newer network consumption models that enable you to "burst" bandwidth if you need it -- we'll undoubtedly see more of that in the future.

However, if everyone is doing the same "I need more bandwidth" thing at the same time, the scheme fails to deliver.

Put simply, if you look at your IT landscape and say "hey, a significant amount of these workloads can be aggregated and are relatively uncorrelated in how they behave", you're a strong candidate for a private cloud.

On the other hand, if you look at your IT landscape and say "hey, there's no significant portion of my workloads that can be aggregated and behave in an uncorrelated fashion.  Most of what I do can't be aggregated, and certainly doesn't behave in an uncorrelated manner", well, it's a more thorny proposition.

For more on the dynamics of oversubscription, please see this post.

What Is Cloud and What Is Not Cloud?

At the conference, there were many definitions and attributes assigned to clouds that I found myself disagreeing with strongly.

The first one of these red herrings is the assumption that all clouds are outsourced and external to IT.  Why should a cloud be defined by who built it and where it runs?

There's no reason why a proficient IT organization might want to build their own internal cloud.  And, if you've been following the private cloud discussion, there's a strong incentive to build it in such a way that you can choose dynamically between internal and external resources.

The second one I heard a lot was that applications had to be re-thought, re-architected and re-written to take full advantage of the cloud.  I usually heard this one from vendors who had new software tools to sell.

Complete and utter nonsense from my perspective. 

Take any arbitrary application, put it in a virtual machine, run it according to the three principles above (architecture, operations, consumption), and -- voila! -- you have a cloud by definition.

Sure, you can make the pedantic argument that applications could be re-written to be more aware of the environment that they're running in (e.g. a cloud, a desktop, a cell phone, etc.), but that should be an option, and not a definitional mandate.

Indeed, one of the reasons that private cloud models are so darn attractive is that they don't require existing applications to be changed in the slightest -- if you choose.  Conversely, any cloud proposition that starts with "rewrite everything" will face a very slow adoption rate.

A third, more subtle version of this application argument is that applications must be taught to be multi-tenant -- they need to understand multiple organizations using the same code, need to understand security, need to understand service level delivered, need to understand geographic location, need to understand ...

Well, with this long list of application requirements, one could argue that these applications will never be written.  Or, if they are, they'll shortly be obsolete because all of these attributes tend to change over time.

You're not going to want to have to change your application every time the deployment model changes, or the security model changes, or the distribution model changes, or ... well, you get the idea.

I would argue vehemently (as I did with a few people) that this sort of approach is ludicrous -- infrastructure issues belong in the infrastructure, and not in the application.

Applications are free to query the world around them and make intelligent decisions about what they do and how they do it, but again this should be optional, and not a prerequisite.

Additionally, I found that many people equated clouds with ginormous scale that couldn't be addressed with existing technology, therefore we all should wait until new and exotic stuff gets invented.  Indeed, there seemed to be a bit of a contest as to who could name the most obscure technologies and companies.

Sure, there will be clouds that will be very big, and a few that might require some new approaches in various areas (e.g. filesystems), but I think those gigaclouds will be the exception, rather than the rule.

Take off-the-shelf technology today, and you can build some pretty effective (and relatively large!) clouds.  No need to get into the exotic (or uninvented) stuff.  Of course, we'll see better technology over time -- don't we always?

And then there was the presumption that all clouds require fine-grain metering and billing.  That statement flies directly with my personal experience in consuming other forms of shared infrastructure -- phone service, cable, internet, power, water, etc. 

I have a rough idea of what I spend every month on these things, but couldn't begin to give you a fine-grained view of any of it.  Nor do I want one, thank you.

You'll get a bill for what you use in resources -- pretty much the way that IT chargeback works today.  Hopefully, though, it'll be a much smaller bill with a more efficient IT cloud!

Where Does That Leave Us?

I'm not quite sure. 

Maybe I'm oversimplifying too much.  Maybe my assertions above that are counter to conventional cloud wisdom are just plain wrong.

Or maybe not.

Either way, we need a much clearer dialogue on clouds and what they mean to enterprise IT.  There's far too much muddled thinking around IMHO.

I can only hope it gets better, and not worse!

Comments

[Marty Loughlin]

To take your power bill reference a step further, we can be reasonably confident that "cloud" electricity is efficient. However, there is still the issue of inefficient consumption.

The same issue applies to companies leveraging cloud infrastructure. Plug cloud into a poorly run IT organization and you get a more efficient, poorly run IT organization.

Can cloud be successful without organizational transformation?

[Nick Mehta]

I like your point about clouds not just being external. The "external" versus "internal" thing is truly a red herring. It's just a question of economies of scale for a given company. If you are big enough to have a large number of apps and a great deal of infrastructure, an internal cloud may make sense and could be cost-competitive with the external providers.

[William Louth]

"And then there was the presumption that all clouds require fine-grain metering and billing. That statement flies directly with my personal experience in consuming other forms of shared infrastructure -- phone service, cable, internet, power, water, etc."

How does one run a business (especially a service based one) if you do not have fine-grain metering to determine cost drivers. How many people pay their phone bills without requesting itemization? You might as well just had over your money to Amazon or Google if that is the case. Metering also helps in migrating from one vendor to another as it allows you to cost the differences based on the rate plans of the alternatives which are to some degree based on common resource metering whether it is one to one is a different matter,

I think you might be merging billing and metering when in fact there are different. Billing is largely subscription based for such things are phones, internet & cable but metering is still be performed when the customer has access to this information and requires it for cost purposes. Someone is always metering someone else and in the future with more and more software being cloud service based what is being purchased is the interaction that you want metered and with competition on pricing this metering will be correlated with the metering of the underlying platform.

Cloud Computing – A Tale of Two Machines
http://williamlouth.wordpress.com/2009/03/23/cloud-computing-a-tale-of-two-machines/

http://www.jinspired.com/products/jxinsight/meteringthecloud.html

I was not at the event so I cannot comment on how this was actually pitched but we have being pushing our activity costing & metering solution well before there was an actual cloud.

[Chuck Hollis]

William, you make good points, so thanks.

And, upon reflection, you're right -- fine-grained metering supports a variety of billing options which might be either fine-grained, or more simplified.

Thanks for correction!

-- Chuck