Hacker News new | past | comments | ask | show | jobs | submit login

Iron Workers: http://www.iron.io/worker/

Most new breed Docker hosts like http://tutum.co can give you a quick DIY version.

But in general they (Amazon) are (currently) the best of breed and I have only positive things to say having used the JS and Java versions.




We're using IronWorker and Lambda for a current project. Our (Go) code can run on either and we've designed the app to easily swap out the backend in case of service failure.

Pros of IronWorker: More language support, better logging, easier to debug, scheduled tasks via API (this is the main thing stopping us going all in on Lambda).

Cons: Slower start up time (~2-3s on average compared to milliseconds with Lambda), pay upfront rather than pay for what you use, no choice re. CPU/RAM.


Thanks for the synopsis. Lots of plans for IronWorker including fully custom Docker image support (soon) and millisecond response times (soon'ish). We also support custom configurations of CPU/RAM for dedicated customers which is what most of our customers with stricter SLA's utilize.

That said, a big differentiator is IronWorker's ability to be deployed to any cloud provider as well as private clouds / on-premises. Many of our enterprise customers need hybrid deployments.

We're always listening so please feel free to shoot us feedback at support[at]iron.io or find us at @getiron.

Chad @ Iron.io


You may be interested to know that Lambda now supports scheduling: https://aws.amazon.com/blogs/aws/aws-lambda-update-python-vp...

Edit: Oh, are you saying that you want to send an API call to schedule something? They say in the post that API support is coming, but I don't know if you could schedule a one-off run that way.


Yeah, we connect with other services so we need the ability to programmatically re-schedule a function to run in ~5 minutes if it failed the first time.


Have you noticed any downsides to using Lambda over running a persistent Node server? Is there overhead in execution time, for example?


There's a warmup time when a function is first executed in a container that can be up to 2 seconds depending on what libraries you include (you pay for this time [1]). After the first execution, your function environment will stay "warm" for 10-15 minutes and it will only take 10-150ms to execute your function on a new event.

The other big downside is every time your function goes "cold" you pay the cost of all the extra (anything not in standard lib, ImageMagick, or the AWS Nodejs SDK) libraries you need.

The upside is that you only pay for the time your code actually runs. I've replaced a cronjob server and saved ~90% on the bill to run my jobs. Mostly they were scheduled backups and other misc integrity checks on AWS and 3rd-party infra, so nothing that intense.

More limits/downsides: http://serverlesscode.com/post/aws-lambda-limitations/

1: the cost for 2 seconds of execution time on a 512-MB execution environment is 0.00001668 USD, so it's not likely to break the bank. If you have a high-traffic function it's likely to stay "warm" pretty much all the time. And if your function is low-traffic, it's likely you fit inside the free tier.


Ha! Cronjob to keep functions from going cold! If everyone starts doing that, it will reck the cost structure of Lambda for Amazon, I wager. One wonders why they didn't consider the possibility of users doing just that.


I don't think the previous poster was talking about using cron jobs to prevent functions from going cold.


The node version was OLD last I checked; no harmony features.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: