There seems to be a good deal of private cloud bashing going on these days. The bashers have grounds for their critique.

According to the Gartner May 2015 report by analyst Thomas Bittman entitled “Internal Private cloud is Not for Most Mainstream Enterprises” between 2011 and 2014 the total number of VMs has tripled.

However, the percentage of VMs living in on-premises private cloud IaaS didn't budge from its 3% position while public cloud IaaS VMs rocketed from 3% in 2011 to 20% in 2014.

In my opinion, just the title of the report is quite an indictment of the notion of on-premises private clouds. So, is the best way to avoid private cloud pitfalls to treat private cloud itself as the pitfall to avoid?

One could be forgiven for wondering what to do with the 77% of VMs that still live on-premises, alongside billions of dollars of bare metal servers, networking devices, and storage equipment. Are they doomed? Not exactly.

On one hand, the report states that the “focus of many internal private cloud efforts has shifted away from cloud and toward virtualisation automation for legacy apps - and products focused on improved virtualisation automation have been more successful”, which is encouraging.

On the other hand, the report forecasts that “by 2020, less than 5% of enterprise workloads will be running in true on-premises private clouds.” What does this all really mean?

First of all, I think it's important to tease some important concepts apart. In the report, Bittman distinguishes “true on-premises private clouds” from “virtualisation automation for legacy apps.”

True private clouds are competitive with and have the characteristics observable in major public cloud IaaS offerings, but are built on-premises for security or compliance reasons.

By contrast, Bittman notes that “Larger deployments tend to be less "cloud" and much more "virtualisation automation," with little use of self-service and standard offerings, lots of customisation, and some manual effort.”

Cloud management platform vendors may have a thing or two to say about the precise boundaries of what constitutes a “cloud” vs “virtualisation automation”.

Nonetheless, I feel the meta narrative from Bittman's point of view is fairly clear: If you're not building something that is competitive with AWS, then you're not building a private cloud, you're building virtualisation automation.

Pride of terminology aside, “virtualisation automation” is not cast as a bad thing. As mentioned above, the report mentions that this type of “private cloud” is actually seeing broader success in enterprise IT teams.

Whatever you want to call your infrastructure modernisation initiative, there's no doubt that IT needs to move faster across the board. If you're dealing with applications and infrastructure that aren't ready to move to the public cloud, then how do you move forward?

Here are a few guideposts that can increase your chance of success:

1. Start with a “Single Solution Cloud” focusing first on a single team, use case and solution allows you to put all your efforts to satisfying a clearly identifiable client organisation.

Anything “as a service” requires careful scoping. In fact, Bittman writes the following in his report entitled “When Building a Private Cloud, Start Small, Think Big” published November 2013, and updated in October 2014:

“Private cloud projects will usually fail if they are scoped too large, move too fast or are developed without an evolving, comprehensive road map for services and processes.”

Even if you have big plans, restrict the scope to ensure that you don't try to generalise so much to everyone's requirements that you don't meet anyone's in specific.

2. Understand the difference between supporting developers and testers and production application deploys. It's very common to start private cloud initiatives by choosing devtest use cases. However, the way that infrastructure is allocated differs between the two use cases:

• Application deployment infrastructure use patterns are kind of like one-way trips. Infrastructure resources are allocated to application components, then deployed until decommissioned, which could be years.
• Devtest use patterns are like round-trips. Users need to be able to get access to infrastructure environments (anything from a single VM to a hybrid physical/virtual environment with networking switches, etc.) for a relatively short period. The period can be hours to weeks. Once they're done, the resources need to come back into the shared pool and be baselined, so they're ready to be deployed by the next user.

Having a clear handle on this is a good starting point to ensure that you don't miss the requirements of your starter team and use case. Keep double-clicking on the requirements, particularly if the use case is new to you. Often, IT and developers haven't spent a lot of time in communication, so if you're trying to serve developers and testers, you'll need to do your homework thoroughly.

3. Plan to offer a complete infrastructure solution. If the team you're trying to service is working across legacy/physical and virtual infrastructure, there's no choice but to address all of those infrastructure elements in your service offering. The alternative is to miss the use case.

4. Procure and allocate automation skills. Cloud management platform products can help provide the scaffolding and a decent amount of the substance needed to achieve a functional infrastructure as a service offering to your starter use case.

Unless you have the good luck to be in a single vendor infrastructure, you're very likely to have to do some automation planning and integration. You simply won't be able to achieve your goals without getting at least one person who is good at automation scripting and has a grasp on data models.

That's still a far cry from trying to build from scratch and the need for a big team of professional coders. However, the point is that building infrastructure as a service is automation, not automagic.

The term “private cloud” is a controversial topic for the moment. Terminology aside, you can still pursue the modernisation of your on-premises infrastructure to increase efficiency and velocity.

Your dev, test, security, compliance and other teams can work a lot faster and more productively via infrastructure as a service. By taking careful, well planned, properly scoped steps, it's possible to make IaaS happen.

Article by Alex Henthorne-Iwane of QualiSystems.

Alex Henthorn-Iwane joined QualiSystems in February 2013 and is responsible for worldwide marketing and public relations. Prior to joining QualiSystems, Alex was vice president of marketing at Packet Design, a provider of network management software, and has 20+ years of experience in senior management, marketing, and technical roles at networking and security startups.

Through his roles at QualiSystems, Packet Design, CoSine Communications, Corona Networks and Lucent Technologies he has acquired expertise in cloud computing and the opportunities presented through virtualisation. He has written for Embedded Computing, Virtual Strategy Magazine, Datamation, SDN Central, Datacenter Knowledge and InformationWeek.

Connect with him on LinkedIn, Twitter, or SlideShare.