HNHacker News
TopNewBestAskShowJobs

treeder

1,221 karma · joined February 15, 2011

submissionscomments
treeder··on Adding Scheduling to Twilio with IronWorker
This is pretty much spot on as to IronWorker's sweet spot. Discrete jobs, no servers, never worry about scaling.
treeder··on Show HN: Pup, real-time app metrics with Statsd
@amix, you clearly didn't read the post.
treeder··on Spikability - An Application's Ability to Handle Load
The pattern is to put the work in a queue, respond to the user immediately, then process in the background, outside the request cycle.

Regarding auto scaling, it is scaling your worker servers to work down the queues, but it is not as urgent/critical as auto scaling your app servers if they had to handle the load.

treeder··on Scalable Image Processing Using Hosted Cloud Services
IronWorker is billed by the second so if an image takes 5 seconds to process, you only get billed for 5 seconds of the hour. No need to deal with auto-scaling heroku workers to keep your costs down.

And priority on IronWorker has a much different meaning than setting it on your own private Resque instance so comparing that based on price isn't really a fair comparison.

treeder··on Scalable Image Processing Using Hosted Cloud Services
No resque setup/management, no auto-scaling setup, scale huge with zero effort (go from processing one image to millions without lifting a finger), redundancy and reliability (how are you going to ensure that with your Resque?), full visibility into your tasks, etc.
treeder··on Iron.io Releases IronCache
In some ways yes:

- they are both hosted services - they both are key/value stores

In other ways no:

- IronCache has a REST API and supports memcached protocol - IronCache only supports the basic functions of Redis, redistogo supports all of Redis because it actually is Redis. - IronCache is elastic and scales with you, without any effort on your part. redistogo requires you to choose how much memory you want up front. - Pricing is much different due to the point above too: IronCache charges by usage, redistogo charges based on the fixed amount of memory you choose.

treeder··on Why Aren't You Developing in the Cloud?
Cloud has a lot of different meanings these days so it's nearly impossible to really define it, but it is possible to think of them in various different contexts:

- Consumer cloud or SaaS for consumers (gmail, rdio, facebook, etc) - SaaS for business (salesforce, box, etc) - Cloud Infrastructure Services (amazon, rackspace, etc) - Cloud Application Services - higher level services on top of cloud infrastructure (heroku, iron.io, mongolab, papertrail) - Private clouds (which can include several of the above) - etc...

In this article I'm referring to cloud application services because those are the high level services that just take a couple lines of code and a couple of minutes to configure and use.

treeder··on Why Aren't You Developing in the Cloud?
I agree with this, it's generally a good idea to use services that don't lock you in and provide common interfaces so you can move your data or take in house at any time. Like http://www.mongolab.com for instance uses standard MongoDB and IronMQ (http://www.iron.io/products/mq/features) supports the beanstalkd protocol so at any point, you can take your data and easily switch just by changing endpoints.
treeder··on Why Aren't You Developing in the Cloud?
> Because I am not stupid to pay monthly fees instead of single upfront licenses.

You also have to think about the cost of hosting, maintaining, monitoring, etc. Usually a service fee by a provider is much smaller than the cost of doing all this yourself. Of course there is some inflection point where it may be cheaper to do it yourself. And during development and while you're still small, most service providers offer a generous free plan.

> Because my desktop screams while my net connection is so so.

Can't argue with that one.

> Because a native UI kicks the sh*t out of any web interface, in looks, perfomance and integration.

Totally agree. Like I said in the post, I still write my code locally.

> Because I am paranoid and I like my data in MY local net.

Are you paranoid about your development data?

> Because I do not mind a bunch of (easily scriptable) installs.

...

> I short because the technical problems I am trying to solve go way beyond a trivial LAMP app...

I would argue that this is a good reason to you use services since they will deal with all the hard stuff of running these non-trivial services. The more complicated your application, the more value you'll get out of using services.

treeder··on How to Reduce a 9 Hour Job into a 10 Minute Job
Ya, they won't need to run those Heroku workers anymore to do this processing, they are just using IronWorker on demand.
← PreviousPage 2 of 2