That depends on available resources in the zone (? I think).
But its at least a couple of minutes, so its possible to keep them warm by pinging them at nearly no cost.
Or if you have enough traffic on the function, thats not needed at all.
Sebb
1
LostKobrakai
I can surely see the “cost” factor, but to me it just sounds ludacris to regularly ping a service so it doesn’t shut down, when the platform of the service is built to reduce cost by shutting down services when not used – over say a server running full time. So much complexity when one could just use a server, which doesn’t shut down the service in the first place.
6
Sebb
You’re right, its a little stupid.
But that’s Amazon’s problem, not ours.
AWS allows us to operate a complex distributed system with close to zero dev-ops cost. Moving the lambdas to EC2 would drastically increase the costs. I know because that is how it was before. We could also have transformed the old system to Elixir, which would also have reduced complexity, but:
(also I did not know about the goodness of Elxir/OTP then)
2
sorentwo
Oban Core Team
There are some great points in this thread. Here are a few other things to consider on behalf of Oban compared to a stateless background job systems (and even some other persistent ones):
- Observability — built in metrics for queue time and execution time, as well as durable timestamps that identify exactly when a job was completed.
- Error Handling — built in retries, automatic backoff, and persisted error messages along with stacktraces.
- Concurrency Controls — concurrency per-queue, because infinite scalability isn’t always the right behaviour. What about external rates limits, or database contention?
- Testing — you run jobs for side effects, and you typically want to test the complete flow from when a job is enqueued to its execution. Testing execution flows should be simple to control without heavy mocking.
5
kanishka
After reading through the responses, it sounds like elixir is not a first class citizen (yet?) within AWS lambda, and so it’s not a realistic option without contortions.
I guess my core interest is when to use a self administered, featureful job scheduler like Oban versus externally administered/managed AWS lambda, in a world where there is no penalty or immediate issues with using Elixir in a lambda. That’s too hypothetical for now, so I will revisit in a year or so, if there is more first party or third party support for Elixir in a lambda.
0