Virtualization to cloud: Planning, executing a private cloud migration
A comprehensive collection of articles, videos and more, hand-picked by our editors
Building a private cloud isn't a quick process. It starts with understanding expectations and defining cloud computing...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
in your environment, then building on the model you've created. Enterprise IT must include the entire organization, its processes and its technologies when constructing a private cloud.
Here are the first five steps you need to take to conceive, build and maintain a private cloud within your enterprise.
1. Decide what you want out of a cloud
Journeying to the cloud is a huge trend in IT. The problem is that the term "cloud computing" means something different to everyone. To start your journey, your organization needs to be realistic about its cloud computing goals.
Many organizations find themselves looking toward private clouds only after they've realized the promises of virtualization, like data center consolidation, power savings and cost savings over physical hardware. Others find themselves wanting to take virtualization to the next level, with standardization and automation as part of their IT processes.
But few organizations are ready to work on organizational changes, tackling the harder "people problems" that traditional IT has fostered, such as silos, duplication of services, security and management of services. These are not usually technical problems but run roughshod over organizational boundaries and long-standing political domains.
To start your journey, your organization needs to be realistic about its cloud computing goals.
And there are many misconceptions about the term "cloud," including an overabundance of differing definitions. One common misconception is that private clouds are completely based in virtualization. Even though virtualization usually plays a major role in a private cloud deployment, a private cloud can also just mean a shared infrastructure. Take, for example, Google's Gmail or Microsoft's SkyDrive. Both are public cloud services that don't rely much on virtualization. Instead, massive amounts of physical hardware are in use behind the scenes.
The same is true of a private cloud for your organization, in which a shared service is created to replace many different duplicate services, and the use of virtualization is evaluated only as part of that service's implementation. For example, a shared file server service might replace dozens of departmental file servers, and it might be implemented with physical hardware because of the incompatibility between VMware vMotion and Microsoft Cluster Service.
2. Have realistic expectations of the journey -- and the cloud
You should expect that there cannot be true self-service IT within your organization. IT departments have spent years wrapping process and procedure around the act of creating and managing servers, usually with good reason. Often these processes are responsible for monitoring systems, determining sizing and dependencies, documenting system designs and responsibilities, handling licensing and more.
Allowing any end user to provision a server or service without approval mechanisms in place might be appropriate for certain lab or test-and-development environments, but in a production IT environment it is a quick path to chaos, sprawl and outages. However, it is reasonable to expect much of the provisioning process can be automated and standardized through the use of workflow tools and approval mechanisms, like those found as part of Embotics' V-Commander or enStratus Networks' offerings.
Expect the journey to the cloud to be less about technological challenges and more about personnel challenges, as processes are torn down and recreated, routine tasks automated and standardization championed. An IT department that is heavy-handed and unresponsive to users' needs may not be in the right place to start rethinking itself and its work. Similarly, an IT department that is overworked may not have enough free time to pursue cloud solutions, despite the time savings the cloud would provide.
It is very important that management prioritizes IT work appropriately and backs up the IT department in the face of complaints about delays in other work due to the focus on cloud computing.
Finally, all levels of management, including human resources, will need to support a transition to the cloud. Not only will all facets of the organization see delays as IT works to improve itself, but IT workers whose primary jobs consist of the tasks being automated might also consider themselves targets for layoffs and may actively undermine the process. Plan for personnel issues and, from the beginning, communicate to staff that they are valuable and these efforts are intended to free them to do more interesting, more productive work for the organization.
3. Understand enterprise workloads and services
Working toward a private cloud model is difficult when you don't understand the services on which your organization relies. Documentation is key; without it the relationships among systems are hard to decipher, service-level agreements are unknown and it's easy to make false assumptions. The needs of the people using these services should also be documented so that new cloud services can be built to meet those needs. This is especially true when centralizing duplicate services within an organization. There was a reason a department built its own infrastructure instead of using shared services; find out the reason to get their buy-in and avoid conflicts.
Expect the journey to the cloud to be less about technological challenges and more about personnel challenges.
Documentation also lends itself to standardization, because a standard that does not account for all needs and system design requirements will quickly have exceptions. Performance information is also crucial to moving toward shared infrastructure and cloud-based applications. A year or more of historical performance data, as high resolution as is practical, can be very helpful for determining capacity needs and system sizing.
4. Get on the path to virtualization
While it isn't required that a private cloud be based on virtualization, it is the common model. Virtualization usually drives certain knowledge and behaviors within organizations. For example, most virtualization software requires centralized storage. That same centralized storage will be a building block for a private cloud, so the knowledge gained in implementing virtualization is very beneficial to private clouds.
Likewise, virtualization is usually quite disruptive to data center networks. At the very least, it can turn static traffic patterns into dynamic ones.
The move toward shared computing models and cloud-based computing continues that trend and increases the reliance on networks, which usually drives up bandwidth needs. The dialogue started among your virtualization administrators, storage administrators and network administrators as a result of planning for virtualization will become crucial as you advance into the cloud, especially when planning to serve remote offices and mobile users.
5. Understand that standardization and automation go hand in hand
Automation is one of the key goals organizations have when moving to a private cloud. However, automation is incredibly difficult without standardization. For example, with standards for operating systems (OSes) and server builds, you can make assumptions about locations of files, sizes of file systems and authentication mechanisms. Based on those assumptions, you can script the installation of application software and middleware such as Web servers, application servers and firewall rules.
Standardization can be difficult for an organization that has not practiced it. But once you take on standardization, the time savings can be enormous.
Consider an organization that has had no standards for OSes, OS versions or build processes. Every server is different and every operation needs special attention. Procedures for patching or installing software differ each time, and success rates waver because of the variations in each host. This usually has two consequences: An incredible amount of staff time is spent performing routine tasks on these servers, and many routine tasks, like patching security vulnerabilities, are skipped because they are too difficult and unpredictable. Standardizing on one or two OSes and automating the build and application deployment processes yields massive IT productivity gains.
Once you've automated much of your environment, you can deliver self-service portals and service catalogs. Though it is unlikely that your organization will ever be 100% self-service-driven, many processes can be automated with workflows; the only interactions, then, are approval processes. This allows the IT department to focus on more important issues -- how to best support and monitor an application or service, for instance. It also gives application admins and developers a consistent and repeatable platform on which to build. And it means IT operations staff can build useful, repeatable procedures for handling incidents and monitoring system alarms, instead of each server being a one-off exception. It may even open the door to automated responses to alarms.
These are the first five steps an enterprise needs to embark on when building a private cloud infrastructure. But these are just the beginning. IT teams need to continue on the private cloud journey by putting in place procedures, such as chargeback or showback, that hold business units accountable for IT resources provisioned and consumed. And private clouds must be carefully monitored to maintain performance and keep end users -- as well as the CIO -- satisfied with the new direction you've taken IT.
Bob Plankers is a virtualization and cloud architect at a major Midwestern university. He also contributes to SearchServerVirtualization.com and SearchDataCenter.com and is the author of The Lone Sysadmin blog.