Buyer's Guide: How to get private cloud right

There are a lot of misperceptions about what it takes to get your private cloud investments right and drive adoption by your developers

Recent Forrester enquiries from enterprise infrastructure and operations (I&O) professionals show that there is still significant confusion between infrastructure-as-a-service (IaaS) private clouds and server virtualisation environments. 

As a result, there are a lot of misperceptions about what it takes to get your private cloud investments right and drive adoption by your developers. 

The answers may surprise you; they may even be the opposite of what you’re thinking. Forrester surveys show that 36% of enterprise I&O teams are putting a high or critical priority on building a private cloud this year. But there’s a catch: most aren’t operationally prepared to run a cloud.

1. Where is the line between cloud and server virtualisation?

This is the issue at the heart of nearly every question Forrester takes about private clouds. Virtualisation underlies nearly every IaaS cloud environment, and you may use many of the same tools to manage your cloud as you do your virtual datacentre. But there are a few fundamental differences between the two:

Clouds are highly standardised

First off, you need to conduct the main operational procedures of your cloud environment – such as provisioning, patching, monitoring, restart, clone and even destroy or archive – in exactly the same way every time. 

It is through standardisation that you gain predictability from the cloud and begin to lower its operational costs.

Clouds are fully automated

Your systems administrators should rarely have to get involved with your cloud environment; clouds should mostly run themselves. That’s how their economics pay off and how you deliver the fast time-to-market your developers seek. 

That means all the procedures we mention above that have been standardised should be handed over to automation software for execution. So long as developer requests fall into the standard operating procedures, your administrators should play no role at all.

Clouds are self-service environments

Don’t be scared of this concept; we aren’t talking about letting chaos reign. Self-service makes I&O lives easier and better through standardised procedures, fixed deployment options, a service catalogue that’s built as a decision tree, and automated approval workflows. 

Each user has approval and access to request certain workflows, essentially building the approval process into the user permissions. If you don’t offer self-service, your developers won’t see this as anything different.

Clouds are multi-tenant

Pop quiz: How many private clouds should your organisation have? The only right answer is one. 

Now, how many server virtualisation environments do you operate? One per business unit? Silos for different groups? This approach keeps applications from coming and affecting each other’s performance, and it makes access rights easy to manage. But it also keeps resource utilisation artificially low, and no cloud should have low resource utilisation. 

Through a good multi-tenant architecture, private clouds keep business units virtually separated but resources highly utilised and operational consistency intact and cost effective.

2. Isn’t everything eventually going to be in the cloud?

No – not even on a 10 to 15-year horizon. How do we know this? Look at your own datacentre. Is that a mainframe in the corner? Is that dusty off-white server in the last row a Unix system running the database you first set up when only five people worked at your organisation? Why are those machines still here? Because they keep working, and frankly it would cost more to try to modernise and migrate them than to just keep them running.

You could virtualise these legacy workloads eventually, but that still doesn’t mean you would drop them in the cloud, because the highly standardised, multi-tenant nature of the private cloud may not be a fit for all workloads. 

Cloud computing is just an extension of the IT portfolio that provides new deployment options with different economics, degrees of standardisation and automation, and means of efficiency. Expect only 10% to 15% of your applications to fit in the cloud today, and for this to grow to between 30% and 60% over time.

3. How big a private cloud should I build?

Smaller than you think. First off, we recommend starting small. This helps you ramp up your cloud knowledge with less pressure, and starting small spans beyond your cloud learning curve. There are four key reasons to start small:

Expect slow buy-in

It will take time for your organisation to see the value in your cloud, and you don’t want a bunch of expensive capital sitting around waiting for this to happen. In 2010, one Fortune 500 insurance company’s private cloud only supported two test and development groups to get their feet wet – it plans to expand to four groups later this year.

Maximise utilisation rates throughout

Because the objective of the cloud is to maximise utilisation (and therefore long-term cost savings), you want to fill it up before you expand it. This means getting your I&O team comfortable with operating an environment running at 60% to 80% utilised all the time.

Avoid cloud squatting

You want your customers to continually leave your cloud. The most common use of your cloud, initially, will be for test and development purposes, which are transient, and as one workload goes you want to quickly free up the resources for the next. If the cloud is too small, then it forces developers to clean up after themselves to make room for new workloads.

Give the appearance of a sold-out show

This reason is perhaps the least intuitive – you need to leave your customer wanting more. The cloud is a shared environment, which means you need lots of constituents lobbying for its expansion to justify further investment. If they love the fast time-to-market it provides but can’t get enough, they’ll make the case for you to expand it.

Sadly, private clouds are not a “field of dreams”. Although a well-designed private cloud should be attractive to your developers, keep in mind that they may have experience with public clouds and may be skeptical of your effort to match that value. 

Developers may also be used to getting their own resources through the old, inefficient system and not have a clear incentive to switch to your cloud model. This means you have to market the cloud to them and you have to incent them to use it.

This is an extract from the Forrester report “Q&A: How To Get Private Cloud Right” (May 2011) by James Staten. James is principal analyst at Forrester and blogs at:

Read more on Cloud computing services