back
7 comments
I would claim that the microservice architecture of AWS Lambda & API Gateway (which is generally associated with Serverless applications) is not what causes vendor lock-in. It's pretty straightforward to implement the same environment to run your apps anywhere.

Real vendor-lock-in is caused by use of proprietary backend services like DynamoDB, Redshift, Kinesis, etc. which cannot be used anywhere else than AWS.

When you go "full serverless", you still need a place to store data, backups, etc. And then with the high cost of bandwith (...) you may as well use the same service provider you use for your "services". Be it AWS or GCloud or Azure.

If you spin up servers to manage your database+storage needs, then you are no longer serverless, you are in a pretty nice hybrid - lowering somewhat your money costs maybe, but I'd still argue that the impact on ops of the "application servers" is negligible compared to what is required by everything else in the stack.

There is a slightly better name for "serverless architecture", its called "function as a service". But in my opinion "process on demand" would describe this concept even better.
I agree that DynamoDB, Kinesis, ... reinforce the vendor lock-in. But I'would say that easy to implement AWS Lambda & API Gateway.
Kenesis and SES, maybe. But Dynamo would be pretty easy to replace with something like Mongo provided that you abstract your databases access code and don't have a lot of backend specific code missed with your business logic.

A lot of serverless apps use Graphql for this purpose since Graphql is backend agnostic.

I would not be not easy to implement the full generic functionality of Lambda and API Gateway. But I think it would be fairly easy to just write some application-specific Express code to handle the API routing, and add some wrappers for Lambda calls, in order to migrate a single application.
It seems to me that all these things do is accelerate time to market and make it easier for you to scale if you're successful.

The corollary to this could be that if you're not repeatedly pushing out MVPs, this newfangled stuff may not be that useful to you. This is my view of the full stack JavaScript world as well. Things are generally transient and experimental so the wild west stuff works fine there.

I'd love to be convinced that I'm wrong. I have yet to write a piece of software that has been decommissioned in less than a decade after going live and I do get a little envious of the fast moving stuff.