Avoiding Private Cloud Pitfalls

Alex Henthorn-Iwane is responsible for marketing and public relations for QualiSystems.

There's a decent amount of private cloud bashing going on these days, and it appears the bashers have grounds for their critique. According to Gartner, between 2011 and 2014 the total number of virtual machines (VMs) has tripled, yet the percentage of VMs living in private clouds didn’t budge from its 3 percent position. On the other hand, public cloud VMs rocketed from 3 percent in 2011 to 20 percent in 2014.

In fact, prominent Gartner Analyst Thomas Bittman recently released a report titled, “Internal Private Cloud Is Not for Most Mainstream Enterprises.” That’s a pretty damning statement in and of itself. So, is the best way to avoid private cloud pitfalls to avoid private clouds all together?

I don't believe that's what Bittman intended. I think it's that most mainstream enterprises should focus on “agility” initiatives on public cloud applications and teams running in full DevOps mode. Meanwhile, traditional IT should move toward something less ambitious but not a private cloud in the true sense.

Regardless of what name to apply to it, 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 private cloud, then how do you move forward? Here are a few guidelines to help increase your chances of success:

Start With a Single Solution Cloud

You should first focus on a single team that allows you to put all your efforts toward satisfying a clearly identifiable client organization. In fact, Bittman writes, "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 generalize so much to meet everyone’s requirements that you don’t meet anyone’s in specific.

Understand Deploy Differences

Make sure you know that difference between supporting developers and testers and production application deploys. It’s very common to start private cloud initiatives by choosing development test use cases. However, the way that infrastructure is allocated differs between the two use cases.

First, application deployment infrastructure use patterns are similar to one-way trips. Infrastructure resources are allocated to application components, then deployed until decommissioned, which could be years.

On the other hand, development test use patterns are like round-trips. Users need to be able to access infrastructure environments (anything from a single VM to a hybrid physical/virtual environment with networking switches, etc.) for a relatively short period such as 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 is a good way 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 communicating, so if you’re trying to serve developers and testers, you’ll need 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. The alternative is to miss the use case.

Procure and Allocate Automation Skills

Cloud management platform products can help provide the scaffolding and substance needed to achieve a functional infrastructure-as-a-service offering to your starter use case. Unless you are fortunate enough 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 (IaaS) is automation, not automagic.

The term “private cloud” is a controversial at the moment. Terminology aside, you can still pursue the modernization of your on-premises infrastructure to increase efficiency and velocity. Your development, 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.

Industry Perspectives is a content channel at Data Center Knowledge highlighting thought leadership in the data center arena. See our guidelines and submission process for information on participating. View previously published Industry Perspectives in our Knowledge Library.