当 AWS 存在时，为什么人们会使用 Heroku？ Heroku 与 AWS 的区别是什么？ [关闭]

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

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

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

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

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

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

速度

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

安全

我已经看到很多内部维护的生产服务器在安全更新方面远远落后，或者只是总体上很糟糕。使用 Heroku，您可以让其他人管理此类事情，这取决于您如何看待它，这不是福就是祸！

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

缩放

我在上面的 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

这个，有一个：

heroku scale web:2 worker:10

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

成本效益

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

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

（顺便说一句，但如果我从这里 (heroku run bash) 连接到测功机，粗略的外观显示 /proc/cpuinfo 中有 4 个内核和 36GB 的 RAM - 这让我相信我在 {1 }. Heroku dyno documentation 说每个 dyno 接收 512MB 的 RAM，所以我可能会与多达 71 个其他 dyno 共享。（关于 Heroku 的 AWS 实例的同质性我没有足够的数据，所以你的里程可能会有所不同） )

他们如何对抗竞争对手？

这个，恐怕真的帮不了你。我真正看过的唯一竞争对手是 Google App Engine - 当时我正在寻找部署 Java 应用程序，而 the amount of restrictions on usable frameworks and technologies 令人难以置信。这不仅仅是“Java 的事情”——一般限制和必要考虑的数量（the FAQ 暗示了几个）似乎不太方便。相比之下，部署到 Heroku 是一个梦想。

结论

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

最终，它是关于什么对你最有效。你说你是“初学者程序员”——可能只是使用 Heroku 可以让你专注于编写 Ruby，而不必花时间构建代码周围的所有其他基础设施。我一定会试一试的。

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

---

AWS / Heroku 对于小型爱好项目都是免费的（开始）。

如果您想立即启动一个应用程序，而不需要对架构进行太多定制，那么请选择 Heroku。

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

Heroku

平台即服务 (PAAS)

良好的文档

具有内置工具和架构。

在设计应用程序时对架构的控制有限。

负责部署（通过 GitHub 自动或通过 git 命令或 CLI 手动）。

不费时间。

AWS

基础设施即服务 (IAAS)

多才多艺——拥有EC2、LAMBDA、EMR等多种产品。

可以使用专用实例对架构进行更多控制，例如选择操作系统、软件版本等。后端层不止一个。

Elastic Beanstalk 是一个类似于 Heroku 的 PAAS 的功能。

可以使用自动部署，也可以自行部署。

---

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

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

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

减少对服务器和数据库的控制

如果管理不当，成本将非常高

在当今时代过早和可疑

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

硬件获取

操作系统

服务器软件

服务器端脚本环境

网络服务器

数据库管理系统（Mysql、Redis 等）

配置生产服务器

测试和部署工具

监控应用

高可用性

负载平衡/ Http 路由

服务备份策略

团队协作

重建生产

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

现收现付

低启动成本

把管道交给专家

PaaS 处理自动缩放/除缩放、负载平衡、灾难恢复

PaaS 管理所有安全要求

PaaS 管理可靠性、高可用性

Paas 为您管理许多第三方插件

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

---

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

想想你的要求。

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

但是我也有一些较小的网站，这些网站的设计年收入为 10 到 2 万美元，没有很高的流量、数据库或处理要求，我用 10 美元/月的通用托管帐户毫不妥协地运行了这些网站。

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

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

如果您的服务每天产生 100k+ 的唯一性并且存在扩展问题，那么无论您运行的是什么语言、数据库、平台或基础架构，我都很乐意为您解除它！

可扩展性是一个可解决的实施问题——没有客户是一个存在的问题。

---

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

https://i.stack.imgur.com/EysMq.png

---

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

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

Heroku

部署任何项目类型的一个命令：Ruby on Rails、Nodejs

如此多的一键式集成插件和第三方：从某事开始非常容易。

没有自动缩放；这意味着您需要手动放大/缩小

成本昂贵，尤其是当系统需要更多资源时

提供免费实例

如果空闲实例处于非活动状态，则它会进入睡眠状态。

数据中心：仅限美国和欧盟

可以使用 Heroku run bash 潜入/访问机器级别（感谢 MJafar Mash 的建议），但它有点有限！您没有完全访问权限！

不需要对 DevOps 了解太多

AWS-EC2

这就像一台具有预配置操作系统（或没有）的机器，因此您需要安装软件、库以使您的网站/服务上线。

插件&库需要手动集成，或者自动化脚本（公共脚本&你写的）

自动缩放和负载均衡器是受支持的服务，只需了解如何配置和集成到您的系统

成本相当便宜，取决于您使用的服务和小时数

T2.micro 实例有几个免费小时，但通常，您每月需要支付几美元（如果仍在使用 T2.micro）

您的免费实例不会进入睡眠状态，24/7 可用（因为您可能会为此付费 :)）

数据中心：遍布全球。选择最适合您的地区。

深入机器级别。所以你可以尽情享受

对 DevOps 有一些了解，不过没关系，Stackoverflow 在那里很有帮助！

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

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

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

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

概括

Heroku：一开始很容易，免费实例，但后来很昂贵

卓：不容易，有免费时间，有点便宜，应该注意使用 Beanstalk

因此，在我当前的系统中，我使用 Heroku 进行暂存，使用 Beanstalk 进行生产！

---

现有答案大致准确：

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

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

对于 tl;dr 跳到这篇文章的末尾。

