<pre>>> I chose Engine Yard for a large project and now, in retrospect, wish  <br>>> I'd gone elsewhere. They are probably appropriate for particular kinds  <br>>> of application but my main problems with them are that a) they're  <br>
>> expensive and b) their stack is very constrained. Both of these are  <br>>> because of the support they offer but I've found that support to be  <br>>> strong on the Ruby/Rails side of things (which I don't actually need,  <br>
>> because Rails basically works and I can fix it when it doesn't) but  <br>>> not so great on the more general sysadmin side (which I do need  <br>>> because it's a waste of my time).<br><br>Tom, the old "slice" product looked like it had a high sticker price compared to conventional hosting, <br>
but there was a huge amount of other resources and services bundled into that price. Since most people had a<br>hard time parsing that out, we've gone with a much simpler, (and lower) price structure for our new Cloud <br>
product which has a lot more features than the old slice product, but bundles a few less "extras" and services.<br>It used to be that you couldn't get onto any form of Engine Yard for less than $1,200, the entry price<br>
is now $115 for a month of a small cloud instance without support, or if you just want to try it out, <br>it's $25 minimum. And it's all self-service to get set up, you don't have to talk to anyone if you<br>don't want to (and lots of people don't)<br>
<br>Your comment about constrained stack is true, we can only support nginx, passenger, mongrel, mysql, postgres, <br>memcached, tokyo, redis, backgroundrb, delayedjob, sphinx, jruby/glassfish today with some help for AMQP, solr and others. But<br>
this means that we REALLY support these. Our support guys know these components and most of their quirks pretty well<br>and we watch for security vulnerabilities and new versions. On cloud you get patched up to date every time<br>
you do a redeploy. For stuff that we don't support there's always your chance to write chef recipes to <br>automate installation and configuration. We can't be experts on everything, unfortunately, and it takes us <br>
a little time to put new stuff through its paces.<br><br><br>>> If you want more than a paltry amount of RAM with Engine Yard you'll  <br>>> need to pay extra for it, but you're going to need that RAM because  <br>
>> they only support 64-bit mongrels running stock Ruby 1.8.6; if you  <br>>> want to run Passenger + REE, for example, you're out of luck. I now  <br><br>The new cloud stuff from Engine Yard gives you a minimum 1.7Gb AWS instance and <br>
passes through bandwidth and storage charges from AWS at cost. <br><br>>> think I'd personally be better off with the simplicity and flexibility  <br>>> of something like Slicehost: letting them take care of keeping the  <br>
>> servers up, letting myself take responsibility for architectural  <br>>> decisions (plus a nice web control panel for fiddling with DNS etc  <br>>> instead of having to open a ticket for everything), and spending the  <br>
>> extra money on larger slices full of memcached and/or more mongrels.  <br>>> Of course YMMV but it's pretty easy to see that deploying Rails  <br>>> applications is much easier than it used to be, and that fact alone  <br>
>> makes Engine Yard's offering less compelling than it used to be.<br><br>>> Note that I'm talking about their conventional virtualised slices  <br>>> here, not Solo or whatever other new cloud-style stuff they might be  <br>
>> doing.<br><br>The cloud-stuff is a veeery different beast from the classic Slices. Check<br>it out -- you might change your opinion. Also someone said you won't need<br>scale-up/down of cloud. Data from our customer base shows that our median<br>
customer has about a 4:1 peak to trough traffic load (over months long <br>sampling periods) so you can save money with easy scale-up/down if you're<br>a typical site.<br><br>Michael Mullany<br>Engine Yard<br></pre>