The myth of the workload movement

Post • 4 min read
Before you invest your time and money into hybrid cloud, you should understand the realities in workload movement between clouds. Who wouldn’t want to be able to move apps between clouds based on your own needs, not to mention that you wouldn't need to do a single migration project again. So you've moved your apps to containers, invested in a Cloud Management Platform (the brokerage engine for your clouds) and you're all set. Unfortunately, no. Even if you would have the technical possibility to move workloads, there are few critical topics that render it unusable in real life.

Let's start with some basic facts:

  • Your existing apps are not built with workload movement in mind.
  • Even the new applications need to be designed and built with workload movement in mind in order for that to work. And that comes with a cost.
  • Every cloud is a silo with its own features, tweaks, cost optimization options etc.

So what are the difficulties with workload movement?

First is your deployment processes – a pretty normal step in any change (including migration) is to plan, design, implement and validate. For you to benefit from workload movement, you need to minimize these steps. Let's assume you get a 10% cost saving by moving to a new cloud. How much of the design, validation and coordination work can you fund with that? If you follow a DevOps process for your cloud native app, this is probably doable, but for your other apps this is big culture change or you'll burn most of your savings in the project whilst performing the change. Data – most apps you consider to be a candidate for workload movement probably contain data, and lots of it. The data synchronization brings two challenges you need to tackle - data consistency and data transfer time. If data consistency is crucial for you, you first need to move every single byte of data before switching over, which means that at some point you need to stop taking new data in, sync the data and then start taking data in again. This probably means a production break, which means planning and execution work, which means costs and delays. The second issue in some cases is simply the time it takes to sync data. It can take weeks and can require separate physical swing boxes. Platform dependencies – we're all supposed to use APIs that hide underlying technical implementation and thus make us less platform dependent. But the reality is that most of the APIs we use are unique, and those are the biggest competitive advantage of the cloud provider. You can write totally platform agnostic code, (that was the big promise from Java from about 20 years ago) but for various good reasons (time to market, cost, laziness etc) we tend to use platform specific features and functionalities. The rise of PaaS will further increase your platform dependency. We can be honest with ourselves and say that time and cost pressure in most apps dev project override any TCO, reusability and workload movement ambitions. They are not alike – even if you have the same stack at both ends (regardless if it’s Microsoft, Vmware or OpenStack based) they are not the same. A cloud consists of a large number of components and having the same versions of each component on both ends is not going to work. VM sizes are also different. Some workloads will move just fine, some not, but you need to plan and test. Skills – we’re in a global war for talent. Most companies have difficulties recruiting and developing skills for one cloud platform, so it's tough finding people who not only can handle containers on multiple clouds but also do that on scale. Cost optimization – private cloud and public cloud have very different cost drivers and optimization possibilities. Your cost optimization options include long-term commitments, licence cost savings, right-sizing etc, all reducing your ability to move workloads to a different place.

Getting your priorities right

Enabling true cloud brokerage and workload movement code can be achieved but at a high cost. In most cases, the reality is that workload movement requires a separate project that creates costs, delays and ultimately takes away real appetite to move the workload. At the end of the day, it’s all about your company’s priorities. Do you get the competitive benefit from cloud brokerage, or maybe using the same money to bring new services faster to market? Workload movement is a nice thing to have but has a little positive effect on your TCO. In this case, time to market and your apps dev cost are much bigger drivers.
  • To find out more about Hybrid cloud, read my blog 'How Hybrid do you need to be'  here 
  • Norcloud have been placed on the Gartner Magic Quadrant for the MSP journey for the second year, read more about it here
Nordcloud ninja
NordcloudLinkedInNinja
Related topics
CloudCloud

Get in Touch.

Let’s discuss how we can help with your cloud journey. Our experts are standing by to talk about your migration, modernisation, development and skills challenges.

Ilja Summala
Ilja Summala LinkedIn
CTO
Ilja’s passion and tech knowledge help customers transform how they manage infrastructure and develop apps in cloud.