AWS ElasticBeanstalk 试图提供一个类似 Heroku 的自动缩放和简单的部署平台。由于它使用 EC2 实例（它自动创建），EB 服务器可以做任何其他 EC2 实例可以做的所有事情，而且运行起来很便宜。

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

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

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

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

不要低估系统管理的工作量，包括使用安全补丁（以及偶尔的操作系统更新）使您安装的所有内容保持最新。不要低估自动部署、自动扩展以及 SSL 供应和配置的好处。使用 Heroku 可以在更新 Git 存储库时轻松进行自动部署。它几乎是即时的、优雅的，因此最终用户不会中断，并且可以设置为仅在测试/持续集成通过时更新，这样如果部署损坏的代码就不会破坏您的站点。您也可以使用 ElasticBeanstalk 进行自动部署，但要准备好花一周时间进行第一次设置 - 您可能必须更改部署和构建资产（如 CSS 和 JS）的方式，以使用 ElasticBeanstalk 处理部署或构建逻辑的方式进入您的应用程序以处理部署。请注意，在估算成本时，要在 EB 上不中断地进行无缝部署，您需要运行多个实例 - EB 单独向每个服务器推出更新，以便您的服务不会降级 - 而 Heroku 为您启动了一个新的 dyno 并且只是弃用旧服务，直到处理完所有对它的请求（然后将其删除）。有趣的是，使用 EB 运行多台服务器的托管成本可能比单个 Heroku 实例便宜，尤其是考虑到附加组件的成本。

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

使用不同的供应商进行生产和开发是一个坏主意。我很害怕人们提出这个建议。虽然理想情况下代码应该在任何合理的平台上运行良好，因此它尽可能可移植，但每个主机上的软件版本会有很大差异，仅仅因为代码在 staging 中运行并不意味着它会在生产中运行（例如主要的 Node.js/ Ruby/Python/PHP/Perl 版本可能在使代码不兼容的方式上有所不同，通常以静默方式出现，即使您有良好的测试覆盖率也可能不会被捕获）。一个好主意是利用 Heroku 之类的东西进行原型设计、较小的项目和微型站点 - 这样您就可以快速构建和部署事物，而无需花费大量时间进行配置和维护。在做出决定时一定要考虑运行生产和预生产实例的成本，不要忘记复制整个环境的成本（包括第三方服务，如数据存储/附加组件、安装和配置 SSL 等） .如果使用 AWS，请警惕来自 Bitnami 等供应商的 AWS 预配置实例 - 它们是安全噩梦。默认情况下，它们可以暴露许多臭名昭著的易受攻击的应用程序，而无需在描述中提及。考虑只使用支持良好的主流发行版，例如 Ubuntu 或 Debian（或 CentOS，如果您需要 RPM 支持）。注意：Amazon 提供了自己的发行版，称为 Amazon Linux，它使用 RPM，但它是 EC2 特定的，第三方/开源软件不太支持。您还可以在 AWS（或 Lightsail）上设置 EC2 实例并在其上配置 flynn 或 dokku 之类的东西 - 然后您可以在其上轻松部署多个站点，如果您维护大量服务或想要成为能够轻松启动新事物。然而，设置它并不像使用 Heroku 那样自动，你最终可能会花费大量时间来配置和维护它（我发现使用 Amazon 集群和 Docker Swarm 进行部署比设置它们更容易； YMMV）。

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

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

tl;博士

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

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

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

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

---

将人员从 Heroku 迁移到 AWS 在我们的业务中占很大比例。两者都有优点，但是一段时间后 Heroku 就会变得一团糟……一旦您需要某种程度的复杂性，由于 Heroku 的限制而不再容易维护。

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

---

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

---

出色地！我观察者 Heroku 以崭露头角和新生的开发人员而闻名，而 AWS 则具有高级开发人员角色。 DigitalOcean 也是这方面的主要参与者。 Cloudways 使通过单击 DigitalOcean 和 AWS 创建 Lamp 堆栈变得非常容易。一键更新所有服务和软件包比手动完成所有事情要好得多。

您可以在此处完整查看：https://www.cloudways.com/blog/host-php-on-aws-cloud/

---

有时，我想知道为什么人们将 AWS 与 Heroku 进行比较。 AWS 是一种 IAAS（基础设施即服务），它清楚地说明了该系统的稳健性和计算能力。另一方面，Heroku 只是一个 SAAS，它基本上只是 AWS 服务的一小部分。那么，当您可以使用 Heroku 将您的第一个产品发送到 Prime 时，为什么还要为设置 AWS 而苦苦挣扎。

Heroku 是免费、简单且易于将几乎所有类型的堆栈部署到网络的。 Heroku 是专门为绕过将应用程序发送到实时服务器的所有麻烦而构建的。

尽管如此，您可能希望使用双方的任何教程部署您的应用程序并进行比较

AWS DOCS 和 Heroku Docs

---

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

---

尽管 AWS 和 Heroku 都是云平台，但它们是不同的，因为 AWS 是 IaaS 而 Heroku 是 PaaS

---

Amazon Web Services (AWS) 提供从 IaaS 到 PaaS 的大量服务，保证 99.9999999% 的数据和基础设施的持久性和可用性。 AWS 为开发人员提供基础设施自动化以及多种工具来管道其应用程序部署过程。

另一方面，Heroku 只是 PaaS，它提供在其云上管理您的平台的服务。无论是基础设施还是安全性，它都与 AWS 无关。

---

Heroku 就像 AWS 的子集。它只是平台即服务，而 AWS 可以在任何级别上实施。

实施取决于业务需求。如果它适合任何一个，请相应地使用。

---