Ruby-on-rails Heroku vs EngineYard：哪个更值钱？

Heroku vs EngineYard: which one is more worth the money?

提问by funkymunky

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

1. 安全
2. 稳定
3. 可扩展性。
4. 价钱

采纳答案by Toby Hede

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

我假设您在谈论 Engine Yard 的 EC2 托管，而不是他们的全方位服务堆栈？

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.

我正在与 Heroku 合作，并且喜欢它。在价格上，Heroku 对我来说是明显的赢家。Heroku 抽象了带宽成本，这是一个巨大的胜利。

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.

Heroku 在技术上投入了大量资金来监控和无缝管理应用程序实例。出了点问题，实例被删除并启动了一个新的实例。很棒的东西。

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

至于可扩展性，两者都支持 Amazon 并利用 EC2 和 EBS，因此在原始容量方面可能大致相同。

回答by Michael Mullany

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.

我曾经在 Engine Yard 工作，所以让我向您提供有关我们的 Engine Yard Cloud 服务（在 AWS 上运行）的信息。我会让你自己研究你的其他选择。

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.

1. 安全性 每个 Engine Yard Cloud 帐户在幕后都是其自己的完整 Amazon 帐户，这意味着您可以获得专供您运行应用程序的完整硬件强制虚拟机。因此，利用人们的 C Gems、Ruby、passenger、linux 等中的零日缓冲区溢出等攻击者只能访问单个帐户。数据路径中没有共享基础设施。我们会查看堆栈中所有元素的安全漏洞报告，并在您重新部署时自动获得新补丁。您可以获得对实例的完全 SSH 访问权限，并在需要安装 Solr 或 Sphinx 或图像处理等软件包时获得正常的服务器环境。

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)

在我看来，硬件级虚拟机是亚马逊成功的基础之一，为什么在虚拟机成熟之前没有出现这样的东西（但我有偏见，因为我曾经是一个 VMware 人，并且看到这种情况实时发生)

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.

2. 稳定性 我们在 Ruby/Rails 组件中什么可以信任什么不能信任方面有很多经验。目前在我们的“不部署”列表中的是 ferret、juggernaut 和 awstats。否则我们会继承 AWS 正常运行时间，因为我们在数据路径中没有共享基础设施。AWS 的正常运行时间非常好，但我还不会尝试用它来运行核电站。最近部署的可靠性好坏参半——亚马逊在容量利用率方面似乎更接近风，因此在某些情况下，容量增加请求将失败，必须重新发出。

3. 可扩展性。我们有一些大型应用程序在 Engine Yard 云上运行。Playmesh 去年 11 月拥有排名第一的 iPhone 应用程序，并提高了处理它的能力。我们甚至对一个能够在恒定负载（非常简单的应用程序）下每月处理 85M/请求的小型实例（4 个杂种）进行了基准测试。如果人们需要大量磁盘 i/o，我们确实建议人们在更大的实例上运行，亚马逊为更大的实例大小提供更好的 i/o 吞吐量。在任何情况下，添加或删除容量实际上都是单击按钮。

4. 价格 在 EY Cloud 上全职运行一个月的小型实例（4 个杂种）将花费您 79 美元或每小时 0.11 美元（而在裸亚马逊上为 8.5 美分）。这包括数据库管理，但您需要为存储和带宽支付少量费用 - Engine Yard Cloud 以 AWS 成本传递这些费用。我们非常有信心，一旦您达到任何合理的流量，我们就是一笔杀手锏。

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.

5. 支持 -> 您可以免费获得社区/论坛支持，但我们也有票支持选项，高级支持选项让您的应用程序 24x7 全天候观看，当您的应用程序出现故障时，我们会通知您，如果受支持，我们会为您排除故障堆栈这是一个问题。

6. 社区 -> 有些人关心这个，有些人不关心这个，但是 Engine Yard 赞助了 2 个全职 Rails 贡献者，一个三人 JRuby 团队和下一代 Ruby VM，Rubinius。我们致力于帮助 Rails 和 Ruby 成为开发 Web 应用程序的最佳平台。

7. 自动化 -> 你只需要观看演示就可以看到它的运行情况，但它很简洁。此外，我们正在使用命令行 git deploys 进行测试，请查看知识库以查看它的实际效果。

回答by Paul McMahon

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.

