3 ms·
Your code becomes AWS specific, it is more expensive if you need to scale, it has higher latency, it is harder to test locally etc etc. IMO lambda is awesome t
by takeda 7y ago
Your code becomes AWS specific, it is more expensive if you need to scale, it has higher latency, it is harder to test locally etc etc.
IMO lambda is awesome to handle infrastructure automation.
- AmericanChopper 7y ago> Your code becomes AWS specific Not really, aside from the other AWS services you consume (KMS, parameter store...). A cloud function takes an event, executes your business logic, and returns a response. The structure of the event can change slightly, but they’re remarkably portable, and I’ve moved them before. If you’re doing it right, most of your API gateway config will be an OpenAPI spec, and equally portable. > it is more expensive if you need to scale This is context specific. > it has higher latency Again context specific, and likely not something actually worth caring about. > it is harder to test locally This is one I simply cannot understand. You can run your functions locally, they’re just regular code. I’ve never had a problem testing my functions locally. If anything I’d say it’s easier. There’s upsides and downsides to any architecture design. Serverless models have their downsides, but these anti-serverless discussions tend to miss what the downsides actually are, and kinda strawman a bunch of things that aren’t really. I’d say the most common downside with serverless is that the persistence layer is immature. If you want to use a document database, it’s great, if you want to use a relational one, you might have to make a few design compromises. But that said, this is something that’s improving pretty quickly.