Why moving all your workloads to the cloud is a bad idea

In the third installment in this series on common pitfalls of moving to the cloud, learn how to figure out which applications you shouldn't migrate.
293 readers like this.
Introduction to the Domain Name System (DNS)

Jason Baker. CC BY-SA 4.0. Source: Cloud, Globe. Both CC0.

As we've been exploring in this series, cloud hype is everywhere, telling you that migrating your applications to the cloud—including hybrid cloud and multicloud—is the way to ensure a digital future for your business. This hype rarely dives into the pitfalls of moving to the cloud, nor considers the daily work of enhancing your customer's experience and agile delivery of new and legacy applications.

In part one of this series, we covered basic definitions (to level the playing field). We outlined our views on hybrid cloud and multi-cloud, making sure to show the dividing lines between the two. This set the stage for part two, where we discussed the first of three pitfalls: Why cost is not always the obvious motivator for moving to the cloud.

In part three, we'll look at the second pitfall: Why moving all your workloads to the cloud is a bad idea.

Everything's better in the cloud?

There's a misconception that everything will benefit from running in the cloud. All workloads are not equal, and not all workloads will see a measurable effect on the bottom line from moving to the cloud.

As InformationWeek wrote, "Not all business applications should migrate to the cloud, and enterprises must determine which apps are best suited to a cloud environment." This is a hard fact that the utility company in part two of this series learned when labor costs rose while trying to move applications to the cloud. Discovering this was not a viable solution, the utility company backed up and reevaluated its applications. It found some applications were not heavily used and others had data ownership and compliance issues. Some of its applications were not certified for use in a cloud environment.

Sometimes running applications in the cloud is not physically possible, but other times it's not financially viable to run in the cloud.

Imagine a fictional online travel company. As its business grew, it expanded its on-premises hosting capacity to over 40,000 servers. It eventually became a question of expanding resources by purchasing a data center at a time, not a rack at a time. Its business consumes bandwidth at such volumes that cloud pricing models based on bandwidth usage remain prohibitive.

Get a baseline

Sometimes running applications in the cloud is not physically possible, but other times it's not financially viable to run in the cloud.
As these examples show, nothing is more important than having a thorough understanding of your application landscape. Along with a having good understanding of what applications need to migrate to the cloud, you also need to understand current IT environments, know your present level of resources, and estimate your costs for moving.

Understanding your baseline–each application's current situation and performance requirements (network, storage, CPU, memory, application and infrastructure behavior under load, etc.)–gives you the tools to make the right decision.

If you're running servers with single-digit CPU utilization due to complex acquisition processes, a cloud with on-demand resourcing might be a great idea. However, first ask these questions:

  • How long did this low-utilization exist?
  • Why wasn't it caught earlier?
  • Isn't there a process or effective monitoring in place?
  • Do you really need a cloud to fix this? Or just a better process for both getting and managing your resources?
  • Will you have a better process in the cloud?

Are containers necessary?

Many believe you need containers to be successful in the cloud. This popular catchphrase sums it up nicely, "We crammed this monolith into a container and called it a microservice."

Containers are a means to an end, and using containers doesn't mean your organization is capable of running maturely in the cloud. It's not about the technology involved, it's about applications that often were written in days gone by with technology that's now outdated. If you put a tire fire into a container and then put that container on a container platform to ship, it's still functionality that someone is using.

Is that fire easier to extinguish now? These container fires just create more challenges for your DevOps teams, who are already struggling to keep up with all the changes being pushed through an organization moving everything into the cloud.

Note, it's not necessarily a bad decision to move legacy workloads into the cloud, nor is it a bad idea to containerize them. It's about weighing the benefits and the downsides, assessing the options available, and making the right choices for each of your workloads.

Coming up

In part four of this series, we'll describe the third and final pitfall everyone should avoid with hybrid multi-cloud. Find out what the cloud means for your data.

User profile image.
Eric is Red Hat’s Portfolio Architect Technical Director. He's renowned in the development community as a speaker, lecturer, author, and baseball expert. In his current role allows him to share his knowledge of Red Hat’s open source technologies and cloud computing.


A DMZ is better than the cloud. For one thing, it (potentially) has better security. Use the cloud only if you can't afford a DMZ.

I'm not sure that in-house means not on cloud. At the scale of 40,000 servers if in-house wasn't at some level synonymous with cloud in 2018 I'd be worried.

There are of course predictable workloads that might leverage mainframes or workstations, most companies don't want or need to get rid of that, but just from a risk management perspective being able to rapidly deploy (even if it's just re-deploy onto HW you already own) is going to be important.

The "cloud" has been understood to mean someone else's computer (server). Moving ANY data or processes to to someone else's hardware is a bad idea! You could easily lose all control of said data or processes, and you have no security as soon as anything leaves your own hardware. The whole idea of the "cloud" or "cloud computing" has always been a VERY BAD IDEA!!

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.