The elusive dream of cloud portability: Why migrating workloads isn't so simple One of the promises of the public cloud was that customers would be able to migrate workloads if they wished, taking advantage of market freedom to switch to a different provider if it offered lower costs or some other advantage. What happened to that dream? Cloud services are nearly 20 years old, if the launch of Amazon S3 in …
I've operated multi-cloud systems before to take advantage of things that were better or cheaper on a different cloud provider. I didn't really like having to do that, but if it saves a lot of money, it can make sense. Of course, it is like any other development challenge. To do it, you have to actually know about the differences, meaning that you will have to read the docs and pricing pages and set up test systems on multiple providers, not just one. That takes time and effort, so unless that's worth expending, a lot of people won't do it. In a lot of cases, companies attach themselves to one cloud provider not because they have to, not because it's the best one, but out of inertia alone.
On prem isn't really an exception to this either. My multi-cloud systems sometimes include our own server room as one of the places where servers live, and I've seen companies lock themselves into one approach that includes self-hosting the hardware, for instance one where they insisted on self-hosting hardware in a location with network links that couldn't really handle the traffic they were getting from the internet. This is why I prefer to be a programmer, not an administrator.
A long article about a topic I have been discussing here for years: friction. Every time I hear "Windows uses will move to Linux!" I scoff and laugh at them, and all the Linuxheads here get all upset.
This isn't the 1980's where we chose Amiga, Apple, BBC, Commodore or any other choice of dozens of incompatible systems and made a switch, a switch made easy by a limited number of applications we were invested in. VisiCalc was VisiCalc on a variety of systems and with a simple UI the learning curve was equal and skills transferable.
Switching from Windows to Linux involves a tremendous commitment in time and resources because of friction; from hardware to new system paradigms to new applications and UI's, the frictional losses involved are a huge hit tob productivity until all aspects of the project are up to speed. "Just switch to Linux and use LibreOffice" doesn't factor in the frictional losses of implementing the new system and then the user becoming familiar with the irrational differences - it might be OK for the home user / hobbyist who has time on their hands but business is notoriously impatient.
This also applies to switching cloud providers. Getting all aspects of the migration project back up to the level of productivity that you left behind is not guaranteed to stay on the targeted schedule, and all that means is that management is weighing ROI on any system changes proposed. And, time being money, you'll find that they aren't happy with the idea of an ROI based upon projections that can't be assured. So, from a management perspective, staying with the status quo can be calculated in costs but other choices are a great unknown of risks and dangers; very few people get fired for having a system that works, today.
While get your point, the friction that OneDrive/SharePoint has created in place of proper shared drives is every bit as severe. Maybe worse, because it's impacting collaboration.
An awful lot of biz applications outside of MS office are browser based and as such switching desktops is a lot easier than it would have been in 2004.
I don't even keep windows in the home lab anymore. I would not have thought myself saying that 10 years ago.
Falls in to the usual trap of assuming most corporate applications are built, not bought. The reverse is true. I reckon that 90+% of applications corporates are running are 3rd party authored packages written by ISVs. And 70% of them run on Windows. These apps live on VMs and the question of how they can be deployed or ‘modernised’ is dependent entirely on what the ISV is prepared to support. So the ability to move a 3rd party app from an VM in Azure to a VM in GCP to a VM in AWS is what matters. And that isn’t super hard, once you have landing zones etc in place. It tends to come down to skills within the companies IT org and what they are happy/familiar with.
When CMA is going to look at actual problems in the market?
It's like they are looking at breads and concluded that breads taste different and so if someone gets used to one particular bread, it is more difficult to switch to cheaper one, because it tastes different.
I also heard CMA found that water is wet!
What is the point of that institution?
...moving these is perhaps a little easier, barring details like having to make changes to their networking connections with the outside world. But working like this is perhaps losing some of the promised benefits of moving to the cloud
Which is why so many of us warned that those promised benefits were smoke and mirrors. For every dollar saved in infrastructure costs we've spent two on porting things and redesigning things - and for five years now everyone in management has said that "This is just the transition cost, once we've moved everything then we'll start seeing the benefit" except that the year this "benefit" is supposed to show up keeps slipping, and we've had to start purchasing hardware again to fill in the gaps.
Hardware that should have been replaced two years ago has started to actually age out and fail and the "cloud native" replacements still aren't ready. We keep finding more and more things we have to buy on top of what was already budgeted for because each SaaS product only does about 90% of what the on-prem version did, so now we have to buy another thing as well and then write some glue to stick them together.
If "moving to the cloud" was going to save us money we could have just stuck all the VM's we were running on prem in AWS about 5 years ago and moved on, but instead we're still redesigning and re-implementing all our services at massive expense to chase some benefit that's always another year away...
If you designed your application up front to be portable between Solaris, HP-UX and AIX, for instance, you had the freedom to choose between those platforms depending on which offered the best performance per dollar when you were buying servers, and were immune to being held hostage to an important vendor (say Oracle) who has worse pricing or allows versions to lag on one of your platforms.
The same is true for cloud, if you design/test everything on the three major clouds then you retain the option to switch clouds for better pricing, or to provide resiliency in case one cloud goes down (one of those "should never happen" things that seems to happen regardless)
But this approach takes longer, and costs more, because you have to develop against multiple clouds whereas the goal of getting the project done in the least time would have you just sprint towards the end in one cloud and say "we'll port to the other clouds someday" but someday never arrives. Thus most companies are locked in to one cloud, just like most companies were locked in to one Unix back in the 90s.
>If you designed your application up front to be portable between Solaris, HP-UX and AIX,
If you designed your application up front to be portable and simultaneously tested in during development on Solaris, HP-UX and AIX,....
Unless you develop and test cross-platform from the outset, "designing to be portable" just gets you something that "should work".
More talented readers may have had more luck with "design" that me.
This isn't actually so very difficult once you got the right mindset. Move all your system-interacting for the project to one file or a small set of well-defined files, and work hard to reduce your assumptions and dependencies. On top of that the Unix world got POSIX/SUS going, making that easier again. It does require the right tools. E.g. it's much easier porting software written on one of the BSDs to linux than the reverse, because linux is full of "all the world is linux anyway" assumptions, possibly inherited from the gnu tools and their assumptions. Related is that you should be using basic Makefiles rather than your favourite all-singing all-dancing make system and fancy configuration management that itself induces more porting effort.
I guess we'll be seeing some sort of portable cloud interface specification eventually. It's really a problem of our own making. But hey, solve it in software, right? Then why is that suddenly Just Too Much Work? This seems to be one of those software industry koans that make cloud providers fortunes.
It is absolutely possible to design cloud architecture so that it is portable between cloud vendors and on prem. It means that you must ignore some of the cloud offerings and try to keep things contains in services that are similar, but I have been involved in lift and shift between these three points and it works if the requirement is considered and designed in from the start.
By "design" I thought I was implying "testing during development" but perhaps adherents to more recent hype trends like agile/scrum/devops that emphasize quickly rolling out new versions and letting the end user do the testing may not assume what I felt was obvious.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
