As much as the public cloud has started to work its way into the fabric of many enterprise computing infrastructures, a wide array of workloads still can't be moved into the cloud. Chief among them are those that center around specific performance requirements, security implications (especially in regulated industries), and getting a hold of and paying for high-speed network access to the cloud. However, even in these cases, it's highly desirable for business units to self-manage their computing resources and pay only for the resources they use.
In these situations, the construction of a private cloud can often satisfy many of the goals of going to the public cloud, while at the same time allowing the enterprise to implement whatever degree of performance capability and security infrastructure it requires. Likewise, maintaining infrastructure on premises removes the need to source potentially expensive WAN connections to the cloud.
Although building a private cloud shares many of the same steps as building an enterprise data center infrastructure, it is different in three key ways.
1. Balanced management capabilities
The most important differentiator between a traditional on-premises virtualization infrastructure and something that can be legitimately called a private cloud is the management layer -- or, perhaps more important, how that the management layer is actually used by IT.
As an example, imagine a traditional IT shop that supports a modern blade-based virtualization infrastructure. Chances are the gear used to put this infrastructure together can support a private cloud. However, the management layer is likely to be completely restricted to IT's use. If a business unit wants to deploy some servers -- even virtual ones -- a request to IT is needed and IT uses whatever management tools it has to complete the request on its own schedule.
Generally speaking, any private cloud infrastructure will offer some level of self-service. That might mean business units can manage all aspects of computing-resource lifecycle management from cradle to grave. Or it may simply automate one portion of the lifecycle that has proven to be a challenge for the organization as it relates to service delivery lead times or support response times.
For example, IT might make available private cloud management tools that allow a business unit to request a computing resource, but might still exercise oversight in approving them. Or it might allow the entire process to be entirely automated and self-service to the point of allowing a business unit to upgrade its "purchased" resources on the fly.
The decision around which level of access to allow is not one of how good of a public cloud you're willing to construct. It's often not even an issue of cost because most cloud-management frameworks are capable of exposing varying degrees controls to end-users. Instead, it's an issue of matching the capabilities of the cloud management software layer to the skill set in the business units and the challenges they're eager to solve.
For example, it does absolutely no good to expose a high degree of granularity in computing instances a business unit could deploy if the business units don't have the know-how to understand it. Conversely, if they have those skills, limiting their access to below the level of detail they can handle could simply replace one kind of conflict with IT with another.
In the end, the challenge is choosing a cloud-management package (or even developing your own) that fits the needs of the business units you intend to support.
2. Multitenant security
The next major difference between a traditional IT-driven infrastructure and that of a private cloud is the security model. In typical IT environments, few network security controls are in place in the interior of the network. This is primarily because IT controls the lot of them, so there are no administrative control boundaries to consider.
However, if business units are allowed to deploy their own servers and manage them at an administrative level, IT may (arguably, should) choose to treat them as untrusted and to protect both core infrastructure and other business units from them. Implementing this kind of interior security is not difficult, but it requires an entirely different mind-set for implementing network security. Gone are the days of the "inside, outside, and DMZ." These are instead replaced by a single "outside" coupled with a multitude of "insides" -- each with its own security policies and administrative domains.
It's also worth mentioning that this internally segregated security model is highly desirable even outside of private cloud infrastructures, depedending on the administrative control boundaries. Even in networks with a single administrative body and tight top-down control, having some interior security capability can be extremely useful for preventing attacks or malware infestations from spreading.
This is a worthwhile approach to investigate whether or not a private cloud implementation is in the offing.
3. Nondisruptive scalability
Finally, designing the infrastructure to be easily and nondisruptively scaled is a key requirement for most private cloud implementations. Depending on the size and complexity of the infrastructure, this design can mean a range of different things. It might be an issue of deploying a server and core networking infrastructure that can be scaled to several multiples of its initial size without a forklift upgrade. Or it might involve more complex storage design that leverages object-based storage in an effort to provide an easier means of delivering scalability and redundancy.
No matter what changes are necessary to how the infrastructure is built and managed, keeping a close eye on how unfettered business-unit consumption of computing resources will impact IT's ability to keep the infrastructure running is critically important.
In the end, building a private cloud is not so different than building a modern enterprise computing infrastructure. Although key differences surround how the infrastructures are managed, what kinds of internal security capabilities are included, and how to maintain the ability to scale aggressively, the hardware and software used may be about the same. Even if you aren't building a private cloud now, it's worthwhile to consider these differentiators. After all, as time goes on, the concept of what a "traditional" computing infrastructure is will eventually be supplanted by that of the private cloud.
This article, "The 3 keys to designing a private cloud -- or data center," originally appeared at InfoWorld.com. Read more of Matt Prigge's Information Overload blog and follow the latest developments in storage at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.