[LRUG] Rails in the wonderful, wonderful Cloud

Michael Mullany mmullany at engineyard.com
Thu Oct 1 15:37:41 PDT 2009

>> I chose Engine Yard for a large project and now, in retrospect, wish
>> I'd gone elsewhere. They are probably appropriate for particular kinds
>> of application but my main problems with them are that a) they're
>> expensive and b) their stack is very constrained. Both of these are
>> because of the support they offer but I've found that support to be
>> strong on the Ruby/Rails side of things (which I don't actually need,
>> because Rails basically works and I can fix it when it doesn't) but
>> not so great on the more general sysadmin side (which I do need
>> because it's a waste of my time).

Tom, the old "slice" product looked like it had a high sticker price
compared to conventional hosting,
but there was a huge amount of other resources and services bundled
into that price. Since most people had a
hard time parsing that out, we've gone with a much simpler, (and
lower) price structure for our new Cloud
product which has a lot more features than the old slice product, but
bundles a few less "extras" and services.
It used to be that you couldn't get onto any form of Engine Yard for
less than $1,200, the entry price
is now $115 for a month of a small cloud instance without support, or
if you just want to try it out,
it's $25 minimum. And it's all self-service to get set up, you don't
have to talk to anyone if you
don't want to (and lots of people don't)

Your comment about constrained stack is true, we can only support
nginx, passenger, mongrel, mysql, postgres,
memcached, tokyo, redis, backgroundrb, delayedjob, sphinx,
jruby/glassfish today with some help for AMQP, solr and others. But
this means that we REALLY support these. Our support guys know these
components and most of their quirks pretty well
and we watch for security vulnerabilities and new versions. On cloud
you get patched up to date every time
you do a redeploy. For stuff that we don't support there's always your
chance to write chef recipes to
automate installation and configuration. We can't be experts on
everything, unfortunately, and it takes us
a little time to put new stuff through its paces.

>> If you want more than a paltry amount of RAM with Engine Yard you'll
>> need to pay extra for it, but you're going to need that RAM because
>> they only support 64-bit mongrels running stock Ruby 1.8.6; if you
>> want to run Passenger + REE, for example, you're out of luck. I now

The new cloud stuff from Engine Yard gives you a minimum 1.7Gb AWS instance and
passes through bandwidth and storage charges from AWS at cost.

>> think I'd personally be better off with the simplicity and flexibility
>> of something like Slicehost: letting them take care of keeping the
>> servers up, letting myself take responsibility for architectural
>> decisions (plus a nice web control panel for fiddling with DNS etc
>> instead of having to open a ticket for everything), and spending the
>> extra money on larger slices full of memcached and/or more mongrels.
>> Of course YMMV but it's pretty easy to see that deploying Rails
>> applications is much easier than it used to be, and that fact alone
>> makes Engine Yard's offering less compelling than it used to be.

>> Note that I'm talking about their conventional virtualised slices
>> here, not Solo or whatever other new cloud-style stuff they might be
>> doing.

The cloud-stuff is a veeery different beast from the classic Slices. Check
it out -- you might change your opinion. Also someone said you won't need
scale-up/down of cloud. Data from our customer base shows that our median
customer has about a 4:1 peak to trough traffic load (over months long
sampling periods) so you can save money with easy scale-up/down if you're
a typical site.

Michael Mullany
Engine Yard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20091001/8105deba/attachment-0003.html>

More information about the Chat mailing list