Private Clouds: A Good Starting Point for IT

Everyone seems to have a definition and opinion on cloud computing—and every technology vendor seems to have a solution. There’s a reason many of us did not sign up for cloud computing and avoid vendor headlines related to C and C. Filter, delete. Dehumidify.

But the reality is—looming clouds, storm approaching—enterprises have to get ready. Business executives of some companies are already asking for an IT plan.

CEO: Hey Bill, What’s up with cloud computing? Are we ready?

Bill: We’re looking at it. There’s some hype. Let me get back to you.

The good news: the shift to cloud computing doesn’t have to be painful or costly. But it does require work and know-how—either from external cloud providers, expertise in IT, or through an outside consulting firm working with your internal IT team.

A few forward-thinking enterprises have been working on utility computing (read internal clouds) for years. In the process of consolidating data centers, reducing servers and storage n-fold, and squeezing every dollar out of purchased IT infrastructure, these companies have invested time and money developing sophisticated cost analysis, tracking, and service delivery and support techniques. In effect, they have transformed from traditional IT shops—to becoming more like service providers.

But where does that leave the CIO of nearly every other enterprise? How should a CIO begin building a cloud computing strategy and implementation plan?

Likely, many will start with a private cloud strategy—providing the hub to current and future cloud computing initiatives. A private cloud is simply a secure cloud and associated set of security services (authentication, administration, identity management), among others, available to a user-base, usually within an organization.

In general, private clouds:

• Increase time-to-innovation: on-demand resource provisioning means users work on projects instead of waiting on IT resources
• Shift the cost model from up-front capitol acquisition to pay-per-use. While some up-front cost may be required for integration, application redevelopment, etc., the cost model should become pay-as-you-go—once the cloud is ready for use.

There are three basic deployment models for private clouds:

• Internal private cloud: a private cloud can be internal, deployed and managed on local IT infrastructure, usually owned or leased within an organization.
• External private cloud: a private cloud can also be external, deployed and managed on remote IT infrastructure. In some cases, a 3 rd-party provider may own and manage the remote site for IT, offering specific private cloud services.
• Hybrid: some combo of the two above, often “federated”.

An internal private cloud provides a good starting point when:

• Your company has higher data confidentiality and / or higher security requirements. If your applications can be virtualized, or are targeted for cloud computing, but there are concerns around security—i.e., moving them offsite—an internal cloud may be the way to go.
• Applications or workloads are targeted for higher service levels. An internal cloud gives IT the most control over delivering SLAs in support of workloads and applications.
• Costs can or must be assessed to effectively select and compare to external offerings. Understanding the costs of delivering internal service utilities provides the ground work for RFPs and assessing 3 rd-party offerings. Cost analysis provides the basis for defining service offerings and SLAs.
• Infrastructure can or should be leveraged. Much of the infrastructure required to deploy private clouds may be in place. Companies that have deployed sophisticated networks, servers and storage, and considering virtualization software, have the building blocks in place for private clouds.
• The project, for any number of reasons, requires an on-premise solution.

An external private cloud makes sense when:

• You have low to moderately confidential information. If security or confidentiality is high, but the external provider is trusted—either as an IT division, subsidiary customer, or known partner company—external private clouds may make sense.
• Applications or workloads (such as test, development, and training) are met by the SLA published by the provider. An external cloud provider should publish specific SLAs in support of general computing environments.
• Increase time-to-market. If the external provider is also a specialist in delivering private clouds, they may have a rapid deployment offering or package designed specifically for delivering private clouds, remotely.
• Current IT cost information is limited or irrelevant. Some companies may not need to assess their own internal costs of delivering the same IT functions as hosted services. For example, startups, SMBs, or medium-size businesses with little IT expertise, may choose to deploy externally to outsource all IT functions.
• Temporary project infrastructure is required—but no capitol may be obtained. For example, many rapid prototyping or testing projects may not be funded to obtain to IT infrastructure locally, or need to be rapidly acquired and decommissioned.

Other companies will utilize hybrid (or federated) private clouds, where a portion of the service utility is run internally and federated to external sites as needed, or vice versa.

Examples where hybrid internal/external clouds could be used include:

• Disaster recovery. Applications and/or virtual machines may be created and run locally, but need to be replicated to remote sites. The primary site may be an internal cloud, run by IT, and the target DR site could be external, hosted by IT or 3 rd-party provider.
• Collaborative workflows: if many remote users need to collaborate on an application or data set within or between sites, aspects of the data set may be replicated; conversely, virtual private access may be provided remotely to the data set, through a VPN or other means.
• Mixing and matching some combination of internal and external cloud capabilities to address many IT-related requirements in any number of use cases.

Vendors such as VMware claim that hybrid, federated clouds are the way forward. They want enterprises to be using their virtualization platform as a building block to clouds.

However, being locked into a single virtualization platform—through VMware, Microsoft, or [name your cloud provider]—creates compatibility and data portability issues across hypervisors which could limit the interoperability of a hybrid model.

Data portability: that’s a good topic for another blog.