From Enterprise Datacenter to Private Cloud, Part 1
One of the most frequently-asked questions I get when from CXOs is: How do I turn my datacenter into a private cloud? In the next couple of blogs, I'll outline how we can take a current traditional datacenter and transform it into an on-premise internal, or private, cloud. Many people make the mistake of claiming that they have an internal cloud already just because they have gone through server virtualization, and while server virtualization is the essential, inevitable first step to building an internal cloud, it is merely the beginning.
There are many benefits to transforming a datacenter into a private cloud has many benefits. But, it's not an easy task and this is not a project that IT can undertake on its own, as doing so will will affect the business as a whole -- the way we procure software will have to change, the way we provision VMs will change, building and enforcing VM standards, etc.
If I had to use one word to summarize the benefits, it would be "discipline." Of course, we are all seeking to reduce cost and maximize efficiency. While I am a strong believer that eventually our datacenter will end up in a public cloud, I think for a period of time we will have a hybrid model and we will slowly transition into placing our most valued resources in the internal private cloud while everything else sits in a privately hosted cloud in the public cloud somewhere. I think today we say "justify a physical server," and tomorrow we will say, "justify putting the resource in the internal private cloud."
Let's start with the basics. To lay a good foundation for an internal cloud, we need to start at the procurement level. Wwe need to establish and be willing to enforce specific procurement requirements. For example, it is no longer acceptable to choose a software vendor whose products you'll be using to not support virtualization. So, one of the very first requirements for software procurement should be:
- Do you support virtualization?
- What is your roadmap for expanded virtualization support and product enhancements?
- Enforce the first and second requirements in any RFP process.
The first two basic requirements can go a long way, but in order to enforce these requirements, you must have business buy-in to the internal private cloud projects and spell out its benefits to the business. Typically these apps are dictated by the different business departments and if you have a business sponsor, you can enforce these requirements. When talking to software vendors, you have the power to dictate, you are paying money and running your business. Vendors have to be willing to support you as well in order to facilitate your other initiatives -- they can no longer just say no.
Once we can get past procurement and we have a clear understanding of how we are going to address that issue, we need to then develop a virtual machine standard. To start, we have to evaluate the different operating systems that we intend on supporting and tie them into the procurement process. Here's another task that's not an easy one to do, so approach this with caution. A set of standards is needed if we are going to build a robust internal private cloud.
The standards conversation will then expand to developing a VM standard, so not only are you limiting the number of operating systems, but now you need to limit the number of VM profiles you support (for instance, Windows 2008 R2 with 2 vCPUs and 8 GB of memory, etc.) There is nothing wrong with having different tiers, as long as you keep the number of VM profiles in check. Don't create 10 profiles for Windows Server 2008 R2.
You see where I am going with this, right? So far we have limited the number of OSes that we support, we established standards for our VMs from a hardware profile perspective and we have developed a procurement policy to support virtualization. Now what? As we start to acquire these software packages with different virtual hardware requirements, we need to fit them in our standards without deviating. In some cases we will use a VM profile that has more resources than the requirements, or we may choose to fit in a profile with fewer resources and change the tier later. Whatever we do, we have to work within the framework we have established.
These strict requirements will benefit us significantly later as we start to discuss chargebacks and showbacks, as we start to discuss automation and orchestration. As you can see so far, building an internal private cloud is not a simple "click next" project and will require true business and IT alignment.
In upcoming blogs, I will go deeper into what the next steps are, what tools to use, what infrastructure to use, etc. Meanwhile, I would love your feedback on this discussion.
Posted by Elias Khnaser on 02/01/2012 at 12:49 PM