问题
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:
- Security
- Stability
- Scalability.
- Price
回答1:
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.
回答2:
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.
- 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)
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.
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.
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...
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.
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.
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.
回答3:
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.
回答4:
This a fairly old thread, with rather old responses, so I thought a more up-to-date response might help some people out.
I have quite a bit of experience using both Heroku and Engine Yard for some rather large and complex web services. My company uses Engine Yard for running Andromo App Maker for Android and we use Heroku for running AirBop Push Messaging Service for Android. Each platform has its own unique capabilities.
Your question is a bit difficult to answer simply because most of the criteria you are interested in aren't the differentiating features of each platform. I'll answer to those points anyways, but I'll also touch on the general philosophy of each platform and the technical support differences that I think are more useful in your decision.
Security, Stability and Scalability are a wash. Both services are as secure and stable as any Amazon EC2 instance. Scalability is also realistically the same. While Heroku limits you to a couple hundred small (512k) instances (or now 'double' smalls), Engine Yard will let you use Extra Large with tons of CPU and memory, but in the real world, it's all about the same in the end. With Heroku you might need to spawn a swarm of cheap little servers to handle your load, or with Engine Yard you'd use a handful of more expensive larger servers. For web requests, it likely doesn't matter that much.
Price is a factor I can address a bit better. First of all, if you're just tinkering around, Heroku is free. Just don't confuse that with meaning you could really run a real website on their free tier. You can't. Engine Yard gives you a whack of free hours to play around with as well, but let's talk about real world applications. Heroku smooths over the pricing, charging you for 'dynos' (those small web servers I mentioned) and a PostgreSQL database plan. Their prices include storage, backup, bandwidth etc, so it's pretty easy to just make a mental calculation of what things cost. Engine Yard breaks things apart and you'll need to use their calculator to figure out what things will cost - but it's all presented for you before you decide to launch a new 'instance'.
I find Heroku's database plans are very expensive (compared to what the EC2 instance they are using costs). They definitely make up their profit here. What looked cheap for dynos now needs a $200-$400/month database (to start getting to the level of reasonable performance you may be looking at more like $800+). I also hate the way that they hide/gloss over the database specs - you'll need to infer the capabilities by going to Amazon's instance size data and looking at the 'memory' that Heroku is using for 'cache'.
Engine Yard's database is simply whatever server instance you want it to be. They tack on the same EC2 markup as they do for the web instances. No gouging here. It's more transparent.
Is one cheaper than the other? Maybe, but I wouldn't let a few dollars muddy your decision.
In the end, I like Engine Yard for its 'bare metal' control . We need that for Andromo, as we are generating and compiling Android apps on the fly and have some very specific requirements. Engine Yard gives us full control over each server, Unix packages, SSH, etc. On the other hand, Herkou works very well in situations where you can abstract your application from the hardware and get into that swarm of dynos thinking. They make it very fast and easy to launch dozens in a couple of minutes. As I mentioned, we run AirBop on Heroku's platform and have automated our instance creation/destruction with HireFire - which works very well for us as our load varies considerably and unexpectedly.
One other thing to consider is technical support. In my experience, Heroku's free/included support is next to useless, whereas Engine Yard is very good. EY used to charge for basic support but have started included that with all their plans (plus they have a priority 24/7 option available). I've found that they really know what they are talking about as well.
Hopefully that helps!
回答5:
I checked out Bitnami, Heroku and Engine Yard and ran some serious tests against heroku and Engine Yard and Engine Yard was by far the winner. Heroku does some really weird stuff like cap out the processes at 250 MB and their answer is that you have to manage your own memory. I was seeing serious spikes in performance on heroku and it seems like sometimes the processes would just hang and not restart for like a minute with multiple web dynos running (that's not supposed to happen.) Plus heroku puts processes to sleep if they are not being used and there is a weird startup issue even with multiple dynos. Plus the added inconvenience that I could not get to the log files on heroku and figure out what is going on. Having deployed the same exact code to Engine Yard and watching it scream without any funky spikes in performance I have to say Engine Yard is by the far the winner and easiest to deploy to once you get your system setup. The cost is actually cheaper on Engine Yard than on heroku once you start adding web dynos and the performance is way, way better especially if you switch to the JRuby stack. I tried setting up something on Bitnami but from what I remember it was kind of difficult to work with. I think heroku is a good solution if you are not concerned about performance or scalability and just want to deploy a simple web app it is probably easier to use than Engine Yard for that sort of thing.
回答6:
I run mission-critical Rails and Sinatra apps on both Heroku and Engine Yard and PHP apps on the Engine Yard Cloud, and my comment is about #2, stability. Engine Yard wins, hands-down. The reason is the support staff. If your app absolutely must work and you need help making it go, then Engine Yard is there to help you, especially if you invest in premium support. They are absolutely fantastic. Heroku is neat when it works, but when it doesn't work their support staff are nowhere near as helpful.
Here's an example from a couple of months ago when I needed to deploy a mission-critical internal app within a couple of days of getting the request for the app from my staff:
Intermittent timeouts from an app that should never timeout (NOT an "R12 Request Timeout" error)
I have a lot of apps running on Heroku, and none of them have ever had the mysterious web operations problem that I had with that app. Just to assure you that I do know what I'm doing and that it wasn't developer error. Further reassurance of that is that the exact same code has been running perfectly since I moved it to Engine Yard when I couldn't get help from Heroku. They finally responded days after I needed the app launched, telling me that I could troubleshoot performance problems in my app with NewRelic. Great, thanks.
The way that I look at it, paying for premium support from Engine Yard costs a LOT less than hiring web operations people. And I'm getting extremely competent support, from a network of people who always have experts to consult when they don't know. Let me repeat: the Engine Yard support staff is unbelievably fantastic.
I suppose I can comment on security a little, since at one point our SaaS app was hit with a DDoS attack. Maybe that's not what the question was really about, but I'm using it as an excuse to talk about the support staff again. I had never been hit with a DDoS attack, and I didn't even know why my servers were malfunctioning. They diagnosed it and helped me to get started on mitigation. They helped me set up some ad-hoc filters in HAProxy and nginx to block the attack for a while, and that bought me enough time to set up DDoS mitigation.
...then there is the time when the entire Amazon US-East-1 data center imploded and some sites went offline for days. Engine Yard at the time only offered hosting in that data center. Within minutes, they had enabled the option to deploy to US-West-1, and they were helping all of their affected customers to move. Without their help, we would not have been running in time for our prime time that night (we're a SaaS for night clubs) and we probably would have lost a lot of clients because it was a Thursday night. Big night for us. A lot of people who were running apps on Heroku that day were just S.O.L., but we were up and running right away in California thanks to Engine Yard's help.
There have been other times when they've saved our company from certain doom. No joke. I could keep telling stories. But you get the idea. Engine Yard's support staff is the reason that I deploy all new mission-critical apps to the Engine Yard Cloud.
来源：https://stackoverflow.com/questions/2197197/heroku-vs-engineyard-which-one-is-more-worth-the-money