that reflects all aspects of your operations. To perform a migration, you must know exactly which applications you are running, their dependencies, along with any storage, network, operating system, processing, memory, and any other relevant requirements. The more detailed assessment of your current operations, the better equipped you are to decide whether it makes sense to move to a cloud-based model.
Selecting Cloud Compute Resources
Let's talk about some considerations for migrating on-premises compute resources into the cloud. In the data center, you have virtual machines. It's often possible to migrate a virtual machine directly to the cloud, but the better approach is usually to create a new virtual machine in the cloud and configure it from scratch. One reason for this is that a virtual machine running in your data center will have drivers and other software specific to the virtualization platform that you're using, which will undoubtedly be different than what the cloud provider is using. Performing a “lift and shift” migration to the cloud is asking for trouble.
The sizing of virtual machines—processor power, memory, and storage—should mirror that of your data center VMs. VMs in the cloud are fundamentally no different than the VMs in your data center. There is no “cloud magic” that makes cloud-based VMs more resource efficient. For example, an application that requires 16 GB of memory in the data center will require just as much memory when it's running in the cloud. Make sure that there is ample input/output (I/O) and low latency for storage access, and that there is enough processing and memory allocated to ensure the proper level of performance expected.
One final word on migrating machines to the cloud. Prior to machine virtualization, each physical server ran a single operating system on bare metal. This often meant that one server could host only a handful of applications. Nowadays, machine virtualization is the norm, both in the data center and in the cloud. However, you may occasionally run across an old application that for whatever reason has to run on a bare-metal server. Such applications generally aren't good candidates for moving to the cloud. If you're not sure, you can sometimes smoke out such legacy applications by looking for servers that have been exempted from operating system updates.
Hypervisor Affinity Rules
Another consideration involves the physical placement of your data center VMs. To ensure resiliency in the event of a virtualization host failure, organizations often use hypervisor affinity rules to ensure that redundant VMs never run on the same hardware. For example, you may have primary and secondary SQL database servers, each running on a different VM host. If the host running the primary SQL VM fails, the secondary VM running on a different host can take over. If both are running on the same host, then both VMs fail, defeating the point of redundant VMs in the first place!
Cloud providers offer the ability to enforce hypervisor affinity rules, although they may use more user-friendly terminology, such as VM-host affinity. As you plan a cloud migration, take note of VMs that are redundant or that appear to serve the same purpose. Chances are that you have hypervisor affinity rules in place that you'll want to re-create in the cloud.
Validating and Preparing for the Move to the Cloud
To perform a successful migration to the cloud, it is important to bring together all the interested parties and stakeholders. The traditional IT groups such as development, operations, OSs, storage, networking, and security will be integral parts of the migration teams. Non-IT groups, such as finance and legal, will need to be involved, because cloud computing can significantly change the cost and accounting models of departments and possibly the entire organization. In the data center model, a healthy portion of the budget goes to the up-front expenses of purchasing physical infrastructure such as servers and networking equipment. Accountants call these capital expenditures (capex for short). When moving to the cloud, these huge capital outlays aren't necessary. Instead of spending hundreds of thousands or more on IT infrastructure, you pay the cloud provider a monthly fee based on usage. This expense is ongoing for as long as you use the services, but the amount you have to fork over up front is much less. This is called an operational expenditure (opex) model. In essence, instead of buying or leasing your own equipment, you're leasing the use of the cloud provider's equipment.
If the company does not have the in-house expertise with cloud migrations, it may be advised to enlist the skills of companies specializing in assisting companies moving to the cloud. Also, especially with larger projects, a project manager should be assigned to track and manage the undertaking.
Once you identify the pieces that need to move to the cloud, you need to decide what cloud delivery model you want to use. If you're hosting applications on-prem, do you continue to host the same applications in the cloud using an IaaS model? Or do you offload some of the responsibility to the cloud provider by using a PaaS model? For example, you may have a custom application written in Python. You can continue to run it in VMs as you always have, but just in the cloud using an IaaS model. Or you may instead run it in the cloud without having to bother with the VMs—the PaaS model.
Also, you may decide that now's a good time to ditch some of your current applications and use an SaaS model where the cloud provider manages the back-end IT infrastructure. With this information, you can evaluate the many different cloud company's service offerings in the marketplace.
A common practice is to determine what less critical or low-risk applications could be good candidates to move to the cloud. These applications can be used as a validation or proof-of-concept project for your company.
As part of the preparation, keep the finance group involved from the start of the project. IT expenses and budgeting often are a significant expense for any company, from the smallest local mom-and-pop shop to multibillion conglomerates. The cloud computing pay-as-you-go utility cost models shift the expenses away from the large up-front capital expenditures of equipment, services, and software. Cloud computing requires little, if any, up-front capital costs, and costs are operational based on usage.
Choosing Elements and Objects in the Cloud
Before making plans to migrate anything to the cloud, it's important to decide whether you want to use the IaaS, PaaS, or SaaS model, or any combination thereof. The model you use will determine the specific cloud building blocks you'll have to put together. As you already know, IaaS leaves much of the work in your hands, making migrations more flexible but more complicated. On the other end of the spectrum, the SaaS model makes migrations quicker and easier, but at the cost of giving up control over the infrastructure.
Once you decide on the model, identify what services and capabilities are available in the cloud that fit your needs and requirements. As service providers have expanded their offerings and capabilities, understanding all your options has become almost overwhelming. Some of the largest public cloud companies have more than a thousand objects and services to choose from, with more being added regularly.
To give you an idea of the plethora of options, let's start with the IaaS model. When it comes to virtual servers, there are a variety of prebuilt OSs to choose from. On the virtual hardware side, you can choose CPU and GPU power, memory, storage volumes, and network I/O. On the network side, you have load balancing, DNS and DHCP services, routing, firewalls, network address translation (NAT), and more. For storage, most cloud companies offer block, object, and file storage.
When it comes to PaaS and SaaS models, your options are naturally more limited because the provider takes on more responsibility for the back-end infrastructure. However, it's not unusual for a provider to offer different services that seem to be very similar to one another. For example, cloud providers offer a variety of managed database services for different types of databases. Likewise, they may offer messaging or email services that
