Hacker News Reader

Comment by multani | Hacker News Reader

What is the pattern to use on Lambda if you actually have to call out other services, which may, sometimes, take a long time to answer? Do you make requests with a shorter timeout and have your Lambda fail when it triggers? Do you delegate long calls to a non-Lambda service?

View on HN

In a case where a dependency has a consistent high latency and you can’t avoid it, I’d run the numbers and see if it’s more worthwhile to just run your app on ECS or something instead.

I find that running your app on ECS is generally a great way to just do away with a whole class of problems. I’ve never found lambda to do away with any of the issues I encounter on ECS.

I don’t feel great about lambda (outside of jobs processing and such) as it sometimes feels like you took your application and broke it into a thousand little footguns where a mistake or bad actor can tank your business, but if your company experiences very spikey workloads or not enough income to pay for 24/7 ECS and such, I can see the appeal.

If you have enougu volume to warrant it, probably re-architecting the lambdas so the before/after part of the calls is a separate invocation, with an adapter service living on ECS that gets a call from the “before” lambda, handles the remote request and response, the calls the “after” lambda with the response.

The simpler solution is often to just lift the app from lambda to ECS without internal changes

It seems like Lambda is not suited for such "hanging" use cases. To me the best use case for Lambda is for an API call that might be made very infrequently, like say 50 times a day. Doing the same with a VM instance (remember, it has to be HA, secure etc) is probably not worth the effort.

There are AWS step functions that might fit this use case. Just another product AWS will charge you to use to perpetuate the serverless myth.

Reply on news.ycombinator.com