Four Pitfalls to Watch for when Migrating to the Cloud

By Weaveworks
February 20, 2020

Migrating an on-premises data center to cloud-based infrastructure is trickier than it seems. This post explains what the most common pitfalls are that can get in the way of achieving a successful cloud migration.

Related posts

Kubernetes Security - A Complete Guide to Securing Your Containers

KubeCon EU 2023 Recap – GitOps Sessions on Flux with OCI, Liquid Metal CI/CD Platforms & Telco Cloud Platforms

Extending GitOps Beyond Kubernetes with Terraform Controller

It’s easy to talk about why you should move to the cloud. But the how of migrating an on-premises data center to cloud-based infrastructure is trickier. Moving to the cloud is a complex process, and there are a lot of points at which things can go wrong.

That’s why it’s important to recognize the common pitfalls that can get in the way of a successful migration to the cloud. This article explains what the most frequent missteps are; this should help organizations empower themselves to achieve a successful migration to the cloud, free of the roadblocks that often arise along the way.

Pitfall 1: Not understanding your cloud workloads

Today’s cloud environments feature dozens of different types of services. They range from simple cloud-based virtual machines’ IaaS platforms and storage, to containers and serverless functions, and even to services for controlling satellites. (Yes, you can do that in the AWS cloud.)

The first instinct of many organizations migrating to the cloud is to select the cloud service that most closely resembles their existing on-premise environments, and move their workloads there.

While this approach works in some cases, it is a mistake in others. The optimal deployment method and architecture for on-premises applications is not always the same as that in the cloud. For example, just because your on-premises apps run on bare-metal servers doesn’t mean you need to host them on a bare-metal EC2 instance. If you do, you’ll probably end up paying a lot more money (since bare-metal hosting comes at a premium cost) than you would if you hosted the applications using less expensive virtual machines.

Likewise, refactoring or rebuilding applications during the migration to the cloud is sometimes necessary. Your current apps may be monoliths, but taking some time to refactor them to run as containers under a microservices architecture could lead to greater agility and performance when you move them to the cloud.

The bottom line: Think carefully about which cloud services are the best fit for your various apps. There are dozens of cloud services available, and the one that seems like the most obvious fit for your workloads may not be.

Pitfall 2: Not understanding costs

In an on-premises data center, costs are relatively straightforward. You pay for hardware up front, then pay on a recurring basis for whatever it costs you in staff time, electricity and replacement parts to maintain that hardware for the duration of its useful life.

In the cloud, however, costs are much murkier – even if they don’t seem that way on the surface. For example, you might think it’s easy to predict the cost of cloud storage, since most public clouds advertise simple-looking, per-gigabyte storage costs. But your actual costs can vary widely depending on factors such as: which cloud region you use to store data; which storage “tier” (hot, cool, cold or deep archive) you choose; and, how frequently you move data into and out of storage.

At the same time, it’s easy in the cloud to sign up for the wrong type of cloud service and end up paying for more than you actually need. You might choose a virtual machine instance that has more resources than your workload requires, for example. Or, you might choose to spin up more cloud-based databases than you need. Both of these mistakes mean wasted money.

This doesn’t mean the cloud will end up being more costly. Often, it saves money in the long run. But it does mean that a cost-effective cloud strategy requires careful planning and analysis.

Pitfall 3: Relying on PaaS solutions

The primary goal of many companies as they move to the cloud is to leverage IaaS (Infrastructure as a Service) to replace their on-premises infrastructure. That’s a great thing to do in many cases. However, if you focus on just IaaS, you miss out on the full value that the cloud can deliver. Although PaaS (Platform as a Service) solutions sound like a panacea selling a seamless process for developing and deploying code directly in the cloud, you will miss out on the many open source projects out there that you can leverage to fully unlock cloud native potential.

The cloud native foundation is home to Kubernetes and many other compatible projects such as Helm the package manager, Flux a GitOps powered continuous delivery tool and other solutions that can be combined to create an integrated and powerful cloud native platform.

Pitfall 4: Cloud migration in isolation

It’s one thing to move workloads to the cloud. It’s another to build the culture and processes within your IT team that will sustain those workloads over the long term.

In other words, don’t make the mistake of assuming that the culture and processes that work for supporting your on-premises workloads will work just as well for the cloud. The cloud requires different ways of thinking and different tooling in many respects. It demands an ability to act more quickly – and, ideally, to embrace the “continuous” mantra that is at the core of the DevOps philosophy, a cultural paradigm that goes hand-in-hand with the cloud.

Measuring a successful cloud migration

How do you know when your cloud migration is successful? Not getting trapped in any of the pitfalls described above is part of the answer, of course. But so is being able to leverage the key benefits that the cloud brings, including:

  • The ability to expand technology and scale workloads without depending on capital expenditures.
  • Freedom from traditional upgrade cycles.
  • The ability to use new hardware and software instantly, instead of having to plan months or years out.
  • Scalability concerns – not just for specific workloads, but for entire teams and processes – become a thing of the past.
  • Disaster recovery and high availability are easier to achieve because they do not require complex on-premises infrastructure spread across multiple data centers.

When you have achieved all of the above, you know that your cloud migration has been successful.

At that point, you can begin working to optimize your cloud strategy in order to get even more out of it. Reassess the cloud services you are using to determine whether they are still the best fit. Consider refactoring your applications further, in order to enable an even greater degree of dynamism and reliability. Keep on top of the latest new services and features offered by cloud providers to ensure that you are continuing to get the most value possible from the cloud.

When you approach your cloud migration in a purposeful way, and with these tenets in mind, you position yourself for long-term cloud success – as opposed to a half-baked effort to migrate to the cloud just because everyone is talking about why you should.

Have questions on what you need to create a cloud native platform?

The Weaveworks team can help you simplify and integrate applications from the vast landscape of cloud native technologies both OSS and paid. Together we can create a cloud native reference architecture and platform that fits your business needs. Manage a secure, up to date and fully integrated Kubernetes platform in git using GitOps.

Contact us for a demo of the Weave Kubernetes Platform or check out our Quickstart program to help you get up and running with Kubernetes.


Related posts

Kubernetes Security - A Complete Guide to Securing Your Containers

KubeCon EU 2023 Recap – GitOps Sessions on Flux with OCI, Liquid Metal CI/CD Platforms & Telco Cloud Platforms

Extending GitOps Beyond Kubernetes with Terraform Controller

What does a cloud native platform look like? Learn more in the whitepaper - Scaling up the Enterprise.