It depends on the industry. A lot of retail companies are moving away from Amazon to avoid having competitive data flow through AWS infrastructure. Some companies may have different business units across different cloud providers but push for strategic consolidation on a major cloud provider for new implementations.

The heavier the use of cloud native solutions and managed services, the greater the effort to migrate away from those solutions. Not all workloads run on containers, and even then those applications will need some code refactoring if they depend on cloud infrastructure services (cloud specific storage, queue services, monitoring, etc)

Retail companies like Walmart are driving more movement than you'd expect since they aren't only moving their own compute from AWS, they're requiring their own tech partners and vendors to provide them non-AWS-based alternatives as well. I've been on several migration/training projects for companies with large retail customers since they hadn't had time to build the sort of GCP or Azure expertise yet that they had around AWS.

That (first paragraph) sounds like a different issue than lock-in.

Anyone who is not concerned about lock in is a fool. There are many fools in business.

Any of the companies I've worked with (and I've worked with many) are large enough and have been around long enough to understand that re-architecting apps, doing lift-and-shifts, re-training employees, or anything like that is an inevitable cost of doing business that is going to happen every couple of years no matter what, so any time fretting about "lock in" would ultimately be a waste of time.

And perhaps more importantly to these companies, lock-in is more than worth it if it means benefiting from some real revenue or cost optimizations. Paying $3 to "unlock" from a platform is more than worth it if said platform gave me $5 of benefit.

> companies I've worked with (and I've worked with many) are large enough and have been around long enough to understand that re-architecting apps...is going to happen every couple of years no matter what

Like the commentator you responded to said. There are many fools in business.

On the contrary, I'd say if you're not re-architecting your apps every couple of years then you're at risk of falling behind.

I'm not talking about rebuilding everything from scratch, but making an active effort to do self introspection and ask yourself "we built this app 3 years ago with certain requirements in mind and chose stack X to host it, but a lot has changed in the past 3 years, both in our requirements and in the technology landscape. Should we still be using stack X or does something else fit our needs better?" is unequivocally a good practice.

I would note that F500 companies are going to have the resources to move out of lock in if it came down to it, and AWS sales management knows it and would have to negotiate costs with that in mind. Smaller scale companies than the F500 that don't have that kind of leverage have to concern themselves more w/ lock-in.

Didn’t AWS just move some of their infrastructure off of oracle because it basically took them a decade to figure out how?

Yup, the interesting data point would be what did Amazon pay for their oracle usage vs smaller companies? I would guess that as long as Oracle gave them a reasonable price Amazon would be happy to stay on - except for a question of long term independence and vertical integration.

Amazon is probably in a unique position in that providing data and database services is a core competency, and so vertical integration off of Oracle makes a lot of sense even separate from the cost leverage question.

Yes and AWS also built multiple database types to meet their needs. Is your company going to do the same?

What? No, but that's my point. Even a company like Amazon was locked-in to a vendor. I'm not saying people should build their own databases but that this is a move in the right direction.

"Oops, your outgoing bandwidth is now 1000x more expensive"

I wouldn't worry about it. This doesn't happen. More likely to fail trying to be independent of all vendors than to be locked into a vendor.

It's only half a million dollars to egress 10 PB from S3. You'll be fine.

I wouldn't worry about global pandemics. They don't happen.

It's also worth keeping in mind that Amazon themselves are a poster child of this kind of thing, with their Oracle migration. If it took them a decade, what hope do you have?

Oh yeah, definitely. Definitely do not plan for that eventuality. Right now, we're in one so you have to be aware but when not in one, don't plan for it or mitigate that risk in any appreciable form.

It is easily 10x harder to migrate from on-prem to a cloud, than it is to migrate between clouds. The big cloud providers are all functionally REALLY similar, if you're mostly using the big components:

- Object storage is basically identical, often even down to common API wrappers

- VMs are VMs

- Kubernetes is Kubernetes. Containers are containers.

- EMR is Dataproc is whatever Azure has

- BigQuery is Redshift is whatever Azure provides. It's big SQL. Whatever.

Like, I'm not saying there isn't a cost, or it's pain-free... but you're not re-engineering everything when you migrate. You're finding fiddly difference between platforms, and if you're an enterprise, your new cloud provider would LOVE to help you with that migration.

