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

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

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

为了让您的代码在AWS上运行并看起来有点像Heroku部署，您需要一些EC2实例-您需要在它们上安装负载均衡器/缓存层（例如清漆），您需要运行类似乘客和nginx的实例来为您的代码提供服务，您需要部署和配置类似PostgreSQL的集群数据库实例。您需要一个具有类似卡皮斯特拉诺的部署系统，以及一些执行日志聚合的东西。

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

所以你到目前为止，你想扩大规模。太好了。您正在使用木偶进行EC2部署，对吧？所以现在您配置Capistrano文件以根据需要向上/向下旋转实例；您重新调整Puppet配置，以便Varish了解Web工作者实例并将自动在它们之间共享。或者你heroku scale web:+5。

希望这能让你对两者之间的比较有一个想法。现在谈谈你的具体观点：

速度

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

安全合规

我见过很多内部维护的生产服务器，它们在安全更新方面远远落后，或者只是通常组合得不好。有了Heroku，你就有其他人来管理这种事情了，这是福是祸，取决于你如何看待它！

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

缩放

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

web:    bundle exec rails serverworker: bundle exec rake jobs:work

这个，用a：

heroku scale web:2 worker:10

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

成本效益

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

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

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

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

这个恐怕我帮不上忙。我唯一真正关注过的竞争对手是谷歌应用引擎——当时我正在考虑部署Java应用程序，而对可用框架和技术的限制数量非常令人讨厌。这不仅仅是“Java的事情”——大量的一般限制和必要的考虑（的FAQ暗示了几个）似乎不太方便。相比之下，部署到Heroku一直是一个梦想。

结论

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

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

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

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

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

但PaaS仍然存在阴暗面，这会阻碍PaaS的采用：

• 对服务器和数据库的控制更少
• 如果管理不当，成本将非常高
• 早熟和可疑在今天和年龄

除此之外，你应该有足够的技能来管理你的IaaS：

• 硬件购置
• 操作系统
• 服务器软件
• 服务端脚本环境
• web服务器
• 数据库管理系统（MySQL、Redis等）
• 配置正式服
• 测试和部署工具
• 监控应用程序
• 高可用
• 负载合并/Http路由
• 服务备份策略
• 团队协作模式
• 重建生产

如果您有小型企业，PaaS将是您的最佳选择：

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

这将是完全基于需求的个人选择。你可以在我的PPT托管Rails应用程序上有详细信息。

从开发、IT和业务目标的角度来看，有很多不同的方法来看待这个决定，所以如果它看起来令人难以承受，不要感到难过。但是也不要过度考虑可扩展性。

想想你的所需资源。

我设计的网站每天服务超过8M个独立的网站，每周交付TB的视频，这些视频建立在基础设施上，由一个巨大的MM IT员工以25万美元的资本硬件开始。

但我也有一些较小的网站，这些网站的设计目标是每年产生10美元2万美元，没有很高的流量，数据库或处理要求，我毫不妥协地用10美元/mo的通用托管帐户运行这些网站。

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

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

如果你有一个每天生成100k+Uniques的服务，并且有缩放问题，我很乐意为你提供它，无论你运行的是什么语言、数据库、平台或基础设施！

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

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

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

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

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

Heroku

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

AWS

• 基础设施即服务（IAAS）
• 多功能-有许多产品，如EC2，LAMBDA，EMR等。
• 可以使用专用实例对架构进行更多控制，例如选择操作系统、软件版本等。有多个后端层。
• 弹性豆茎是一个类似于Heroku的PAAS的功能。
• 可以使用自动部署，或自己滚动。

将人员从Heroku迁移到AWS是我们业务的重要组成部分。两者都有优势，但一段时间后在Heroku上会变得混乱……一旦您需要一定程度的复杂性，就不再容易维护Heroku的局限性。

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

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

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

Heroku

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

AWS-EC2

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

AWS弹性豆茎 Heroku的替代品，但更便宜

• 弹性豆茎从2010年开始作为公开测试版发布；它有助于我们更容易地进行部署。有关详细信息，请访问

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

