Virtualization to cloud: Planning, executing a private cloud migration
A comprehensive collection of articles, videos and more, hand-picked by our editors
For good reason, clouds are a popular topic in IT. They offer numerous benefits, such as pay-as-you-go billing...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
models, seemingly infinite resources and the ability to place workloads around the globe to boost capacity. Still, as you consider a cloud migration, you will likely have to make changes to your data center infrastructure and your organization to prepare for the move. You need to think carefully about the impact on all aspects of data center infrastructure and on IT teams.
Before taking on a cloud migration project, you need to take a step back and evaluate the wisdom of the move. It's critical to make the business case for why a migration to the cloud makes sense -- and the fact that the cloud is en vogue is not enough. So, assuming that you already have a private cloud, why would you want to add public cloud capabilities? Perhaps you want to broaden your disaster recovery (DR) options by running workloads from a different location. Or maybe you want to add workloads, but are constrained by capacity limitations at your on-site data center. Or perhaps your reasoning for the move to a hybrid cloud model is financial. The pay-as-you-go aspect of public clouds can shift capital expenditures to operational ones and free you from unpleasant leases and forklift upgrades.
It is critical for all levels of your IT organization to know what the goals of this move are, so your organization can make solid decisions. It is also important to include all IT teams --including application, system, network and storage administrators -- in these plans. Their knowledge will be key to solid preparation for implementing a hybrid cloud.
Assess existing infrastructure and set goals
As you consider moving to a cloud model, the first step is to assess where your infrastructure is now. Do you already have a private cloud and want to bridge the gap between it and a public cloud? Perhaps you are on the path to virtualization, but you haven't progressed to a cloud. And while the term "cloud" has many meanings, it doesn't just mean greater degrees of virtualization; it also involves a push toward centralization and automation. In particular, this move toward centralization makes the cloud as much about people and process as it is about technology.
Gather technical requirements
It's critical to make the business case for why a migration to the cloud makes sense -- and the fact that the cloud is en vogue is not enough.
Once your organization has made its business goals for a hybrid cloud clear, develop technical requirements with your staff. Do the applications you want to move need to scale? Perhaps you need load-balancing capabilities, not just for service availability, but also so you can distribute workloads and automatically redistribute resources to accommodate the peaks and valleys of cloud demand. Do applications require secure communication to a back-end database that will continue to live in your data center? Do you need services to run from particular parts of the globe for support or DR reasons?
Once you have identified your technical needs, consider public cloud provider offerings objectively. For example, perhaps some providers natively support your virtual private network (VPN) concentrator or a network tunneling technology your engineers are already comfortable with, thereby making secure networking easier. At this stage, it's also important to gather performance data. Knowing how much network and storage I/O your applications generate enables you to size network connections and virtual machines that reside in the public cloud and to select from differing service tiers offered by public cloud vendors.
Select hybrid cloud tools
Several self-service cloud portals can connect your on-premises infrastructure to public cloud infrastructure. Most work with a subset of public cloud providers, so knowing your technical requirements and organizational goals is important to match a tool set with providers' capabilities, as well as with your own infrastructure.
There are several aspects to consider. First, how well do these tools manage existing heterogeneous infrastructure? Do they require completely new infrastructure, or do they plug into what you have already built? Where do these tools run? Do they get installed in a legacy data center or run in the cloud? Some tools, like VMware's vCloud Connector, plug in directly to existing infrastructure, but that has implications for DR. You would need to plan for your primary site becoming unavailable and ensure that you fully protect your management infrastructure.
Can these tools access more than one public cloud? What about accessing a provider's different locations? Are these tools capable of doing chargeback and real-time reporting of costs and performance metrics across all sites? Does it help monitor and meet service-level agreements (SLAs)? Does it create a service catalog from which users can choose? How does it help manage templates and configurations? How does it handle authentication? Is there an audit trail? At this stage, you need to ask all these questions.
Implement security safeguards
Once you have selected a cloud provider and a tool set, you need to address the multifaceted issue of security. To begin, determine how the tools and the cloud provider will interact with your data center and grant them access through network- and host-based firewalls if necessary. This might be tricky with offsite, hosted tools, as private clouds' management interfaces are often on completely internal, private networks.
You need to implement authentication and access control for the new hybrid cloud tool as well. Perhaps the tool has its own authentication systems, so you need to recreate your users and your access control policies in its user database. For example, when an employee leaves the company, you need to revoke his cloud access at the same time as you revoke his onsite access. You also might need to grant access to your internal help desk for password resets. If the tool uses existing authentication systems, you may need to make those systems more robust, especially if one of your goals is DR. Without a robust authentication system, consider what would happen if your primary site went down and users were still trying to access these systems.
If you have sensitive data that is stored in a public cloud, investigate encryption technologies for that data. Securing network connectivity among sites is also important, and it may require changes or additional purchases. You also need to consider how to store important data, like cloud application programming interface (API) keys and encryption keys. Access to them is important in an emergency, but they also grant powerful access rights to whoever knows them. This is a good time to take steps to protect these access rights but also to make them available when needed, protecting them as you would an administrator password, logging access and changing access information periodically.
Read part two of our discussion of migrating to the cloud for its implications for networks, storage and configuration management.
About the author
Bob Plankers is a virtualization and cloud architect at a major Midwestern university and author of The Lone Sysadmin blog.