... a decade later:

Real cloud vendor lock-in is when you have decades of code written against a [cloud vendor] and you're getting charged outrageous [cloud] rates and it would also cost a fortune migrate.[sic]

A decade has to past first. Most start ups don't last 5 years. Statistically speaking he's right and if he's not, well, a project that lasted 10 years ought to be profitable so pay up. Not profitable? Then who cares that cloud lock-in broke the camels back. If it wasn't profitable enough to justify the investment needed to switch to another vendor then it wasn't profitable enough to begin with.

If anything, vendor lock-in is consistently underblown.

The thing Ive learned is that a lot of people have both a vested interest and a sort of stockholm syndrome with vendors (cloud or otherwise). If you spent tons of time learning AWSs special tooling, you are going to see everything as a nail if you catch my drift. Ive seen a few particular users here spend many threads defending their choices despite the often very logical criticisms levied against the "cloud everything" approach.

One thing I like to talk about to Cs is their strategy on capex vs opex, because honestly that determines quite a lot, but is often something engineers dont think about.

> The thing Ive learned is that a lot of people have both a vested interest and a sort of stockholm syndrome with vendors.

Not to mention “resume driven development”. Recruiters love cloud experience.

> I like to talk about to Cs is their strategy on capex vs opex, because honestly that determines quite a lot

For example?

The ultimate “vendor independence” is racking your own servers in your own on-prem data centre with multiple internet connections. Very high capex, potentially low opex depending on scale. In the middle would be racking your own servers at multiple DCs. Less capex (you’re still buying servers, but not air handlers and power distribution), higher monthly opex. On the other end are things like GCP and AWS, where you have virtually no capex but relatively high opex.

And in the end, it really depends on how much you trust different vendors and how you want to manage cash flows. Racking your own servers reduces some risks (Google deciding to terminate your account on a whim, Azure pushing wild updates, Amazon jacking prices wildly) while increasing other risks (only your own staff are watching your hardware).

You are painting an incomplete picture. Between high (racking your own servers at multiple DCs) & very-high (your own DCs) CapEx options and low CapEx options (IaaS and PaaS), there is a middle ground that - unless you need specific managed services, the larger PaaS ecosystem and/or an extreme scalability - is to use bare-metal cloud providers. This approach combines multiple benefits, including bare metal's max. performance, full isolation / no "noisy neighbors", pretty much total control of the equipment that you rent, cloud-like elasticity, flexible, usually globally distributed, network architecture and reasonable pricing.

Totally true :). It's a spectrum and there's a ton of options in the middle. I was mostly pointing out the extremes.

Yes. This becomes clear when the cloud costs rise to be the largest burn in your budget and the runway keeps getting shorter and you can't migrate away because your code has tendrils deep into every AWS crevice...

Any company after a decade is going to have growing pains.

Spend your early time working on your core business. If your core business isn't cloud agnosticism then you shouldn't be investing your resources there.

Vendor lock-in depends heavily on exactly what vendor you’re using and especially if it’s OSS API hosted on the vendor or a vendor API.

If you use something like AppEngine to run a Flask or Django app, you will not be locked in much because those are open source libraries with well known runtime options elsewhere.

Same to some extent with any sort of managed OSS database.

If you use something like Cloud Datastore or Firestore or DynamoDB , you are using a proprietary API and will have to rewrite all your client calls , or write an extensive shim, and probably significantly re architect to port.

Even in the “hosted OSS” option there are usually some vendor specific stuff but it can vary a lot. Something like AppEngine specifically used to be an absurd amount of API lock-in but has evolved over the years to be more of a general container runtime.

Cost involved really depends upon how you did it and the differences between what you're migrating to/from.

If all database access is compartmentalized and the two datastores are fairly similar then it can be pretty cheap. If you didn't compartmentalize it will be expensive. If their characteristics are different enough then your compartmentalization will probably fall down in some cases and it will probably be expensive, although not as expensive if it weren't compartmentalized.

If you have a DAO layer in your code, it shouldn't be too significant of a refactor to switch between noSQL vendors for simple tables.

The real heavy lifting would be if you've optimized your tables to that specific architecture. You might need to re-design a lot of your schemas.

My worry with these providers is I get locked out of my accounts for some arbitrary reason or bug.

Yeah and in the case of google, good luck finding support.