• 我使用弹性豆茎很长一段时间，我认为它可以替代Heroku和更便宜！

总结

• Heroku：开始时很容易，免费实例，但后来很昂贵
• AWS：不容易，提供免费时间，有点便宜，应该关注Beanstrak的使用

所以在我目前的系统中，我使用Heroku进行分期，使用Beanstemk进行生产！

现有的答案大致准确：

• Heroku非常易于使用和部署，可以轻松配置为自动部署存储库（例如GitHub），有很多第三方插件，每个实例收取更多费用。

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

对于tl； dr，请跳到本文末尾。

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

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

您可以使用ElasticBeanstrak在幕后使用的所有服务来构建您自己的定制系统（使用CodeDeploy，Elastic Load Balancer，Auto Scaling Group-以及CodeCommit，CodeBuild和CodePipeline，如果您想全力以赴），但您肯定可以花几个星期的时间第一次设置它，因为它相当复杂，并且比在EC2中配置东西稍微棘手。

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

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

1. 不要低估系统管理的工作量，包括通过安全补丁（和偶尔的操作系统更新）保持安装的所有内容都是最新的。

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

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

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

   在估计成本时要注意，对于在EB上没有中断的无缝部署，您需要运行多个实例-EB单独向每个服务器推出更新，以便您的服务不会降级-其中Heroku为您旋转一个新的dyno，只是弃用旧服务，直到处理完所有对它的请求（然后删除它）。

   有趣的是，使用EB运行多个服务器的托管成本可能比单个Heroku实例便宜，尤其是在包含附加组件成本的情况下。

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

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

   虽然理想情况下，代码应该在任何合理的平台上运行得很好，所以它尽可能的可移植，但每个主机上的软件版本会有很大的差异，仅仅因为代码在暂存中运行并不意味着它会在生产环境中运行（例如，主要的Node.js/Ruby/Python/PHP/Perl版本可能会在使代码不兼容的方面有所不同，通常是以无声的方式，即使你有不错的测试覆盖率，也可能不会被发现）。

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

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

2. 如果使用AWS，请警惕来自Bitnami等供应商的AWS预配置实例-它们是一场安全噩梦。默认情况下，它们可以暴露许多众所周知的易受攻击的应用程序，而无需在描述中提及。

   考虑使用支持良好的主流发行版，例如Ubuntu或Debian（或CentOS，如果您需要每1k展现的收入支持）。

   注意：亚马逊提供了自己的发行版，称为亚马逊Linux，它使用每1k展现的收入，但它是EC2特定的，第三方/开源软件支持较少。

3. 您还可以在AWS（或Light的）上设置一个EC2实例，并使用flynn或dokku-然后您可以在其上轻松部署多个站点，如果您维护大量服务或希望能够轻松启动新事物，这是值得的。然而，设置它并不像使用Heroku那样自动，您最终可能会花费大量时间配置和维护它（我发现使用Amazon集群和Docker Swing部署比设置它们更容易；YMMV）。

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

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

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

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

嗯！我观察到Heroku以崭露头角和新生的开发人员而闻名，而AWS则拥有高级开发人员角色。DigitalOcean也是这一领域的主要参与者。Cloudways使单击DigitalOcean和AWS即可轻松创建Lamp堆栈。单击所有服务和软件包更新远比手动完成所有事情要好。

您可以在这里查看：https://www.cloudways.com/blog/host-php-on-aws-cloud/

有趣的是，Heroku实际上在后端使用AWS。它消除了所有的开销，并为您在EC2上进行架构管理。（在一次采访中从一家大公司的高级工程师那里了解到这一点）

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

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

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

AWS DOCS和Heroku文档

Heroku在后台使用AWS，这一切都取决于您需要的解决方案类型。如果您是核心linux和devops的人，您不担心从头开始创建虚拟机，例如选择ami、选择pal选项等，您可以使用AWS。如果您想在表面上做事情而没有那些网络问题，您可以使用heroku。

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

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

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