There are many case studies of AWS Lambda's scaling power and its constraints are well documented. The newcomer in the serverless architecture is AWS API Gateway Websockets, and I personally have not performed any tests using this service within a variety of use-cases at significant scale (it's still a new service).
When it comes to migration, it depends on your use-case. A few suggestions which may be helpful:
* Consider your data strategy (much lock-in happens at this level). Most serverless architectures leverage DynamoDB because its design pairs well with stateless compute like AWS Lambda. You can use DynamoDB within all types of architectures.
* Don't use AWS API Gateway specific URLs in your application. Use custom domains. This will enable you to easily swap out your websockets endpoint. Fortunately, there is only 1 endpoint in this architecture, so there is little surface area to refactor.
* Make sure you understand the cost of these serverless technologies at scale before building with them. But don't forget to factor in the reduced labor costs of using serverless technologies.
When it comes to migration, it depends on your use-case. A few suggestions which may be helpful:
* Consider your data strategy (much lock-in happens at this level). Most serverless architectures leverage DynamoDB because its design pairs well with stateless compute like AWS Lambda. You can use DynamoDB within all types of architectures.
* Don't use AWS API Gateway specific URLs in your application. Use custom domains. This will enable you to easily swap out your websockets endpoint. Fortunately, there is only 1 endpoint in this architecture, so there is little surface area to refactor.
* Make sure you understand the cost of these serverless technologies at scale before building with them. But don't forget to factor in the reduced labor costs of using serverless technologies.