Hacker News Reader

Comment by scarface74 | Hacker News Reader

For context, I know the ins ands outs of most of the core AWS services really well from the dev, Devops, and ops side.

But, my advice tends to be Lambda first if it is really low volume, LightSail second, and full AWS third.

As far as Lambda, I often recommend proxy integration, where you can just use the standard API framework for whichever language you choose (Django, Flask, Express, ASP.Net, etc) add three lines of code and push the entire thing into Lambdas. This gives you the flexibility to deploy to a VM later with no code changes.

For your static assets use S3, except for the case of Lightsail where you get plenty of free bandwidth.

View on HN

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.

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

Python/Flask (ignore the DDB part):

https://www.serverless.com/blog/flask-python-rest-api-server...

C#/Web API

https://aws.amazon.com/blogs/developer/deploy-an-existing-as...

> I often recommend proxy integration

Could you go further into what this is? Do you mean the API Gateway proxy integration? Is there a code sample somewhere

See previous comment.

https://news.ycombinator.com/item?id=23668069

Short version, instead of letting APIGW do the routing and applying its own intelligence, it just passes the event straight to your lambda. Your lambda has to process it. The plugins I cited, will translate the Lambda event to a form that your standard API framework expects.

Those plugins also work if you put your lambda behind an application load balancer.

Reply on news.ycombinator.com