Cloud computing has revolutionized IT, which in turn has led to a gradual shift in priorities among service providers and customers, starting with classic hosting service providers, who are increasingly becoming platform providers and no longer operate servers for individual customers.

Many startups and smaller service providers now see their opportunities, because customers are taking advantage of variety rather than committing to vendor tie-in, as in the past. Finally, customers are increasingly using approaches such as serverless computing and have completely stopped operating their own infrastructure.

Hardware Is a Pain

The customer has good reasons for doing without their own hardware. Maintaining and operating hardware is a troublesome, cost-intensive task. If you entrust this work to a platform provider, you can kill several birds with one stone. You get rid of the assets in the data center and save a considerable amount of paperwork. Moreover, clouds are even cheaper because providers pass on the savings they have made thanks to efficient processes to their customers.

The one flaw in the beauty of this setup is that the move from bare metal to the cloud does not simply happen on its own. If you have a mental image of cool admins sitting in their command centers with drinks in their hands, watching their apps move to the cloud, you definitely need a reality check. Migrating to a cloud environment is a tedious task, with many pitfalls just waiting for the admin to stumble into. In most cases it is not enough simply to create virtual machines (VMs) in the cloud and copy the data over (Figure 1).

Figure 1: Employing clouds is not complex, but migrating a workload that is not designed for the cloud is.

Cloud Services

A modern cloud offers many types of services. Classic Infrastructure as a Service (IaaS) offers virtual systems in the form of VMs or containers, to which you roll out your services as needed, just as on physical hosts. Therefore, almost all workloads that were previously running on the physical servers can be moved to an IaaS environment.

One point to keep in mind is that Pacemaker and others that rely on the principle of a service IP that simply moves to another host in the event of a failure are difficult to implement in clouds.

Additionally, IaaS can only leverage the benefits of cloud environments to a limited extent. Clouds today offer far more functionality. Platform as a Service (PaaS), serverless computing, and various other as-a-service offerings are designed to make life easier for administrators. In the context of moving to the cloud, such services almost inevitably play a role.

The central issue about which admins should be concerned from the beginning is time. The difference between whether you have time to plan for the move to the cloud or whether the move will be a head over heels affair (e.g., because data center contracts are expiring and a late decision was made to not extend them) is considerable. Of course, the task for people in a hurry is far more complex.

Here, I first show you the ways and means of moving from classic hosted setups to IaaS. I then turn to the question of how the services in a cloud can be used to make the setup better. Finally, I also look at design principles for those who can afford the luxury of starting out on a greenfield.

Assess Your Starting Position

For the example here, a company wants to move its entire workload to the cloud. Previously, it operated the application on rented servers from a standard hosting service provider. In such scenarios, admins often make bad decisions under the pressure of time.

Out of necessity, the admin begins to plan a direct migration by first converting the currently running systems to a hard disk image that is then uploaded into the cloud, and finally starting a new VM with that image. Sounds good, but read the "Why a Direct Move is Difficult" box to see why this approach doesn't work in most cases.

Why a Direct Move Is Difficult

If you are still running your applications on bare metal or self-hosted KVM or Xen VMs, you might think simply to create images of these VMs and use them directly in the cloud. Although this sounds like a good idea, in reality it usually leads to problems and a considerable loss of time – for both technical and practical reasons.

First, public clouds such as Amazon Web Services (AWS) or Azure and private clouds based on OpenStack expect certain formats for volumes or OS images. Additionally, clouds usually involve unwritten laws that determine how certain work steps need to be taken. Anyone who has assigned a static IP address to their static system, for example, would need to change this if the applications were to move to the cloud. In clouds, IP addresses are assigned exclusively by DHCP so that the virtual network itself can be managed and controlled by the cloud.

Clouds also expect the cloud-init tool on VMs, which is not present on a classic physical or virtual system. Moreover, various problems come to light when accessing hard disks, which are named differently depending on the distribution, have different paths, or are controlled in a strange way by /etc/fstab.

The number of pitfalls is gigantic. If you want to convert an existing VM into an image for a cloud, you can expect a huge amount of work, time, and overhead, and you will still probably not end up with completely satisfactory results (Figure 2).

Figure 2: Many things work differently in clouds, one good example being cloud-init, which handles much of the system configuration by retrieving data directly from the cloud APIs.

Even if you succeed in moving directly to the cloud, you probably have a highly specific VM that has been modified manually in several places. However, this contradicts the cloud mantra "automation first" and is not easily reproducible. In most cases, it is therefore not worth your while to convert an existing system to be operated in the cloud by hook or by crook.

Instead, admins would do well to adapt their workflows to suit the cloud. Step 1 in this procedure is an inventory that provides an overview of which systems your environment contains. Of course, this is best achieved if a Data Center Infrastructure Management (DCIM) system is present (e.g., NetBox [1]), which provides the relevant information at the push of a button.

However, such information systems are often missing, especially in conventional setups with historical growth. Your only option then is manual work. The better your inventory of the existing setup, the lower the risk of failure on moving to a cloud.