jamesheroku

Heroku IPs are 75.101.163.44, 75.101.145.87, and 174.129.212.2, if you want to update the script to make the distinction from raw Amazon EC2.

18 now. ;-)

For sub-hour scheduled or recurring tasks, most users prefer a scheduled background task with DJ, rather than old-school cron. There are a bunch of ways to do this, for example:

   Delayed::Job.enqueue(work, 0, Time.now + 5.minutes)

Docs: http://docs.heroku.com/delayed-job

This article contains quite a bit of inaccurate information.

Despite the size of 22 double-XL instances, they were a small portion of our overall footprint in EC2; it takes well over that kind of capacity to run the platform.

Those instance types all happened to be in one availability zone for a variety of reasons. Our platform overall does not live in a single zone.

Losing machines is not a problem for us (we cycle them constantly, in fact). Normally losing even that many machines would not even be noticed by our customers; this was an unusual case in which several factors cascaded into a larger problem.

To be clear, this downtime (45 minutes or so, with full normal state by 90 minutes) was, unfortunately, our fault - not Amazon's. EC2 instances vaporizing is an expected part of using the service.

We've made a couple of operational changes that will prevent these issues in the future, and we sincerely apologize to any customers who were affected.

We aren't planning to provide any additional types of file storage, as we don't believe that the local file system should be used at all in a scalable app, as it creates state at the app server.

We do provide access to /tmp if you need scratch file space for processing (it is not persistent between requests). More info here:

http://docs.heroku.com/constraints#read-only-filesystem

Transfer between S3 and your Heroku app (which lives inside EC2) is free.

We've seen a ton of Couch and Mongo apps lately - works very well with Heroku. Check out http://www.mongohq.com.

Storage limits are for database data only, they don't apply to assets like uploads. Assets should be stored in an asset store, like S3.

Correct, the editor is no longer supported. We hope to bring it back sometime in the future.

Exactly. Most people use DelayedJob to do image processing in the background - also the correct/scalable way to do it. More here:

http://docs.heroku.com/background-jobs

http://docs.heroku.com/delayed-job

Thanks for the feedback.

=== ImageMagick

We have a couple thousand apps using ImageMagick/RMagick, and haven't had any reports of missing functions. We are running ImageMagick 6.2.4 (will be updated to 6.3 sometime soon), so you might check that, and also be sure you aren't trying to use custom-compiled options. If you still have trouble, open a ticket and we'll take care of it: http://support.heroku.com/tickets/new

=== Uploads

We also have thousands of apps doing large file uploads. They should be done as described here: http://docs.heroku.com/s3

Specifically, for larger uploads (we recommend for anything bigger than 4MB), it's wise not to run the upload direct to a dyno, tying up one of your app servers and risking a timeout - it's just not a scalable way to do it. A good pattern is to upload direct to S3 instead, as directed at the bottom of the page. We recommend the S3 SWF Upload plugin: http://github.com/GreenAsJade/s3-swf-upload-plugin/tree/mast...

Awesome, we look forward to it.

I just created a quick Rack app that uses curb and deployed it to Heroku, no problem: http://gist.github.com/108315

If you keep having trouble with your app, please shoot me an email or open a support ticket, and we'll get you sorted out.

Hey Nir, it's James from Heroku. Sorry to hear you had trouble with Heroku. I'd like to address some of your concerns:

1. Gems

We completely support all types of gems, including gems with native bindings (which get compiled automatically for your app). Detailed documentation: http://docs.heroku.com/gems

2. Support

While we were were running our completely unsupported public beta, we tried hard to answer support requests, but our main focus was getting the technology developed. Now that we have launched commercially, we have a full support ticket system, fast response times, and are committed to making immediate support a priority.

3. Financial Solvency

It's true, we aren't Google. We are, however, backed by high quality investors with large investment funds, who are committed to Heroku's success. We have strong interest from many additional firms if we wanted to raise more capital, and we currently have a very healthy runway.

I'd love to talk with you directly to better understand your needs and get more detailed feedback, please feel free to email me at james at heroku dotcom.

Thanks Marcos. We were running db:migrate on push a long time ago for a while, but we ended that practice when serious production applications started moving on to the platform.

We found that running db migrations explicitly is very important for a mission critical production app.

We currently have 11, plus some contractors.

That's interesting feedback, thanks. Sounds like two different issues:

1. Database pricing. We aren't trying to sell storage space, that's not the value you're getting with a Heroku db plan. We would argue that the value is the instant, provisionless nature of the platform - radically faster deployment and scaling, and an environment that just works. So if those features of the platform aren't valuable to you (i.e. you want to provision, configure, and maintain the db yourself), and you're just looking for the best cost/MB, we're definitely not the right answer for you.

Let's say you set that comparison aside for a moment, and you took one of your apps that's providing value to you and selected a Heroku pricing configuration that fits the app's needs. Given the value of your app plus the value you get from our platform, is the total price worth it?

2. Pricing on query execution time, compute cycles, etc. Why is this appealing to you? Is it because those numbers make more sense to you, or because you think if we priced on those units it would make the platform less expensive for you?

Thanks again for your feedback - interesting stuff.

Nice work Peter. I wrapped this in two lines of Sinatra and deployed it to Heroku, so anyone can get an RSS feed for their username: http://hackernews.heroku.com/username

Code is here: http://github.com/jnl/hackernews-thread-rss

Wow, that's silly. Fixed - thanks.

Ah, bingo. Yes, "it just works" and "it glides" are exactly what we're going for. Our version of the magic deploy button is "git push". We've got some great detailed posts coming up about this.

The thing that we've discovered is that instant and "it just works" are tightly related. If something takes minutes or hours to do (even if automated), it's likely that there are many steps involved - each of which is a potential point of failure.

Awesome comment. Wow, "scrum fanboyism" is definitely not what I was going for there - just trying to poke fun at how these teams have changed over the years.

Yes, the technical details are on the way - we're excited to share them.

Interesting to hear the mailing list was unhelpful; we try to respond to it as soon as we can. More importantly though, we are in the process of setting up a proper and reliable support channel, which will be launched very soon.

This intermittent issue is an edge case affecting a very small percentage of apps, and has been eliminated in the new version to be released shortly.