views:

2618

answers:

3

I looked this up on Google, but wanted more opinions before I committed to either service. Has anyone had experience with either (or maybe both) services? Are there any advantages or disadvantages that stood out about either one? Particular areas of interest are:

  1. Security
  2. Stability
  3. Scalability.
  4. Price
+3  A: 

They are completely different approaches.

Heroku is a ruby PaaS solution, similar to google app engine. It allows you to scale an application with no system administration skills, as long as your application fits into the ecosystem they provide.

Engine Yard is a more traditional service, giving you access to boxes and providing you with tools to make your life easier. As it is less of an abstraction, it offers you more flexibility, but also requires greater sys-admin skills on your part.

Paul McMahon
Engine Yard also have a cloud hosting option, which I presume is the service in question.
Toby Hede
Your points are very valid though, and I think that even in the cloud the EY stuff has more options and flexibility.
Toby Hede
Yes I am referring to the cloud-hosting option in regards to Engine Yard. Thanks for the input though. So it seems like for someone relatively new to web development Heroku would be a better option?
funkymunky
I haven't tried EY's cloud offering, but if you don't know much about sysadmin type stuff, Heroku is tough to beat...
Luke Francl
+5  A: 

I am presuming that you are talking about Engine Yard's EC2 hosting, rather than their full-service stack?

I am working with Heroku, and love it. On price, Heroku is the clear winner for me. Bandwidth costs are abstracted by Heroku, which is a big win.

On the security fronts, it's a bit hard to tell - which is one of the common critiques of the cloud. You don't have a whole lot of insight into the stack that is running on either service.

Heroku have invested a huge amount in technology to monitor and seamlessly manage application instances. Something goes wrong and the instance is dropped and a new one started. Wonderful stuff.

As to scalability, both are backed onto Amazon and leverage EC2 and the EBS, so probably much the same in terms of raw capacity.

Toby Hede
+6  A: 

Funky,

I used to work for Engine Yard, so let me give you the information on our Engine Yard Cloud service (running on AWS). I'll leave you to do your own research on your other options.

  1. Security Each Engine Yard Cloud account is its own full Amazon account behind the scenes, that means you get full hardware-enforced, virtual machines dedicated to you to run your application. So attackers exploiting a zero-day buffer overflow etc. in people's C Gems, Ruby, passenger, linux etc. only get access to a single account. There is no shared infrastructure in the data-path. We watch security vulnerability reports for all elements of our stack and you get new patches automatically when you redeploy. You get full SSH access to your instances, and get a normal server environment for when you need to install packages such as Solr or Sphinx or image manipulation etc.

In my mind, hardware-level virtual machines is one of the foundations of Amazon success and why nothing like this came along before virtual machines matured (but I'm biased because I used to be a VMware guy, and saw this happening in real time)

  1. Stability We have a lot of experience with what can be trusted and what can't in Ruby/Rails components. Currently on our "do not deploy" list are ferret, juggernaut and awstats. Otherwise we inherit AWS uptime because we do not have shared infrastructure in the data path. AWS uptime has been pretty good, but I wouldn't try to run a nuclear power plant with it just yet. Deploy reliability has been mixed recently -- Amazon seems to be running a little closer to the wind on capacity utilization, so on some occasions a capacity addition request will fail and have to be re-issued.

  2. Scalability. We have some big applications running on Engine Yard cloud. Playmesh had the number 1 iphone app last November and cranked up capacity to handle it well. We've benchmarked even a small instance (4 mongrels) able to handle 85M/Reqs per month at constant load (very simple app). We do recommend that people run on larger instances if they want a lot of disk i/o, Amazon provides better i/o throughput to larger instance sizes. In any case, adding or removing capacity is literally a click of a button.

  3. Price Running a small instance (4 mongrels) full-time for a month will cost you $79 on EY Cloud or 0.11 per hour (vs. 8.5 cents on naked Amazon). This includes database management, but you'll pay a small amount for storage and bandwidth - which Engine Yard Cloud passes along at AWS cost. We're pretty confident that once you reach any reasonable amount of traffic, we're a killer deal.

Let me add a few other criteria that you might want to consider...

  1. Support -> you get community/forum support for free, but we also have a ticketed support option, the premium support option gets your app watched 24x7 and we'll notify you when your app goes down and troubleshoot it for you if it's the supported stack that's a problem.

  2. Community -> Some people care about this, some people don't but Engine Yard sponsors 2 full time Rails contributors, a three person JRuby team and the next gen Ruby VM, Rubinius. We're committed to helping make Rails and Ruby the best platform for developing web apps there is.

  3. Automation -> you just have to watch the demo to see it in action, but it's neat. Also we're in beta with command line git deploys, check out the knowledgebase to see it in action.

Michael Mullany
Michael, thanks for taking the time to write such an in-depth response. It's extremely helpful. I'm currently hosting my app on Heroku because it's relatively small and free to host there, but will definitely give Engine Yard a try for larger apps in the future.
funkymunky