Deconstructing Private Clouds: What You Need & Steps to Take

I hear very often that cloud platforms, specifically private clouds, are simply the next evolution of virtualization. This is incorrect and hides a massive amount of complexity, concern, and good old fashion work in a fog of assumption & misunderstanding. I'm not the type to be a real stickler for proper terms of art; generally if I can figure out what you’re after in a conversation I let it slide. However, this one is too big to leave alone.

A lot of companies out there would have you believe that your first foray into the cloud should manifest as a private Infrastructure as a Service (IaaS) endeavor. This seems to be an attempt to marginalize the technology, or tread water until they have established a true cloud offering. Marketing is a weapon of sorts, and I strongly believe that companies that toe this line are pointing it square at their own customers, holding them hostage until they are ready to deal with the cloud landscape.

Strong words huh? Well they should be. This sleight of hand hides a nasty fact: running a private cloud is almost twice as much work as running a standard data center or virtualization stack. Think about what it takes:

• You still have to acquire or retrofit the hardware to support the cloud - Compute & Storage!
• You still have to build out or modify your networking layer
• You still have to deploy the basic hypervisors & virtualization control layers
• Next on your checklist: plan, design, create and test your Gold Guest images
• Integration with authorization systems or the creation of authorization systems
• Connectivity to other sites, or the Internet

Oh, and by the way, you’re still paying for CAPEX as well as service and support.

Building Your Private Cloud

Once you've done all that, then you start building your private cloud. To do that you’ll need to:

• Gauge your capacities
• Install your cloud control layer
• Design, plan, and implement your elasticity rules
• At the very least, layout your chargeback model, then at the very least, design, plan, and implement it
• Service delivery roll out is our next contestant! Self service patterns and classes of service: plan, design, create, and test.

Lot of work huh? If you get this far, congratulations: You now have to run the datacenter environment, the virtualization stack, the cloud layer, AND assist your end users within their individual implementations inside the cloud.

The bottom line is that a private cloud is a massive outlay of effort. While you don't have to refit your entire hardware stack to have a private cloud, you still have a healthy amount of OPEX expenditure in time and money to keep it cranking. It's not something to trivialize, but it happens every day in a million different minds, encouraged in a hundred million different slick glossies.

All that said, private clouds have their place. They mature in very tight IT shops that take the workload on and win. There are missions that are tailor-made for private clouds. More often than not, the security mechanics of the public cloud are as strong as or stronger than what you can do within your own four walls. However, there are politics and regulations that may have very little to do with actual security that makes a private cloud more appealing, or possible to acquire an Authority-to-Operate (ATO) against. That's life in a regulated world. Sometimes your missions are small enough and your infrastructure is mature enough that a private cloud is a great place to start, even if you don't have regulation pressures.

However, there is a spot between the private cloud ideal and a "simple" virtualization stack that seems to lack a good, understandable definition, and consequently a spiffy marketing term. Some of the better, more complete, and more stable private cloud products live in this space: Eucalyptus, RedHat, and others like them.

Know Your Department & Needs

Let’s say you’re a typical IT organization that is looking for accountability and automation in running a virtualization stack for a few groups or departments. Chargeback is less of a concern than quick turn-around and resource accountability. Self-service may or may not be a big deal to you either, especially if you have a Help Desk that can field the requests in a day or so. Oh, and by the way a day or so is good enough to roll out a known design pattern - doing that in hours is an over kill and doesn't have much value to your end users.

This set of goals and features floats between the full NIST definition of private clouds— "IT as a Service" — and virtualized data centers circa 2007. Self-service, chargeback, and instant provisioning are the three characteristics of the cloud that hit the floor first, because many times they are simply not "must haves" when compared to the rest of the feature sets, as well as, the fact it takes a considerable amount of internal political wrangling to make them a reality.

This use case is a good example of the fact that not everyone needs to rush directly to a full on NIST private cloud model and, most certainly, do not have to push that model down the throats of their customers if there is not a definable need for it. However, that doesn't mean that the actual definition of cloud or virtualization needs to be perverted in the race for your attention. At the end of the day, when you start your project, know what you need to accomplish your mission and push buzzword compliance to the backseat.