If you believe the advertisements, it's easy to use the services of cloud providers like Amazon [1], Google [2], Microsoft [3], and others. At the same time, the marketing by these companies suggests that the way into the cloud is completely uncomplicated. In fact, moving to the cloud is often a multidimensional challenge. In this article, I highlight some of the hurdles and focus on the non-technical side.

Experts argue about what exactly the cloud is [4], but here, the cloud is understood to provide the capacity to store, transport, and process third-party data – or, in cloud jargon, storage, network, and compute.

Why Move?

Companies that want to move to the cloud should clarify a number of questions before making the switch. Among them: What problems relating to the local IT infrastructure do you expect the cloud to solve? What are the expectations? Which objectives should the change fulfill? Which criteria are important? Can these criteria be measured, and how is the measurement carried out? What happens if expectations are not fulfilled? What are the exit criteria? Moreover, few people think about an alternative in the event that cloud outsourcing does not work as desired.

A professional evaluation requires some research. Among other things, the myths of higher speed and greatly reduced costs in the cloud must be examined carefully – at least for your own use case. Expectations that broken business processes will magically repair themselves outside of your own IT infrastructure are bold at best, but probably misplaced.

I will take a look behind the scenes of a migration to the cloud from four perspectives to answer the question: Should I stay or should I go?

Software

One obvious question relates to software, which can be broken into two parts. The IT department has to consider the business application itself (i.e., the software used by the company to earn money), and it needs to look at the software that works behind the scenes: What technologies are used when it comes to updating, availability, or normal operation?

Business software is either a proprietary development or it comes from a third party. In the second case, you need to check whether the contracts allow operation outside the previous IT landscape and, if so, to what extent. Is the license or subscription limited to, say, a certain country, the EU, or other geographical regions or jurisdictions? Could the possibility of unlimited access to the infrastructure by employees of the cloud operator be a problem? Do prices change according to external use (Figure 1)? Does the manufacturer map operations on a mainly virtual infrastructure? These questions only touch the tip of the iceberg.

Figure 1: With Oracle, virtual CPUs in the cloud cost twice as much as physical CPUs.

If your company's business applications are developed in-house, you might be smiling because you would not have to concern yourself with most of the restrictions mentioned above; however, the overall situation remains complex. The central questions are: Does the software also run in the cloud? What does the company do if this is not the case? Generally, you have no valid recourse in the second case.

Alternatively, a "lift-and-shift" application simply runs unchanged on the new infrastructure because the large cloud providers meet almost every requirement: the provision of a virtual or physical infrastructure, a variable number of CPUs, a discretionary amount of RAM, the choice of Windows or Linux, different GPUs, and so on.

Opponents of lift and shift argue that a company gives up many advantages of being in the cloud and would have to face challenges that might be overcome with new development. For example, an interactive approach – possibly via a GUI – often scales less well outside the corporate IT environment and even causes unnecessary costs. Another possible challenge is data handling, but more about that later.

The essential points of cloud operations are infrastructure expectations and contractually guaranteed performance. Only rarely does a cloud user fall back on physically separate hardware, although it might be possible to implement CPU, RAM, and storage outside the cloud.

Availability

Another aspect is the reliability of the infrastructure, which also requires a thorough reading of the cloud provider's small print. Figure 2 shows an excerpt of the service description for Compute by Amazon Web Services (AWS) [5]. The section shown also includes the definition of regions and availability zones (AZs). If you take a close look, you will see that, from the AWS point of view, the failure of one AZ does not constitute a violation of the service agreement.

Figure 2: Excerpt of the service description for the AWS Elastic Container Service.

This situation is fatal if the region is small. London, for example, has only three AZs (Figure 3). AWS does not breach its service obligation here until the entire region is out of action, which can be a problem if the software is not allowed to leave the country: With AWS-only resources, the business application would be grounded.

Figure 3: New customers need to study Amazon's concept of AWS regions and availability zones in detail.

The expectations of your own IT infrastructure will typically be significantly higher. Three small data centers (DCs) located close to each other more or less correspond to the AWS region for London. Normally, the failure of a data center is not a negligible event.

A formal check of whether software or a software provider is suitable for the cloud is useful. A catalog of requirements should include, among other things, the questions already posed to this point, along with a selection and evaluation of possible answers. In the simplest case, you can create a document or a spreadsheet template to evaluate both the existing software and what you intend to purchase.

Depending on the vendor, the requirements can focus on the application manufacturer, rather than the application itself. It is important not to make exceptions, and the criteria in the catalog should be as objective as possible – even if they are specific to a company. This procedure can be easily generalized and extended to suppliers, business partners, and cloud providers.

The challenges presented here are intended to encourage you to prepare the topic thoroughly, not discourage you from setting out.