Just tell that to your PMO and have them give you an estimate about how long it will take to migrate. Then talk to your developers and infrastructure folks and let them do a (bad) estimation about how long it will take to remove all of the hidden dependencies.

That’s not even including the training involved. At the same time, your competitors are actually trying to create products that meet their customers needs while your resources are tied up in migrations.

> Just tell that to your PMO and have them give you an estimate about how long it will take to migrate.

Ask the same in your own infrastructure. They'll give even worse estimate.

The thing with the cloud, is that it's public, they all follow the same stuff and their goal is for you to migrate to them. They got an hundred similar situation as yours.

> At the same time, your competitors are actually trying to create products that meet their customers needs while your resources are tied up in migrations.

How is that different from your own infrastructure? If you have to migrate, you have to migrate... whatever is the source and whatever is the destination, migration is migration.

That’s true and this isn’t an AWS vs Azure vs GCP argument.

Once you decide to move from on prem to either of the cloud providers you get the benefits of being able to take advantage of scale efficiencies, letting another company do the “undifferentiated heavy”, elasticity (not having to provision for peak capacity), a global infrastructure, quick provisioning of resources etc.

Yes depending on your use case, you can gain benefits from moving off prem/colo to any cloud provider. The benefit once you move to any of the providers to switch providers is negligible.

Everything in life is about risk vs reward.

Platform lock in is a risk. The reward is faster time to market, thus making more money earlier, thus having more means to ameliorate your risks.

Imagined faster time to market. In reality, you just end up spending more time trying to debug black boxes.

I think you must have a limited mindset of how long it can take wheels to turn in large companies. Without cloud, it's not uncommon for the F500s I've worked at to take literal months (90+ days) just to provision and stand up a new server for an application team to even begin developing on. Even if you spend time "debugging black boxes" (which is highly debatable), most of the time you're still moving a lot faster with cloud than before.

Some companies are better than others. One place I worked had a decent OpenStack implementation in their own data centers, and it greased the wheels a little bit (though it was not without its own issues). And of course smaller companies are likely more agile and able to move faster. But for the most part, these big companies see some very real benefits in speed by embracing public clouds.

Why don't they give the application team a few extra servers to do whatever on without asking for permission?

Because without good organizational controls, the developers will put those servers into production with no HA, backups, and insecure configuration.

I’ve seen it multiple times in my careeer.

That makes a lot of sense. I can see how using cloud solves for HA and backups. But how does insecure configuration come in?

While this makes sense what the parent comment said is also true.

I always wondered why big enterprise customers are not concerned about lock in. Maybe they cut multi year deals with the big cloud providers?

Have you ever been part of a large scale migration? Even if you try your best to avoid “lock in”. It’s still a multi year, expensive proposition and at the scale of a F500, it adds little business value.

Do you know how many third party services and offerings that the typical F500 depend on? More than 80% have a huge “lock in” to Microsoft.

You’re always locked into your infrastructure when you are at any type of scale. The cost and the risk of regressions hardly ever make it economically viable to migrate to another cloud provider.

How does avoiding “lock in” add business value either by reducing cost or increasing revenue.

Out of all the business risks that a company has, avoiding lock-in is the least of them.

Any big enough business have no trouble moving out from theses lock in though.

Lock-In is dead simple to avoid with AWS. Even with Lambda, which people tend to point to and say "lock-in!". Even now we've got lambdas running Docker containers.

It's a total boogeyman and I've never heard anyone care about it except on HN, where it comes up constantly.

You seem to be agreeing with parent comment, from where I stand. Lock-in may be simple to avoid, but not many people make any effort to avoid it ("There are many fools in business"). I mean, take a look at the number of companies/services that got knocked offline last week because AWS's us-east-1 was fucky: if they are "locked-in" to one AWS region, do you think they'd bother with decoupling from AWS tech in general?

So there's a reason for this that is unfortunate but true. AWS outages make the news and customers treat them like natural disasters. We host a few services on AWS but the bulk of our stuff is on-prem. When AWS has issues none of our customers cared -- they were annoyed that they couldn't do their work but were otherwise totally understanding and none of the blowback fell on us.

