3 ms·

Hello, author here. I totally agree on Lambda first. The only reason we did not do that is because when we started this product I was not well versed with Lamb

Hello, author here. I totally agree on Lambda first. The only reason we did not do that is because when we started this product I was not well versed with Lambda and serverless and preferred to work with something that I dealt with previously. If I could go back in time, I would set up all our applications on serverless.

scarface74 6y ago
Disclaimer: I work for AWS Professional Services but I just started. All of my experience comes from working at outside companies. From the perspective of an outside, boots on the ground Developer/architect, I’ve never worried about “vendor lock in”, I believe you should choose your infrastructure wisely and go all in. But, I do worry about “Lambda lock-in” for APIs. I like the optionality of being able to deploy my APIs anywhere just by changing the CI/CD pipeline. That’s why I recommend using proxy integration. Every language supported by Lambda has a method to just throw your standard API in lambda without tying yourself to it. Here is an example for Node/Express https://github.com/awslabs/aws-serverless-express https://github.com/awslabs/aws-serverless-express Python/Flask (ignore the DDB part): https://www.serverless.com/blog/flask-python-rest-api-serverless-lambda-dynamodb/ https://www.serverless.com/blog/flask-python-rest-api-server... C#/Web API https://aws.amazon.com/blogs/developer/deploy-an-existing-asp-net-core-web-api-to-aws-lambda/ https://aws.amazon.com/blogs/developer/deploy-an-existing-as...