(no title)
aahortwwy | 3 years ago
I can't recommend Serverless Framework. The abstractions are leaky and it's quite opinionated about architecture. We regularly need to step away from Serverless Framework to use various features offered by AWS. Meanwhile, it's led us to build an infrastructure that reflects our org chart in some really unpleasant ways. I wish we'd used AWS CDK from the start.
Lambda currently makes sense for us cost-wise, but we are approaching an inflection point where that will no longer be true (something like Fargate will probably be cheaper). Problem is, the cost of migrating from Lambda to Fargate will be non-trivial for us. I wish we'd used containers on Lambda from the start.
We struggle regularly with global state in the Lambda runtime. Some devs avoid it assiduously, which can result in costly inefficiencies which have bitten us badly a few times (think hitting API limits due to calls happening on each Lambda invocation rather than only when needed). Other devs make use of global state for efficiency benefits, which then bites us by causing difficult-to-reproduce bugs. I don't think there's a great solution to this in the Lambda runtime.
Overall I think the benefits of security, process isolation, scaling, cost, etc. have all made it worth it, but there are things I would do differently if I was setting up a project from scratch.
idunno246|3 years ago
Does this actually solve a problem? You still need to implement the lambda interface. so as someone who hasn’t used them, containers just seem to replace the zip file format with no actual portability benefit
aahortwwy|3 years ago
Speculative, but had we used containers from the start we would likely have built "fatter" Lambdas running full web servers with an extant web framework (someone else in this thread mentioned Flask - we don't use anything like that, we have one Lambda per... function, and our functions just consume the raw Lambda event).
tomcam|3 years ago