When one of our upstream ISPs had an outage and prevented some of customers from being able to reach us people were mad at us even after the explanation. AWS is enough of a household name that you can say sorry "AWS is down right now" and people will sympathize.

first , it is real. second, it is very much a concern. we're buying game studios, and, if their projects are using Amazon-specific technologies( gamelift, f.e) we know it's an uphill battle to profitability ; games are low margin enough to take hosting and bandwidth costs into account

That must be why nobody buys Oralce, or SAP, or mainframes.

I've not been at a place while they got sold on Oracle, but I've been at one that was desperately working to get away from it. Over 15 years the relationship went from amicable to "Oracle reps are in town this week, give management a wide berth" announcements.

Anyone who is concerned about lock in is a fool. There are many fools in business.

It's not about lock in or getting access to the side-show features available in other clouds. For a large company there is significant business risk in having all your infrastructure in one place. A billing error or some other misunderstanding could have catastrophic consequences. I've heard of absurdly close calls here. I know that one public company dependent on AWS maintains multiple accounts to lower the risk of this happening. Multi-cloud is another way to mitigate that risk.

TripAdvisor had a very strong “no lock in” policy that impacted the technical stacks we could keep/choose when we got bought by them.

We could use an nginx installed and maintained on EC2 by ourselves but not the AWS flavor on it, or I guess we’d have needed to fight to get an exception.

That’s just an anecdote, but I am sure more companies put real money behind getting “locked in”.

Did avoiding lock in do anything as far as making them more competitive in the marketplace?

How many man hours was spent babysitting infrastructure?

> But "lock in", IME, is only something people fret about on HN.

Lock in is a _very real problem_, but often you hear on HN scare mongering that making any decision at all is "lock in".

This is my experience as well. It is definitely one of the things that HN worries a lot more about than any CTO I know from tiny startups to billion dollar businesses.

Where I work, lock-in is actually embraced. Homogeneity is valuable. It is a boogeyman in HN but the concern does have merit, for sure.

I used to be very careful / strict with the lock-in. But not anymore. You have to compare the cost of an hypothetical migration to something else to the cost of not using the capability of the platform to its full capacity. I read somewhere here that accepting vendor lockin is being a fool. I would say that paying aws prices without benefiting from any of their great stuff is also not very clever.

Fortune 500 sure. But mid and small business have 0 negotiation power, it's extremely expensive to migrate data, and they can't afford a legal battle(as threat).

IME (my experience) -- Lock-in was really about APPs in the 90s and 2000s... JDE Edwards, IBM AS 400, etc...

AWS is a substrate platform, thus is does not look like lock-in in any other respect other that price.

if you marry with Oracle, JDE, AS-400 etc you are mapped to an APP and not a platform on which you can build WTF you want... so only noobs think of AWS as a lock-in because they are only looking a price/cost as opposed to the entire ripple effect of what it means to move/migrate core ops (typically finOps) between platforms...

Look at the underlying phys infra thats required to do at scale shit...

Thats the cost benefit analysis thats really overlooked. That hourly cost per comput/service/resource is mortgaging a SHIT TON of physical infrastructure that would cost a single company MILLIONS - yet - Amzn is literally investing everything that one company should in physical and digital security and executing it well...

And for that, I respect them and support them.

Anecdotal: I once had a dev (I was DEVOPS director) check in creds to github after it was the 251st repo (where our account only paid for 250) and by default at the time, Git made any repos above your account limit public, and bots scanned ALL of these - they got our creds in this devs post, and launched - from Germany - THOUSANDS of G-class instances for bitcoin mining.....

Anyway, an all-nighter - but Amazon refunded / canceled the tens of thousands of dollars in compute time without hesitation....

Cloudability proved to also be an invaluable resource - and While I am concerned over the bezos-new-world, Amazon never fails to make me appreciate their customer service... (they sent me the wrong SSD and sent me a new one, refunded my money and sent me a second one as well....)

AWS/Azure lock in is more about data than platform.

Fortune 500 have lot of data and while its free to move data to a particular cloud provider they pay a bomb to take it out.

Good point, but begs the question; how fix?

maybe there is a market for JUST data migration/storage/translation service?

Such that you can be a data miration/router first hop - and then pipe to AWS/GCP/MS at will - then an overlay which launches the overlay infra on demand depending on which rout you want to take...? Layer 9