Heroku 是一个 ruby​​ PaaS 解决方案，类似于谷歌应用引擎。它允许您在没有系统管理技能的情况下扩展应用程序，只要您的应用程序适合它们提供的生态系统。

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.

Engine Yard 是一项更传统的服务，让您可以使用箱子并提供工具，让您的生活更轻松。由于它不是抽象的，它为您提供了更多的灵活性，但也需要您具备更高的系统管理技能。

回答by Colin Adams

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.

我有相当多的使用 Heroku 和 Engine Yard 来处理一些相当大和复杂的 Web 服务的经验。我的公司使用 Engine Yard 运行 Android 版 Andromo App Maker，我们使用 Heroku 运行 Android 版 AirBop 推送消息服务。每个平台都有自己独特的功能。

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.

安全性、稳定性和可扩展性很重要。这两项服务与任何 Amazon EC2 实例一样安全和稳定。可扩展性实际上也是一样的。虽然 Heroku 将您限制为几百个小型 (512k) 实例（或者现在是“双”小型实例），但 Engine Yard 可以让您使用具有大量 CPU 和内存的 Extra Large，但在现实世界中，这一切都差不多结尾。使用 Heroku，您可能需要生成大量廉价的小型服务器来处理您的负载，或者使用 Engine Yard，您可能需要使用一些更昂贵的大型服务器。对于 Web 请求，它可能没有那么重要。

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

价格是我可以更好地解决的一个因素。首先，如果你只是在摆弄，Heroku 是免费的。只是不要将其与您可以真正在其免费层上运行真实网站的意思混淆。你不能。Engine Yard 也为您提供了一些空闲时间来玩，但让我们谈谈现实世界的应用程序。Heroku 平滑了定价，向您收取“dynos”（我提到的那些小型 Web 服务器）和 PostgreSQL 数据库计划的费用。它们的价格包括存储、备份、带宽等，因此很容易对事物的成本进行心理计算。Engine Yard 将事情分解开来，您需要使用他们的计算器来计算成本 - 但在您决定启动新的“实例”之前，这一切都已为您呈现。

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

我发现 Heroku 的数据库计划非常昂贵（与他们使用的 EC2 实例相比）。他们肯定在这里弥补了他们的利润。对于 dynos 来说看起来很便宜的东西现在需要一个 200-400 美元/月的数据库（要开始达到合理的性能水平，您可能需要 800 美元以上）。我也讨厌他们隐藏/掩盖数据库规范的方式 - 您需要通过访问 Amazon 的实例大小数据并查看 Heroku 用于“缓存”的“内存”来推断功能。

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.

Engine Yard 的数据库就是您想要的任何服务器实例。他们使用与 Web 实例相同的 EC2 标记。这里没有挖。它更透明。

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.

最后，我喜欢 Engine Yard 的“裸机”控制。Andromo 需要它，因为我们正在动态生成和编译 Android 应用程序，并且有一些非常具体的要求。Engine Yard 让我们可以完全控制每个服务器、Unix 包、SSH 等。另一方面，Herkou 在您可以从硬件中抽象应用程序并进入 dynos 思维群的情况下非常有效。它们可以在几分钟内快速轻松地启动数十个。正如我所提到的，我们在 Heroku 的平台上运行 AirBop，并使用 HireFire 自动化了我们的实例创建/销毁 - 这对我们来说非常有效，因为我们的负载变化很大且出乎意料。

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.

要考虑的另一件事是技术支持。根据我的经验，Heroku 的免费/包含的支持几乎没用，而 Engine Yard 非常好。安永过去对基本支持收费，但已开始将其包含在所有计划中（此外，他们还提供 24/7 优先选项）。我发现他们也真的知道他们在说什么。

Hopefully that helps!

希望这有帮助！

回答by Adam Freeman

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.

