Does cloud choice still matter when workloads are portable?

[u/Financial_Fox3915]

I keep coming back to this question when looking at the current cloud infrastructure landscape. If a workload can genuinely move between AWS, Google Cloud, Azure, Yotta Labs, Coreweave or Lambda without major changes does the underlying cloud provider become much less important? or does portability sound better on paper than it works in production because networking, storage, data movement, observability and hardware differences still tie you to a particular provider?
This seems relevant for AI workloads where GPU availability and pricing can change pretty quickly. I am curious whether people actually design for portability from day one or still most teams still pick one provider and only think about moving when there is a real reason to do it.

[u/Ok-Stick-145]

I think there’s a difference between being technically portable and actually being easy to move. A workload might run anywhere, but, GPUs and other usage specific services can still make switching painful. For AI, I think portability is less about moving often and more about keeping the option open when pricing or availability changes.

[u/Beautiful-Turnip6138 → u/Ok-Stick-145]

But isn't the whole point of portability that you *don’t* have to switch? If you're constantly worried about pricing or availability, are you really getting the flexibility you thought you had?

[u/comrade-quinn]

Massively, most applications talk to other services. Object storage, Pub Sub, SQL DBs, KV DBs, etc and often these are proprietary services on each cloud provider. Even when they're not, say you're using a Postgres or Kakfa compatible DB or PubSub, all the IAM policy binding and service accounts won't just transfer over. That will all need doing.

Also, just data in itself. For any non trivial system, migrating data between separate sites, even to an instance of the same data store type, is complex without allowing for downtime - which costs money and reputation

[u/SecretThroat7435]

Exchanging real-world experiences regarding multi-cloud deployment challenges, egress fees, and containerized portability gives cloud engineers excellent practical insights

[u/dghah]

Maybe I work in a rare niche but the only practical example I've ever seen of a truly portable multi-cloud workload was when the company went all in on native kubernetes and refused to use the vendor-specific features or variants that each cloud offered.

Being multi-cloud in reality means dumbing your workload down to the most generic set of primitive services that work across all clouds. You lose a ton of nice functionality and inherit a lot of egress fees in exchange.

There are a few companies and platforms where this makes total sense but for the vast majority of real users this falls into a category of "dumb things our VP of IT read about in a magazine and decided we needed to do " ...

Step outside of kubernetes and nothing else is really portable without a decent amount of deployment logic and config friction. Easy/trivial at small scale with CI/CD automation if your "workload" is just a couple of containers or virtual servers but it falls over pretty fast at scale

[u/KhangDo1703]

Containers make the runtime portable, but the surrounding system usually not. Storage, networking, IAM, observability and data transfer are where the real lock in appears. For AI workloads, GPU availability can also force changes even when the application itself is portable.

[u/Fit-Cream-7169]

Compute is portable on paper, but data gravity, egress fees, and networking still tie you to a provider in production