And it's often worse for bigger companies. Startups can often just rewrite their crap. You can't do that overnight with several years worth of legacy systems if they rely on vendor-specific features.

The odds may be low, but there are vendor lockin scenarios that sink a company fast. Having experienced that once you don't want that sense of powerlessness again.

The part where I agree with the sentiment in this chain is where people try to avoid this by putting in big abstraction layers of custom crap.

It's possible to use Law of Demeter principles to keep the vendor details of a lot of subsystems from leaking across your entire app. But that requires architectural skills that are de-emphasized in the Ship Every Week world we live in.

(I'm not implying causality there, or maybe the causality is in the other direction. These things are hard to learn and harder to teach and if you can't get one thing you try something else.)

There's certainly a continuum here. The most minimal risk mitigation strategy is simply to use your own domain (as opposed to the vendor's domain), and that requires nearly zero effort. Unfortunately the team in that article made that mistake, and they're pretty honest about admitting it.

Assuming you don't make rookie mistakes at the beginning, you always can move to another platform - it's just a question of how much work it will take. Is it better to put that work in up front for the 0.01% chance you'll need it? I think not.

The recent 12 x Google Maps API price hike is another such "exception that proves the rule" apparently.

Over a sufficiently long time horizon, the chance is much greater than 0.01% and the longer you go without doing the work, the more it costs to do the work.

Sure, it's more a problem that bites you when you've become a big enterprise, but it bites hard, and some of us work in big enterprises on systems that could reasonably be operational for generations going forward (and perhaps have been going backwards.)

And that's the right choice in some cases. But the added up-front effort can be a lot less than the added reengineering effort, and growing into a big enterprise doesn't mean you are immune to disruption by more agile startups.

And, of course, those who are already in big enterprises have different concerns (while premature adoption of the mitigations at issue can be engineering resume padding in startups, deferring it with the hope that it won't be a crisis until it's someone else's problem in exchange for short-term metrics can just as easily be management resume padding in enterprises.)

I don't think it's 100x or even 20x less work.

Depending on your perspective, that might also be a small amount, but let's not misrepresent the situation.

The anchor in the metaphor is using large tech conglomerate without being able to quickly pivot away from them at a moment's notice.

How much did it cost to engineer your product to not "tie an anchor"?

My guess is, you didn't "save" anything trying to build out several layers of abstraction to deal with a hypothetical risk of getting screwed by "large tech conglomerates".

Spoiler: Answer will be "no".