Ruby-on-rails 为什么人们在 AWS 存在时使用 Heroku？Heroku 与 AWS 的区别是什么？

Why do people use Heroku when AWS is present? What distinguishes Heroku from AWS?

提问by Bryan

I'm a beginner RoR programmer who's planning to deploy my app using Heroku. Word from my other advisor friends says that Heroku is really easy, good to use. The only problem is that I still have no idea what Heroku does...

我是一名 RoR 初学者，计划使用 Heroku 部署我的应用程序。我的其他顾问朋友说 Heroku 真的很简单，很好用。唯一的问题是我仍然不知道 Heroku 是做什么的......

I've looked at their websiteand in a nutshell, what Heroku does is help with scaling but... why does that even matter? How does Heroku help with:

我看过他们的网站，简而言之，Heroku 所做的是帮助扩展，但是......为什么这很重要？Heroku 如何帮助：

1. Speed - My research implied that deploying AWS on the US East Coast would be the fastest if I am targeting a US/Asia-based audience.

2. Security - How secure are they?

3. Scaling - How does it actually work?

4. Cost efficiency - There's something like a dyno that makes it easy to scale.

5. How do they fare against their competitors? For example, Engine Yardand bluebox?

1. 速度 - 我的研究表明，如果我的目标是美国/亚洲的受众，在美国东海岸部署 AWS 将是最快的。

2. 安全性 - 他们有多安全？

3. 缩放 - 它实际上是如何工作的？

4. 成本效率 - 有一种类似 dyno 的东西可以轻松扩展。

5. 他们如何与竞争对手竞争？例如，Engine Yard和bluebox?

Please use layman English terms to explain... I'm a beginner programmer.

请用外行的英文术语来解释...我是一个初学者程序员。

采纳答案by SuperNova

AWS / Herokuare both free for small hobby projects (to start with).

AWS / Heroku对于小型业余项目（首先）都是免费的。

If you want to start an app right away, without much customization of the architecture, then choose Heroku.

如果您想立即启动应用程序，而无需对架构进行太多自定义，请选择Heroku。

If you want to focus on the architecture and to be able to use different web servers, then choose AWS. AWS is more time-consuming based on what service/product you choose, but can be worth it. AWS also comes with many plugin services and products.

如果您想专注于架构并能够使用不同的 Web 服务器，请选择AWS。根据您选择的服务/产品，AWS 更耗时，但值得。AWS 还附带了许多插件服务和产品。

---

---

Heroku

赫鲁库

• Platform as a Service (PAAS)
• Good documentation
• Has built-in tools and architecture.
• Limited control over architecture while designing the app.
• Deployment is taken care of (automatic via GitHub or manual via git commands or CLI).
• Not time consuming.

• 平台即服务 (PAAS)
• 良好的文档
• 具有内置工具和架构。
• 在设计应用程序时对架构的控制有限。
• 部署得到照顾（通过 GitHub 自动或通过 git 命令或 CLI 手动）。
• 不费时间。

---

---

AWS

自动售货机

• Infrastructure as a Service (IAAS)
• Versatile - has many products such as EC2, LAMBDA, EMR, etc.
• Can use a Dedicated instance for more control over the architecture, such as choosing the OS, software version, etc. There is more than one backend layer.
• Elastic Beanstalk is a feature similar to Heroku's PAAS.
• Can use the automated deployment, or roll your own.

• 基础设施即服务 (IAAS)
• 多才多艺——拥有EC2、LAMBDA、EMR等多种产品。
• 可以使用专用实例对架构进行更多控制，例如选择操作系统、软件版本等。后端层不止一个。
• Elastic Beanstalk 是一个类似于 Heroku 的 PAAS 的功能。
• 可以使用自动部署，也可以自行部署。

回答by Kristian Glass

First things first, AWS and Heroku are different things. AWS offer Infrastructure as a Service (IaaS) whereas Heroku offer a Platform as a Service (PaaS).

首先，AWS 和 Heroku 是不同的东西。AWS 提供基础设施即服务 ( IaaS)，而 Heroku 提供平台即服务 ( PaaS)。

What's the difference? Very approximately, IaaS gives you components you need in order to build things on top of it; PaaS gives you an environment where you just push code and some basic configuration and get a running application. IaaS can give you more power and flexibility, at the cost of having to build and maintain more yourself.

有什么不同？大致上，IaaS 为您提供了在其上构建事物所需的组件；PaaS 为您提供了一个环境，您只需在其中推送代码和一些基本配置并获得正在运行的应用程序。IaaS 可以为您提供更多功能和灵活性，但代价是您必须自己构建和维护更多内容。

To get your code running on AWS and looking a bit like a Heroku deployment, you'll want some EC2 instances - you'll want a load balancer / caching layer installed on them (e.g. Varnish), you'll want instances running something like Passengerand nginxto serve your code, you'll want to deploy and configure a clustered database instance of something like PostgreSQL. You'll want a deployment system with something like Capistrano, and something doing log aggregation.

