The lockin happens when DevOps gets lazy and start using a bunch of cloudy functions.
Have you ever done a large migration at scale? I have - even moving over a lot of VM hosted services involves your project management organization, regression testing, networking, firewall, training, security, working with outside vendors, and the list goes on.
The average enterprise uses 254 SaaS servers. I have never in 5 years heard any CTO of any company of any size worry about “lock in” when considering their cloud choices.
Source: 2 years as an architect responsible for integrating acquired companies before a private equity owned company went public, two years leading the “application modernization” effort at a startup that exited 10x revenue, 3 years working at AWS in the Professional Services department and now working at a smaller consulting shop.
And I got Amazoned a couple of months ago. I have no particular loyalty toward Amazon
That's where the lock-in is, Kubernetes vs VMs isn't that big a deal at all; annoying sure. For the record, my employer uses both Kubernetes and VM. The deployment is pretty much the same.
Everyone here is completely ignoring the organization complexities.
Developer time is very, very expensive, and any time you spend "migrating" is time not spent building features that add value. Except in rare cases, the end customer probably doesn't care if your stuff runs on AWS, GCP, or Azure.
Are you going to suggest that your medical software doesn’t integrate with third party EMH/EMR systems? That your call center and sales team doesn’t integrate with Salesforce?
What about your dependency on Workday? ServiceNow? Your project management software? All of the Microsoft software?
Yes even VMWare. There is a reason that AWS has a VMWare offering.
Exactly my experience. Some services I manage are still entrenched in Big Co. Cloud, and it's a hell. This lock-in costs us additional money (thousands per year), but that amount is less than it would cost us to migrate those apps immediately.
Unix is cool not because it's a Unix, but because it's simple, aka Unix Philosophy.
The hairy stuff is when you get into the highly specific offerings for each SaaS platform. They all offer a ton of them and they can certainly be attractive for some cases (ie. Filehosting) or useless in others (there's a lot of stuff that amounts to "our version of cache/database" and little else) but that's where the lock-in issues tend to play up.
GCP is uniquely terrible though from what I've heard in terms of support lifespan and utter unhelpfulness in terms of communicating to their customers when some SaaS offering of theirs are on the chopping block.
The reality though is that most tech stacks aren't that complicated. Not every company is a venture capital "go big or go bust, we change the entire industry" darling (nor are they necessarily looking to grow that way, especially outside the SV bubble) or a government with 2000 different contracts and enough yellow tape + bureaucracy around those contracts that signing a new contract is just easier than possibly extending an existing one with new features.
For the rest of those tech stacks (which are definitely "enterprise", simply by definition, since they get used in companies and are bespoke enough to be their own tools), it's rare to see a stack more complex than the one I mentioned (backend, cache, db) unless a technical admin decided to play runaway with Azure/Google/Amazon because it's shiny and exciting.
In those cases, the vendor lock-in from using a bespoke AWS or Azure solution are absolutely worth it because if AWS or Azure are an active problem they also will have the manpower to migrate off of AWS/Azure. My suggestion/advice is for the other 99%. You still want AWS/Azure for CYA, the managed part (not having to deal with ops) and backups but you don't need all the extra solutions they offer.
It's why "you are not Google" is an advice that exists. Newbies often tend to assume that because [big company/VC startup] is willing to eat the potential risk of a lock-in gone awry that the [smaller company] they work for/founded is able to eat it as well. There's definitely a usecase for all the specific services that GCP/Azure/AWS offer. Chances are though that you're not working for a company where that's the case and the more conventional tools will do just fine.
(VC Startups tend to ignore that advice mostly because they have a lot of financial resources to spend upfront, so they think it's worthwhile/that they will hit that point where GCP/Azure/AWS services become a necessity compared to a traditional tech stack.)
Startups should use whatever technology that gets them to market fastest and the last thing they should be worried about is “lock-in”.
If they find product market fit and get customers, in normal times the money will come. Why worry about the “undifferentiated heavy lifting”?
Sure for Dropbox or BackBlaze, managing storage is their competitive advantage for instance.
But creating a AbstractFactoryRepositoryKeyValueFacade to avoid a DynanoDB dependency makes absolutely no sense.
The company I got laid off just decided they are going multi-cloud and that anything on their original cloud offering which is vendor specific is verboten in the middle of multiple in flight projects which now probably will never complete because they basically just did it by fiat in an unfunded mandate; no new deadlines, no new thought around how.
Is it giving your former company a competitive advantage?
People are loss averse to decisions that they made about things that are completely unrealized, it makes no sense.