The interface between Lambda and your business logic is usually very thin so in case of simple REST APIs migrating from platform (as long as the target platform has a compatible language runtime) to another or to be executed in a web app framework is rather easy.
Serverless applications' reliance on other proprietary services like Cognito, DynamoDB etc is another thing however...
> Serverless applications' reliance on other proprietary services like Cognito, DynamoDB etc is another thing however...
I feel like even this lock-in is overstated. Those other services are billed based on usage and are completely separate from each other. Your migration path away would be one service at a time.
That's in no way comparable to traditional lock-in, which is like a decades-old Oracle database with high licensing fees paid annually and depended upon by dozens of complex business processes interacting directly and indirectly with each other. You don't really have a migration path in that case because there's not enough time / resources to decouple everything and migrate to something else, so you're stuck.
And that doesn't touch on the reality that if you're not relying on AWS for Lambda, DynamoDB, Kinesis, etc., then you're maintaining something yourself, which itself is not free from lock-in. Building a system that heavily utilizes Cassandra or Kafka may not have an annual licensing cost, but absolutely imposes a cost in terms of maintenance, team expertise, and (of course) makes moving away from them look not much different than moving from DynamoDB or Kinesis.
The problem is also that Lambda works really poorly with anything that is NOT Cognito and DynamoDB. For example, we were using some CouchBase we deployed ourselves - however, that meant that the Lambda now had a network interface in a private subnet, and start times skyrocketed, especially for concurrent access. When we also started doing our own authentication with yet another Lambda, request times for cold lambdas (which also means every new concurrent connection, remember) almost doubled.
There's also the fact that most of the code isn't really gone, it's just transformed from web server logic to lambda deployment/configuration logic.
The biggest win all told seems to be security - at least with Lambda you don't need to worry about staying on top of OS updates and the likes. I'm not at all convinced that we gained much of anything else.
Oh, and one thing that's rarely discussed is how much development&qa costs skyrocket when you have a larger team developing a fully serverless application, each with their own setup and running a few performance tests every few months...
It’s just the opposite of migrating users to Cognito.
If you are storing the passwords in Cognito and not using federated login, you should be able to insert a lambda trigger that captures the user’s password then authenticates the user with Cognito via code. Once the user is authenticated, store the password in your new store.
Yes that would be a slow process but it isn’t like you couldn’t move everything else off of AWS first and let that be a slow migration over time.
Serverless applications' reliance on other proprietary services like Cognito, DynamoDB etc is another thing however...