为了让您的代码在 AWS 上运行并看起来有点像 Heroku 部署，您需要一些 EC2 实例 - 您需要在它们上安装负载均衡器/缓存层（例如Varnish），您需要运行类似的实例乘客和nginx为您的代码提供服务，您将需要部署和配置诸如PostgreSQL之类的集群数据库实例。您将需要一个部署系统，其中包含Capistrano 之类的东西，以及进行日志聚合的东西。

That's not an insignificant amount of work to set up and maintain. With Heroku, the effort required to get to that sort of stage is maybe a few lines of application code and a git push.

这不是一个微不足道的工作量来设置和维护。使用 Heroku，达到那种阶段所需的努力可能是几行应用程序代码和一个git push.

So you're this far, and you want to scale up. Great. You're using Puppetfor your EC2 deployment, right? So now you configure your Capistrano files to spin up/down instances as needed; you re-jig your Puppet config so Varnish is aware of web-worker instances and will automatically pool between them. Or you heroku scale web:+5.

所以你已经走了这么远，你想扩大规模。伟大的。您正在使用Puppet进行 EC2 部署，对吗？因此，现在您将 Capistrano 文件配置为根据需要启动/关闭实例；你重新调整你的 Puppet 配置，这样 Varnish 就会知道 web-worker 实例，并会自动在它们之间进行池化。或者你heroku scale web:+5。

Hopefully that gives you an idea of the comparison between the two. Now to address your specific points:

希望这能让您对两者之间的比较有所了解。现在解决您的具体问题：

Speed

速度

Currently Heroku only runs on AWS instances in us-eastand eu-west. For you, this sounds like what you want anyway. For others, it's potentially more of a consideration.

目前 Heroku 仅在us-east和 中的AWS 实例上运行eu-west。对你来说，这听起来像是你想要的。对于其他人来说，这可能更需要考虑。

Security

安全

I've seen a lot of internally-maintained production servers that are way behind on security updates, or just generally poorly put together. With Heroku, you have someone else managing that sort of thing, which is either a blessing or a curse depending on how you look at it!

我见过很多内部维护的生产服务器，它们在安全更新方面远远落后，或者只是总体上很糟糕。使用 Heroku，您会有其他人来管理此类事情，这取决于您如何看待它，这是一种祝福还是一种诅咒！

When you deploy, you're effectively handing your code straight over to Heroku. This may be an issue for you. Their article on Dyno Isolationdetails their isolation technologies (it seems as though multiple dynos are run on individual EC2 instances). Several colleagues have expressed issues with these technologies and the strength of their isolation; I am alas not in a position of enough knowledge / experience to really comment, but my current Heroku deployments consider that "good enough". It may be an issue for you, I don't know.

部署时，您实际上是将代码直接交给 Heroku。这对你来说可能是个问题。他们关于Dyno Isolation的文章详细介绍了他们的隔离技术（似乎多个 dyno 运行在单个 EC2 实例上）。几位同事表达了对这些技术及其隔离强度的问题；唉，我没有足够的知识/经验来真正发表评论，但我目前的 Heroku 部署认为“足够好”。这对你来说可能是个问题，我不知道。

Scaling

缩放

