One of the most frequent objections/benefits/discussion points in software is the idea of “lock-in.” This usually means “if I pay someone for something, I’m using something only they have, and I’ll be locked into it.” With public cloud, it applies to cloud services as well. I’m never really bought into lock-in as a huge deal. I think there’s always lock-in, no matter what. When thinking about lock-in, the question isn’t so much avoiding it, as figuring out how much you want to take on for what benefits.
Here’s the more on this topic that I gave to a reporter about lock-in concerns with serverless vendors and services:
I work at a vendor, so it’s easy to use an ad hominem argument to dismiss anything I say here. Nonetheless!
Anytime you move your code from one environment to another, you’re doing to have to deal with portability. That’s what most people are worrying about with “lock-in.” This concern crosses open and closed source: if I use an open source UI framework here, and then I want to my my UI to another open source framework, I have to deal with portability - rewriting, re-configuring, maybe even re-architecting things.
Of course, you can try to follow standards to hide the unique FaaS stuff. You could do serverless with knative, for example. You write your own abstraction layer (in general, this is a terrible idea because you probably won’t maintain it over the years, when you want to move to a new type of infrastructure/cloud you’ll have to re-write parts of your own framework, and incorporate new ideas into it, staff will leave and then you’ll lose knowledge of how the system works). When considering “lock-in,” I would look at portability: how easy would it be to move this code - re-writing, etc. if needed - to something else? And then weigh that against any benefits you get from the thing you’re afraid of locking into. If there’s a standard to write to, then use that if you’re concerned with portability.