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:
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:
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...
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.
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
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.