I touched on how one might implement this in my IaaS vs PaaS comparison above. Approximately, your application has a Procfile, which has lines of the form dyno_type: command_to_run, so for example (cribbed from http://devcenter.heroku.com/articles/process-model):

我在上面的 IaaS 与 PaaS 比较中谈到了如何实现这一点。大约，您的应用程序有一个Procfile，其中包含表单的行，dyno_type: command_to_run例如（摘自http://devcenter.heroku.com/articles/process-model）：

web:    bundle exec rails server
worker: bundle exec rake jobs:work

This, with a:

这与：

heroku scale web:2 worker:10

will result in you having 2 webdynos and 10 workerdynos running. Nice, simple, easy. Note that webis a special dyno type, which has access to the outside world, and is behind their nice web traffic multiplexer (probably some sort of Varnish / nginx combination) that will route traffic accordingly. Your workers probably interact with a message queue for similar routing, from which they'll get the location via a URL in the environment.

将导致您运行2 个webdynos 和 10 个workerdynos。不错，简单，轻松。请注意，这web是一种特殊的 dyno 类型，它可以访问外部世界，并且位于其出色的 Web 流量多路复用器（可能是某种 Varnish / nginx 组合）的后面，它将相应地路由流量。您的工作人员可能会与消息队列进行交互以进行类似的路由，他们将通过环境中的 URL 从中获取位置。

Cost Efficiency

成本效益

Lots of people have lots of different opinions about this. Currently it's $0.05/hr for a dyno hour, compared to $0.025/hr for an AWS micro instance or $0.09/hr for an AWS small instance.

很多人对此有很多不同的看法。目前，dyno 小时为 0.05 美元/小时，而 AWS 微型实例为 0.025 美元/小时，AWS 小型实例为 0.09 美元/小时。

Heroku's dyno documentationsays you have about 512MB of RAM, so it's probably not toounreasonable to consider a dyno as a bit like an EC2 micro instance. Is it worth double the price? How much do you value your time? The amount of time and effort required to build on top of an IaaS offering to get it to this standard is definitely not cheap. I can't really answer this question for you, but don't underestimate the 'hidden costs' of setup and maintenance.

Heroku 的dyno 文档说你有大约 512MB 的 RAM，所以将dyno 视为有点像 EC2 微实例可能并不太不合理。值得双倍的价格吗？你有多珍惜你的时间？在 IaaS 产品之上构建以使其达到此标准所需的时间和精力绝对不便宜。我无法真正为您回答这个问题，但不要低估设置和维护的“隐藏成本”。

(A bit of an aside, but if I connect to a dyno from here (heroku run bash), a cursory look shows 4 cores in /proc/cpuinfoand 36GB of RAM - this leads me to believe that I'm on a "High-Memory Double Extra Large Instance". The Heroku dyno documentationsays each dyno receives 512MB of RAM, so I'm potentially sharing with up to 71 other dynos. (I don't have enough data about the homogeny of Heroku's AWS instances, so your milage may vary))

（有点旁白，但如果我从这里连接到一个 dyno ( heroku run bash)，粗略看会显示 4 个内核/proc/cpuinfo和 36GB 的 RAM - 这让我相信我在一个“高内存双超大实例”上"。Heroku dyno 文档说每个 dyno 接收 512MB 的 RAM，所以我可能与多达 71 个其他 dyno 共享。（我没有足够的关于 Heroku 的 AWS 实例的同质性的数据，所以你的里程可能会有所不同））

How do they fare against their competitors?

他们如何与竞争对手竞争？

This, I'm afraid I can't really help you with. The only competitor I've ever really looked at was Google App Engine- at the time I was looking to deploy Java applications, and the amount of restrictions on usable frameworks and technologieswas incredibly off-putting. This is more than "just a Java thing" - the amount of general restrictions and necessary considerations (the FAQhints at several) seemed less than convenient. In contrast, deploying to Heroku has been a dream.

这个，我恐怕真的帮不了你。我真正关注过的唯一竞争对手是Google App Engine——当时我正在寻求部署 Java 应用程序，而对可用框架和技术的限制数量令人难以置信。这不仅仅是“只是 Java 的事情”——一般限制和必要考虑的数量（常见问题解答提示了几个）似乎不太方便。相比之下，部署到 Heroku 一直是一个梦想。

Conclusion

结论

I hope this answers your questions (please comment if there are gaps / other areas you'd like addressed). I feel I should offer my personal position. I love Heroku for "quick deployments". When I'm starting an application, and I want some cheap hosting (the Heroku free tier is awesome - essentially if you only need one web dyno and 5MB of PostgreSQL, it's free to host an application), Heroku is my go-to position. For "Serious Production Deployment" with several paying customers, with a service-level-agreement, with dedicated time to spend on ops, et cetera, I can't quite bring myself to offload that much control to Heroku, and then either AWS or our own servers have been the hosting platform of choice.

我希望这能回答您的问题（如果有您想要解决的差距/其他领域，请发表评论）。我觉得我应该提供我的个人立场。我喜欢 Heroku 的“快速部署”。当我开始一个应用程序时，我想要一些便宜的托管（Heroku 免费层很棒 - 基本上如果你只需要一个 web dyno 和 5MB 的 PostgreSQL，它可以免费托管一个应用程序），Heroku 是我的首选位置. 对于有几个付费客户的“严重生产部署”，具有服务水平协议，有专门的时间花在运维上，等等，我不能完全让自己将那么多控制权转移到 Heroku，然后是 AWS 或我们自己的服务器一直是首选的托管平台。

Ultimately, it's about what works best for you. You say you're "a beginner programmer" - it might just be that using Heroku will let you focus on writing Ruby, and not have to spend time getting all the other infrastructure around your code built up. I'd definitely give it a try.

归根结底，这是关于什么最适合你。您说您是“初学者程序员”- 可能只是使用 Heroku 可以让您专注于编写 Ruby，而不必花时间围绕您的代码构建所有其他基础设施。我肯定会试一试。

---

---

Note, AWS does actually have a PaaS offering, Elastic Beanstalk, that supports Ruby, Node.js, PHP, Python, .NET and Java. I think generally most people, when they see "AWS", jump to things like EC2 and S3 and EBS, which are definitely IaaS offerings

请注意，AWS 实际上有一个 PaaS 产品Elastic Beanstalk，它支持 Ruby、Node.js、PHP、Python、.NET 和 Java。我认为通常大多数人在看到“AWS”时会跳到 EC2、S3 和 EBS 之类的东西，它们绝对是 IaaS 产品

回答by Pravin Mishra

As Kristian Glass Said, there is no comparison between IaaS(AWS) and PaaS(Heroku, EngineYard).

正如 Kristian Glass 所说，IaaS（AWS）和 PaaS（Heroku，EngineYard）之间没有可比性。

PaaS basically helps developers to speed the development of app,thereby saving money and most importantly innovating their applications and business instead of setting up configurations and managing things like servers and databases. Other features buying to use PaaS is the application deployment process such as agility, High Availability, Monitoring, Scale / Descale, limited need for expertise, easy deployment, and reduced cost and development time.

PaaS 基本上帮助开发人员加快应用程序的开发，从而节省资金，最重要的是创新他们的应用程序和业务，而不是设置配置和管理服务器和数据库之类的东西。购买使用 PaaS 的其他功能是应用程序部署过程，例如敏捷性、高可用性、监控、扩展/缩减、对专业知识的需求有限、易于部署以及降低成本和开发时间。

But still there is a dark side to PaaS which lead barrier to PaaS adoption :

但是 PaaS 仍然有一个阴暗面，它导致了 PaaS 采用的障碍：

• Less Control over Server and databases
• Costs will be very high if not governed properly
• Premature and dubious in current day and age

• 减少对服务器和数据库的控制
• 如果管理不当，成本将非常高
• 在当今时代过早和可疑

Apart from above you should have enough skill set to mange you IaaS:

除了上述之外，您应该有足够的技能来管理您的 IaaS：

• Hardware acquisition
• Operating System
• Server Software
• Server Side Scripting Environment
• Web server
• Database Management System(Mysql, Redis etc)
• Configure production server
• Tool for testing and deployment
• Monitoring App
• High Availability
• Load Blancing/ Http Routing
• Service Backup Policies
• Team Collaboration
• Rebuild Production

• 硬件采购
• 操作系统
• 服务器软件
• 服务器端脚本环境
• 网络服务器
• 数据库管理系统（Mysql、Redis等）
• 配置生产服务器
• 测试和部署工具
• 监控应用
• 高可用性
• 负载均衡/Http 路由
• 服务备份策略
• 团队协作
• 重建生产

If you have small scale business, PaaS will be best option for you:

如果您的业务规模较小，PaaS 将是您的最佳选择：

• Pay as you Go
• Low start up cost
• Leave the plumbing to expert
• PaaS handles auto scaling/descaling, Load balancing, disaster recovery
• PaaS manages all security requirements
• PaaS manages reliability, High Availability
• Paas manages many third party add-ons for you

• 现收现付
• 启动成本低
• 将管道交给专家
• PaaS 处理自动缩放/去缩放、负载平衡、灾难恢复
• PaaS 管理所有安全要求
• PaaS 管理可靠性、高可用性
• Paas 为您管理许多第三方插件

It will be totally individual choice based on requirement. You can have details on my PPT Hosting Rails Apps.

这将完全是基于需求的个人选择。您可以在我的 PPT Hosting Rails Apps 中获得详细信息。

回答by sivi

Actually you can use both - you can develop an app with amazon servers ec2. Then push it (with git) to heroku for free for awhile (use heroku free tier to serve it to the public) and test it like so. It is very cost effective in comparison to rent a server, but you will have to talk with a more restrictive heroku api which is something you should think about. Source: this method was adopted for one of my online classes "Startup engineering from Coursera/Stanford by Balaji S. Srinivasan and Vijay S. Pande

实际上，您可以同时使用两者 - 您可以使用亚马逊服务器 ec2 开发应用程序。然后将它（使用 git）免费推送到 heroku 一段时间（使用 heroku 免费层将它提供给公众）并像这样测试它。与租用服务器相比，这是非常划算的，但是您必须使用限制性更强的 heroku api，这是您应该考虑的事情。来源：这种方法被用于我的在线课程之一“Coursera/Stanford 的启动工程，作者是 Balaji S. Srinivasan 和 Vijay S. Pande

回答by BricoleurDev

There are a lot of different ways to look at this decision from development, IT, and business objectives, so don't feel bad if it seems overwhelming. But also - don't overthink scalability.

从开发、IT 和业务目标来看，有很多不同的方式来看待这个决定，所以如果它看起来势不可挡，不要感到难过。而且 - 不要过度考虑可扩展性。

Think about your requirements.

想想你的要求。

I've engineered websites which have serviced over 8M uniques a day and delivered terabytes of video a week built on infrastructures starting at $250k in capital hardware unr by a huge $MM IT labor staff.

我设计的网站每天为超过 800 万个独立用户提供服务，每周提供 TB 级视频，这些网站建立在基础设施上，起价为 25 万美元的资本硬件，由庞大的 MM IT 劳动力人员组成。

But I've also had smaller websites which were designed to generate $10-$20k per year, didn't have very high traffic, db or processing requirements, and I ran those off a $10/mo generic hosting account without compromise.

但是我也有一些较小的网站，这些网站旨在每年产生 10 到 2 万美元，没有很高的流量、数据库或处理要求，我用 10 美元/月的通用托管帐户运行这些网站而没有妥协。

In the future, deployment will look more like Heroku than AWS, just because of progress. There is zero value in the IT knob-turning of scaling internet infrastructures which isn't increasingly automatable, and none of it has anything to do with the value of the product or service you are offering.

未来，部署看起来更像 Heroku，而不是 AWS，只是因为进步。扩展互联网基础设施的 IT 旋钮的价值为零，这不会越来越自动化，而且与您提供的产品或服务的价值没有任何关系。

Also, keep in mind with a commercial website - scalability is what we often call a 'good problem to have' - although scalability issues with sites like Facebook and Twitter were very high-profile, they had zero negative effect on their success - the news might have even contributedto more signups (all press is good press).

此外，请记住商业网站 - 可扩展性是我们通常所说的“好问题” - 尽管 Facebook 和 Twitter 等网站的可扩展性问题非常引人注目，但它们对其成功的负面影响为零 - 新闻甚至可能促成了更多的注册（所有媒体都是好媒体）。

If you have a service which is generating a 100k+ uniques a day and having scaling issues, I'd be glad to take it off your hands for you no matter what the language, db, platform, or infrastructure you are running on!

如果您的服务每天生成 10 万多个唯一身份并且存在扩展问题，那么无论您运行的是何种语言、数据库、平台或基础架构，我都很乐意为您解决问题！

Scalability is a fixable implementation problem - not having customers is an existential issue.

可扩展性是一个可修复的实现问题——没有客户是一个存在的问题。

回答by Hieu Pham

Well, people usually ask this question: Heroku or AWS when starting to deploy something.

好吧，人们通常会问这个问题：开始部署某些东西时，Heroku 还是 AWS。

My experiment of using both of Heroku & AWS, here is my quick review and comparison:

我同时使用 Heroku 和 AWS 的实验，这是我的快速回顾和比较：

Heroku

赫鲁库

• One command to deploy whatever your project types: Ruby on Rails, Nodejs
• So many 1-click to integrate plugins & third parties: It is super easy to start with something.
• Don't have auto-scaling; that means you need to scale up/down manually
• Cost is expensive, especially, when system needs more resources
• Free instance available
• The free instance goes to sleep if it is inactive.
• Data center: US & EU only
• CAN dive into/access to machine level by using Heroku run bash(Thanks, MJafar Mash for the advice) but it is kind of limited! You don't have full access!
• Don't need to know too much about DevOps

• 部署任何项目类型的命令：Ruby on Rails、Nodejs
• 如此多的一键集成插件和第三方：从某些东西开始非常容易。
• 没有自动缩放；这意味着您需要手动放大/缩小
• 成本昂贵，尤其是当系统需要更多资源时
• 提供免费实例
• 如果空闲实例处于非活动状态，则它会进入睡眠状态。
• 数据中心：仅限美国和欧盟
• 可以通过使用Heroku run bash（感谢 MJafar Mash 的建议）深入/访问机器级别，但它是有限的！您没有完全访问权限！
• 不需要对 DevOps 了解太多

AWS - EC2

AWS - EC2

• This just like a machine with pre-config OS (or not), so you need to install software, library to make your website/service go online.
• Plugin & Library need to be integrated manually, or automation script (public script & written by you)
• Auto scaling & load balancer are the supported services, just learn how to config & integrate to your system
• Cost is quite cheap, depends on which services and number of hours you use it
• There are several free hours for T2.micro instances, but usually, you will pay few dollars every month (if still using T2.micro)
• Your free instance won't go to sleep, available 24/7 (because you may pay for it :) )
• Data center: around the world. Pick the region which is the best fit for you.
• Dive into machine level. So you can enjoy it
• Some knowledge about DevOps, but it is okay, Stackoverflow is helpful there!

• 这就像一台有预配置操作系统（或没有）的机器，所以你需要安装软件、库来让你的网站/服务上线。
• Plugin & Library 需要手动集成，或者自动化脚本（公共脚本&由你编写）
• Auto Scaling 和负载均衡器是受支持的服务，只需学习如何配置和集成到您的系统
• 成本相当便宜，取决于您使用的服务和小时数
• T2.micro 实例有几个免费小时，但通常，您每个月会支付几美元（如果仍在使用 T2.micro）
• 您的免费实例不会进入睡眠状态，24/7 可用（因为您可能会为此付费 :)）
• 数据中心：遍布全球。选择最适合您的地区。
• 潜入机器级别。所以你可以享受它
• 关于 DevOps 的一些知识，但没关系，Stackoverflow 在那里很有帮助！

AWS Elastic Beanstalkan alternative of Heroku, but cheaper

AWS Elastic Beanstalk是 Heroku 的替代品，但更便宜

• Elastic Beanstalk was announced as a public beta from 2010; it helps we easier to work with deployment. For detail please go here

• Beanstalk is free, the cost you will pay will be for the services you use & number of hours of usage.

• I use Elastic Beanstalk for a long time, and I think it can be the replacement of Heroku and cheaper!

• Elastic Beanstalk 于 2010 年宣布为公开测试版；它帮助我们更轻松地进行部署。详情请到这里

• Beanstalk 是免费的，您将支付的费用是您使用的服务和使用小时数。

• Elastic Beanstalk 用了很久，觉得可以替代Heroku，而且更便宜！

Summary

概括

• Heroku: Easy at beginning, FREEinstance, but expensive later
• AWS: Not easy, free hours available, kind of cheaper, Beanstalk should be concerned to use

• Heroku：一开始很简单，免费实例，但后来很贵
• AWS：不容易，有免费时间，有点便宜，Beanstalk 应该关心使用

So in my current system, I use Heroku for staging and Beanstalk for production!

所以在我当前的系统中，我使用 Heroku 进行登台，使用 Beanstalk 进行生产！

回答by Iain Collins

The existing answers are broadly accurate:

现有的答案大致准确：

• Heroku is very easy to use and deploy to, can be easily configured for auto-deployment a repository (eg GitHub), has lots of third party add-ons and charges more per instance.

• AWS has a wider range of competitively priced first party services including DNS, load balancing, cheap file storage and has enterprise features like being able to define security policies.

• Heroku 非常易于使用和部署，可以轻松配置为自动部署存储库（例如 GitHub），具有许多第三方附加组件并且每个实例收费更高。

• AWS 拥有更广泛的价格具有竞争力的第一方服务，包括 DNS、负载平衡、廉价的文件存储，并具有能够定义安全策略等企业功能。

For the tl;drskip to the end of this post.

对于tl;dr，请跳至本文末尾。

AWS ElasticBeanstalk is an attempt to provide a Heroku-like autoscaling and easy deployment platform. As it uses EC2 instances (which it creates automatically) EB servers can do everything any other EC2 instance can do and it's cheap to run.

AWS ElasticBeanstalk 试图提供一个类似于 Heroku 的自动扩展和简单的部署平台。由于它使用 EC2 实例（它会自动创建），因此 EB 服务器可以执行任何其他 EC2 实例可以执行的所有操作，并且运行成本低廉。

Deployment with EB is very slow; deploying an update can take 10-15 minutes per server and deploying to a larger cluster can take the best part of an hour - compared to just seconds to deploy an update on Heroku. Deployments on EB are not handled particularly seamlessly either, which may impose constraints on application design.

使用 EB 部署非常慢；部署更新每台服务器可能需要 10-15 分钟，而部署到更大的集群可能需要一个小时的时间——相比之下，在 Heroku 上部署更新只需几秒钟。EB 上的部署也没有特别无缝地处理，这可能会对应用程序设计施加限制。

You can use all the services ElasticBeanstalk uses behind the scenes to build your own bespoke system (with CodeDeploy, Elastic Load Balancer, Auto Scaling Groups - and CodeCommit, CodeBuild and CodePipeline if you want to go all in) but you can definitely spend a good couple of weeks setting it up the the first time as it's fairly convoluted and slightly tricker than just configuring things in EC2.

您可以使用 ElasticBeanstalk 在幕后使用的所有服务来构建您自己的定制系统（使用 CodeDeploy、Elastic Load Balancer、Auto Scaling Groups - 以及 CodeCommit、CodeBuild 和 CodePipeline，如果您想全力以赴），但您绝对可以花很多钱第一次设置它需要几个星期，因为它比仅仅在 EC2 中配置东西相当复杂且稍微复杂一些。

AWS Lightsail offers a competitively priced hosting option, but doesn't help with deployment or scaling - it's really just a wrapper for their EC2 offering (but costs much more). It lets you automatically run a bash script on initial setup, which is nice touch but it's pricy compared to the cost of just setting up an EC2 instance (which you can also do programmatically).

AWS Lightsail 提供价格具有竞争力的托管选项，但对部署或扩展没有帮助 - 它实际上只是其 EC2 产品的包装器（但成本更高）。它允许您在初始设置时自动运行 bash 脚本，这很好，但与仅设置 EC2 实例的成本（您也可以通过编程方式进行）相比，这很昂贵。

Some thoughts on comparing (to try and answer the questions, albeit in a roundabout way):

关于比较的一些想法（尝试回答问题，尽管以迂回的方式）：

1. Don't underestimate how much work system administration is, including keeping everything you have installed up to date with security patches (and occasional OS updates).

2. Don't underestimate how much of a benefit automatic deployment, auto-scaling, and SSL provisioning and configuration are.

   Automatic deployment when you update your Git repository is effortless with Heroku. It is near instant, graceful so there are no outages for end users and can be set to update only if the tests / Continuous Integration passes so you don't break your site if you deploy broken code.

   You can also use ElasticBeanstalk for automatic deployment, but be prepared to spend a week setting that up the first time - you may have to change how you deploy and build assets (like CSS and JS) to work with how ElasticBeanstalk handles deployments or build logic into your app to handle deployments.

   Be aware in estimating costs that for seamless deployment with no outage on EB you need to run multiple instances - EB rolls out updates to each server individually so that your service is not degraded - where as Heroku spins up a new dyno for you and just deprecates the old service until all the requests to it are done being handled (then it deletes it).

   Interestingly, the hosting cost of running multiple servers with EB can be cheaper than a single Heroku instance, especially once you include the cost of add-ons.

1. 不要低估系统管理的工作量，包括使用安全补丁（以及偶尔的操作系统更新）使您安装的所有内容保持最新。

2. 不要低估自动部署、自动扩展以及 SSL 供应和配置的好处。

   使用 Heroku 可以轻松地在更新 Git 存储库时自动部署。它几乎是即时的、优雅的，因此最终用户不会中断，并且可以设置为仅在测试/持续集成通过时更新，这样在部署损坏的代码时就不会破坏站点。

   您还可以使用 ElasticBeanstalk 进行自动部署，但第一次要准备好花一周的时间进行设置 - 您可能需要更改部署和构建资产（如 CSS 和 JS）的方式，以使用 ElasticBeanstalk 处理部署或构建逻辑的方式进入您的应用程序以处理部署。

   请注意，在估算成本时，要在 EB 上无中断地进行无缝部署，您需要运行多个实例 - EB 会分别向每个服务器推出更新，以便您的服务不会降级 - 而 Heroku 会为您启动一个新的 dyno 并且只是弃用旧服务，直到处理完所有对它的请求（然后将其删除）。

   有趣的是，使用 EB 运行多台服务器的托管成本可能比单个 Heroku 实例便宜，尤其是当您包括附加组件的成本时。

Some other issues not specifically asked about, but raised by other answers:

其他一些没有具体询问但由其他答案提出的问题：

1. Using a different provider for production and development is a bad idea.

   I am cringing that people are suggesting this. While ideally code should run just fine on any reasonable platform so it's as portable as possible, versions of software on each host will vary greatly and just because code runs in staging doesn't mean it will run in production (e.g. major Node.js/Ruby/Python/PHP/Perl versions can differ in ways that make code incompatible, often in silent ways that might not be caught even if you have decent test coverage).

   What is a good idea is to leverage something like Heroku for prototyping, smaller projects and microsites - so you can build and deploy things quickly without investing a lot of time in configuration and maintenance.

   Be sure to factor in the cost of running both production and pre-production instances when making that decision, not forgetting the cost of replicating the entire environment (including third party services such as data stores / add ons, installing and configuring SSL, etc).

2. If using AWS, be wary of AWS pre-configured instances from vendors like Bitnami - they are a security nightmare. They can expose lots of notoriously vulnerable applications by default without mentioning it in the description.

   Consider instead just using a well supported mainstream distribution, such as Ubuntu or Debian (or CentOS if you need RPM support).

   Note: Amazon offer have their own distribution called Amazon Linux, which uses RPM, but it's EC2 specific and less well supported by third party/open source software.

3. You could also setup an EC2 instance on AWS (or Lightsail) and configure with something like flynnor dokkuon it - on which you could then deploy multiple sites easily, which can be worth it if you maintain a lot of services or want to be able to spin up new things easily. However getting it set up is not as automagic as just using Heroku and you can end up spending a lot of time configuring and maintaining it (to the point I've found deploying using Amazon clustering and Docker Swarm to be easier than setting them up; YMMV).

1. 使用不同的提供程序进行生产和开发是一个坏主意。

   我很害怕人们提出这个建议。虽然理想情况下代码应该在任何合理的平台上运行得很好，因此它尽可能可移植，但每个主机上的软件版本会有很大差异，仅仅因为代码在暂存中运行并不意味着它会在生产中运行（例如主要的 Node.js/ Ruby/Python/PHP/Perl 版本可能会在使代码不兼容的方式上有所不同，通常以静默方式出现，即使您有不错的测试覆盖率也可能不会被捕获）。

   一个好主意是利用 Heroku 之类的东西进行原型设计、小型项目和微型站点 - 这样您就可以快速构建和部署事物，而无需在配置和维护上投入大量时间。

   在做出决定时，请务必考虑运行生产和预生产实例的成本，不要忘记复制整个环境的成本（包括第三方服务，如数据存储/附加组件、安装和配置 SSL 等） .

2. 如果使用 AWS，请注意来自 Bitnami 等供应商的 AWS 预配置实例 - 它们是安全噩梦。默认情况下，它们可以公开许多臭名昭著的易受攻击的应用程序，而无需在说明中提及。

   考虑使用支持良好的主流发行版，例如 Ubuntu 或 Debian（或者 CentOS，如果您需要 RPM 支持）。

   注意：Amazon 产品有自己的发行版，称为 Amazon Linux，它使用 RPM，但它是 EC2 特定的，第三方/开源软件的支持不太好。

3. 您还可以在 AWS（或 Lightsail）上设置一个 EC2 实例并在其上配置诸如flynn或dokku 之类的东西 - 然后您可以轻松地在其上部署多个站点，如果您维护大量服务或想要成为能够轻松地创造新事物。然而，设置它并不像使用 Heroku 那样自动，您最终可能会花费大量时间配置和维护它（我发现使用 Amazon 集群和 Docker Swarm 进行部署比设置它们更容易； YMMV）。

I have used AWS EC instances (alone and in clusters), Elastic Beanstalk and Lightsail and Heroku at the same time depending on the needs of the project I'm working on.

根据我正在处理的项目的需要，我同时使用了 AWS EC 实例（单独和在集群中）、Elastic Beanstalk、Lightsail 和 Heroku。

I hate spending time configuring services but my Heroku bill would be thousands per year if I used it for everything and AWS works out a fraction of the cost.

我讨厌花时间配置服务，但如果我将 Heroku 用于所有事情，我的 Heroku 账单每年将达到数千美元，而 AWS 只是成本的一​​小部分。

tl;dr

tl;博士

If money was never an issue I'd use Heroku for almost everything as it's a huge timesaver - but I'd still want to use AWS for more complicated projects where I need the flexibility and more advanced services that Heroku doesn't offer.

如果钱从来都不是问题，我会在几乎所有事情上都使用 Heroku，因为它可以节省大量时间——但我仍然希望将 AWS 用于更复杂的项目，在这些项目中，我需要 Heroku 不提供的灵活性和更高级的服务。

The ideal scenario for me would be if ElasticBeanstalk just worked more like Heroku - i.e. with easier configuration and quicker and a better deployment mechanism.

对我来说，理想的情况是 ElasticBeanstalk 的工作方式更像 Heroku——即配置更简单，部署机制更快更好。

An example of a service that is almost thisis now.sh, which actually uses AWS behind the scenes, but makes deployments and clustering as easy as it is on Heroku (with automatic SSL, DNS, graceful deployments, super-easy cluster setup and management).

一个几乎与此类似的服务示例是now.sh，它实际上在幕后使用 AWS，但使部署和集群变得像在 Heroku 上一样简单（具有自动 SSL、DNS、优雅的部署、超级简单的集群设置和管理）。

I've used it quite lot for both Node.js app and Docker image deployments, the major caveat is the instances are shared (something reflected in their lower cost) and currently no option to buy dedicated instances. However their open source deployment tool 'now' can also be used to deploy to dedicated instances on AWS as well as Google Cloud and Azure.

我已经在 Node.js 应用程序和 Docker 映像部署中大量使用它，主要的警告是实例是共享的（反映在它们的较低成本上）并且目前没有购买专用实例的选项。然而，他们的开源部署工具“现在”也可用于部署到 AWS 以及 Google Cloud 和 Azure 上的专用实例。

回答by Kendall Miller

It's been a significant percentage of our business migrating people from Heroku to AWS. There are advantages to both, but it's gets messy on Heroku after a while... once you need a certain level of complexity no longer easy to maintain with Heroku's limitations.

我们业务的很大一部分是将人员从 Heroku 迁移到 AWS。两者都有优点，但一段时间后它在 Heroku 上变得混乱......一旦你需要一定程度的复杂性，就不再容易用 Heroku 的限制来维护。

That said, there are increasingly options to have the ease of Heroku and the flexibility of AWS by being on AWS with great frameworks/tools.

也就是说，通过使用具有出色框架/工具的 AWS 来获得 Heroku 的易用性和 AWS 的灵活性的选择越来越多。

回答by Saurav Prakash

Funny thing is Heroku actually uses AWS on the backend. It takes away all the overhead and does architecture management on EC2 for you. (Got that knowledge from a senior engineer at a Big Company during an Interview)

有趣的是 Heroku 实际上在后端使用 AWS。它消除了所有开销并为您在 EC2 上进行架构管理。（在面试中从大公司的高级工程师那里得到的知识）

回答by prasoon

Well Heroku uses AWS in background, it all depends on the type of solution you need. If you are a core linux and devops guy you are not worried about creating vm from scratch like selecting ami choosing palcement options etc, you can go with AWS. If you want to do things on surface level without having those nettigrities you can go with heroku.

Heroku 在后台使用 AWS，这完全取决于您需要的解决方案类型。如果你是一个核心 linux 和 devops 的人，你不担心从头开始创建 vm，比如选择 ami 选择 palcement 选项等，你可以选择 AWS。如果你想在没有那些网络的情况下在表面上做事情，你可以使用 heroku。