Hacker News Reader

Comment by jcampbell1 | Hacker News Reader

Since this was on the front page, I took the time to figure out what IronWorker was all about. It looks to be cron, and memcached as a service, which to me are not real pain points.

Twilio on the other hand is Asterisk, TTS, telephony gateways, and a bunch of other telephony stuff as a service, which is a real pain point.

If I were to implement this app with neither iron.io nor twilio, it would be easy, however using twilio would save me about 2 hours, and cost the same money as a regular SMS gateway. Iron.io would require an additional several hours, and cost additional money. In short, I see iron.io as a negative value add.

View on HN

I'm an ex-intern of Iron.io (ply me with enough alcohol and I'll tell you about it), and I can roughly explain IronWorker: background processing without servers, with a scheduler on top.

I wouldn't call it a 'negative value add' because it means you don't have to babysit a server somewhere, assuming you want to add scheduling onto a Twilio action (call/SMS).

If you took Iron.io out of the equation, how would you schedule the Twilio call? I assume you mean via cron, which is all well and good if you want another server/script to babysit.

That said, I haven't used anything from Iron.io since I've left, and I've written scripts which use a loop, sleep and two if statements to 'schedule' a Twilio call.

Doesn't this require a server for a signup page? Once you have that, you get cron for free.

That Sinatra application can be run locally. From what I have gathered from the article, the Sinatra application is a pretty form for putting your phone number in, nothing more, Twilio calls Iron.io directly.

Rubynerd!! Hope all is well. Thanks for the comments.

Hey Jcampbell,

Thanks for your comments, that's good feedback for us. You're right, in the way that you described it, Iron.io would only be overhead. Cron is built in. Memcached is easy to setup. So is Resque, Gearman, RabbitMQ, Beanstalkd, and a host of other great pieces of software.

We want to not only eliminate the need of setting up Workers/MQ/Cache/Scheduling, but autoscale them, make them elastic, redundant, multi-zone failover, and erosion resistent (Heroku term). And then we'll provide layers of monitoring, management, and alerting out of the box.

Time savings on "setup" is minimal, but time savings and headache as you grow and scale is priceless.

In any case, thanks for taking the time to check us out. If you ever want to chat more, email me chad[at]iron.io or jump into our public chat room monitored like 23/7: http://get.iron.io/chat

Chad

It took me a while to understand the benefit of IronWorker however a 'server-less' environment is exactly what we need for some small discrete jobs. I know that these jobs will scale up (in number) without the need to deploy more servers or maintain them.

This is pretty much spot on as to IronWorker's sweet spot. Discrete jobs, no servers, never worry about scaling.

Reply on news.ycombinator.com