我检查了 Bitnami、Heroku 和 Engine Yard，并对 heroku 进行了一些严肃的测试，Engine Yard 和 Engine Yard 是迄今为止的赢家。Heroku 做了一些非常奇怪的事情，比如将进程限制为 250 MB，他们的答案是你必须管理自己的内存。我看到 heroku 上的性能出现了严重的峰值，而且似乎有时进程会挂起，并且在运行多个 web dynos 的情况下不会重新启动一分钟（这不应该发生。）此外，如果进程没有被运行，heroku 会将进程置于睡眠状态使用，即使有多个 dynos 也有一个奇怪的启动问题。加上我无法访问 heroku 上的日志文件并弄清楚发生了什么的额外不便。将完全相同的代码部署到 Engine Yard 并看着它尖叫而没有任何时髦的性能峰值我不得不说 Engine Yard 是迄今为止的赢家，并且一旦您完成系统设置，就最容易部署。一旦您开始添加 Web dynos，Engine Yard 的成本实际上比在 heroku 上便宜，并且性能会更好，尤其是如果您切换到 JRuby 堆栈。我尝试在 Bitnami 上设置一些东西，但我记得它有点难以使用。我认为 heroku 是一个很好的解决方案，如果您不关心性能或可扩展性并且只想部署一个简单的 Web 应用程序，它可能比 Engine Yard 更易于使用。一旦您开始添加 Web dynos，Engine Yard 的成本实际上比在 heroku 上便宜，并且性能会更好，尤其是如果您切换到 JRuby 堆栈。我尝试在 Bitnami 上设置一些东西，但我记得它有点难以使用。我认为 heroku 是一个很好的解决方案，如果您不关心性能或可扩展性并且只想部署一个简单的 Web 应用程序，它可能比 Engine Yard 更易于使用。一旦您开始添加 Web dynos，Engine Yard 的成本实际上比在 heroku 上便宜，并且性能会更好，尤其是如果您切换到 JRuby 堆栈。我尝试在 Bitnami 上设置一些东西，但我记得它有点难以使用。我认为 heroku 是一个很好的解决方案，如果您不关心性能或可扩展性并且只想部署一个简单的 Web 应用程序，它可能比 Engine Yard 更易于使用。

回答by Ryan Porter

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.

我在 Heroku 和 Engine Yard 上运行关键任务 Rails 和 Sinatra 应用程序，在 Engine Yard Cloud 上运行 PHP 应用程序，我的评论是关于 #2，稳定性。发动机场获胜，毫无悬念。原因是支持人员。如果您的应用绝对必须运行并且您需要帮助才能使其运行，那么 Engine Yard 可以帮助您，特别是如果您投资高级支持。他们绝对是太棒了。Heroku 在工作时很整洁，但当它不起作用时，他们的支持人员远没有那么乐于助人。

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)

应用程序的间歇性超时不应超时（不是“R12 请求超时”错误）

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.

我在 Heroku 上运行了很多应用程序，但没有一个应用程序遇到过我在使用该应用程序时遇到的神秘网络操作问题。只是为了向您保证我确实知道我在做什么并且这不是开发人员错误。更令人放心的是，自从我在无法从 Heroku 获得帮助时将其移至 Engine Yard 以来，完全相同的代码一直在完美运行。在我需要启动应用程序几天后，他们终于做出回应，告诉我可以使用 NewRelic 解决应用程序中的性能问题。万分感谢。

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.

在我看来，从 Engine Yard 支付高级支持的费用比雇用网络运营人员的成本要低很多。而且我得到了非常称职的支持，来自一个总是有专家在他们不知道的时候咨询的人的网络。让我再说一遍：Engine Yard 的支持人员非常棒。

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.

我想我可以对安全性发表一些评论，因为有一次我们的 SaaS 应用程序遭到了 DDoS 攻击。也许这不是问题的真正含义，但我以此为借口再次谈论支持人员。我从未遭受过 DDoS 攻击，我什至不知道我的服务器为什么出现故障。他们诊断出来并帮助我开始缓解。他们帮助我在 HAProxy 和 nginx 中设置了一些临时过滤器来阻止攻击一段时间，这为我赢得了足够的时间来设置 DDoS 缓解。

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

...然后整个 Amazon US-East-1 数据中心崩溃，一些站点离线数天。Engine Yard 当时仅提供在该数据中心的托管服务。在几分钟内，他们启用了部署到 US-West-1 的选项，并且他们正在帮助所有受影响的客户迁移。如果没有他们的帮助，我们就无法赶上那天晚上的黄金时段（我们是夜总会的 SaaS），而且我们可能会失去很多客户，因为那是星期四晚上。对我们来说是个重要的夜晚。那天在 Heroku 上运行应用程序的很多人只是 SOL，但由于 Engine Yard 的帮助，我们立即在加利福尼亚州启动并运行。

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.

也有其他时候他们将我们的公司从某种厄运中拯救出来。不是开玩笑。我可以继续讲故事。但是你明白了。Engine Yard 的支持人员是我将所有新的关键任务应用程序部署到 Engine Yard Cloud 的原因。