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

Question

我是初学者RoR程序员,他计划使用Heroku部署我的应用程序.来自我的其他顾问朋友的话说,Heroku非常简单,易于使用.唯一的问题是我仍然不知道Heroku做了什么......

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

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

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

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

4. 成本效率 - 像dyno这样的东西可以很容易地扩展.

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

请用外行英语术语来解释......我是初学程序员.

Answer 1

首先,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和中的AWS实例上运行eu-west.对你来说,这听起来像你想要的.对于其他人来说,这可能是更多的考虑因素.

安全

我已经看到很多内部维护的生产服务器在安全更新方面落伍,或者通常很难整合在一起.使用Heroku,你有其他人管理那种事情,这可能是一种祝福或诅咒,取决于你如何看待它!

部署时,您将有效地将代码直接交给Heroku.这可能是一个问题.他们关于Dyno Isolation的文章详述了他们的隔离技术(好像多个dynos在各个EC2实例上运行).几位同事表达了这些技术的问题和隔离的强度; 我真的没有足够的知识/经验来评论,但我目前的Heroku部署认为"足够好".对我来说这可能是一个问题,我不知道.

缩放

我在上面的IaaS vs 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个webdynos和10个workerdynos运行.很好,简单,容易.请注意,这web是一种特殊的dyno类型,它可以访问外部世界,并且位于其良好的Web流量多路复用器(可能是某种Varnish/nginx组合)之后,它们将相应地路由流量.您的工作人员可能会与消息队列进行交互以进行类似的路由,然后他们将通过环境中的URL获取该位置.

成本效益

很多人对此有很多不同的看法.目前,dyno小时为0.05美元/小时,相比之下,AWS微型实例为0.025美元/小时,AWS小型实例为0.09美元/小时.

Heroku的dyno文档说你有大约512MB的RAM,所以把dyno看作有点像EC2 micro实例可能并不太不合理.是否值得双倍的价格？你重视你的时间多少钱？在IaaS产品之上构建以达到此标准所需的时间和精力绝对不便宜.我无法真正回答这个问题,但不要低估设置和维护的"隐性成本".

(稍等一下,但是如果我从这里连接到dyno(heroku run bash),粗略的外观显示4个内核/proc/cpuinfo和36GB内存 - 这让我相信我在"高内存双超大实例" ".Heroku的赛道文档说,每个赛道接收512MB的RAM,所以我可能与其他多达71个DYNOS共享.(我没有关于Heroku的AWS实例的同质足够的数据,让您的milage可能会有所不同))

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

这个,我恐怕无法真正帮助你.我真正关注的唯一竞争对手是Google App Engine--当时我正在寻求部署Java应用程序,而且对可用框架和技术的限制令人难以置信.这不仅仅是"Java事物" - 一般限制和必要考虑因素(常见问题解答中的几个提示)似乎不太方便.相比之下,部署到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产品

Answer 2

AWS/Heroku对于小型业余爱好项目都是免费的(首先).

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

如果您希望专注于架构并能够使用不同的Web服务器,请选择AWS.根据您选择的服务/产品,AWS更耗时,但值得.AWS还提供了许多插件服务和产品.

Heroku的

• 平台即服务(PAAS)
• 好文档
• 有内置的工具和架构.
• 设计app时对架构的控制有限.
• 部署得到处理(通过GitHub自动或通过git命令或CLI手动).
• 不费时间.

AWS

• 基础设施即服务(IAAS)
• 多功能 - 有许多产品,如EC2,LAMBDA,EMR等.
• 可以使用专用实例来更好地控制体系结构,例如选择操作系统,软件版本等.有多个后端层.
• Elastic Beanstalk是一个类似于Heroku的PAAS的功能.
• 可以使用自动部署,也可以自行部署.

Answer 3

正如Kristian Glass Said所说,IaaS(AWS)和PaaS(Heroku,EngineYard)之间没有比较.

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

但PaaS仍然存在一个黑暗的一面,导致PaaS采用的障碍:

• 减少对服务器和数据库的控制
• 如果管理不当,成本将非常高
• 在当前和年龄中过早和可疑

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

• 硬件采集
• 操作系统
• 服务器软件
• 服务器端脚本环境
• 网络服务器
• 数据库管理系统(Mysql,Redis等)
• 配置生产服务器
• 用于测试和部署的工具
• 监控应用程序
• 高可用性
• 加载Blancing/Http路由
• 服务备份策略
• 团队协作
• 重建生产

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

• 现收现付
• 启动成本低
• 将管道留给专家
• PaaS处理自动扩展/除垢,负载平衡,灾难恢复
• PaaS管理所有安全要求
• PaaS管理可靠性,高可用性
• Paas为您管理许多第三方附加组件

根据要求,它将完全是个人选择.您可以在我的PPT Hosting Rails应用程序中获得详细信息.

Answer 4

实际上你可以使用两者 - 你可以开发一个亚马逊服务器ec2的应用程序.然后将它(使用git)免费推送到heroku一段时间(使用heroku免费套餐向公众提供)并进行测试.与租用服务器相比,这是非常划算的,但你必须与更严格的heroku api交谈,这是你应该考虑的事情.来源:我的在线课程"Balaji S. Srinivasan和Vijay S. Pande的Coursera/Stanford启动工程"采用了这种方法

Answer 5

从开发,IT和业务目标来看这个决策有很多不同的方法,所以如果看起来压倒性的话,不要感到难过.但也 - 不要过度思考可伸缩性.

考虑一下你的要求.

我设计的网站每天提供超过800万的独立服务,每周提供数TB的视频,建立在基础设施上,资金硬件价格高达25万美元,由一个巨大的MM工资人员组成.

但我也有一些较小的网站,这些网站的设计目标是每年产生10到2万美元,没有很高的流量,数据库或处理要求,而且我还没有妥协就将这些网站从10美元/月的通用主机帐户中运行.

在未来,部署将看起来更像Heroku而不是AWS,只是因为进步.IT旋钮的价值没有变化 - 缩小互联网基础设施的转变,这种基础设施不会越来越自动化,并且没有任何与您提供的产品或服务的价值有任何关系.

此外,请记住商业网站 - 可扩展性是我们通常所说的'好问题' - 尽管Facebook和Twitter等网站的可扩展性问题非常引人注目,但它们对其成功没有负面影响 - 新闻可能甚至有助于更多的注册(所有媒体都很好).

如果您的服务每天产生100k +唯一身份并且存在扩展问题,那么无论您运行的语言,数据库,平台或基础架构是什么,我都很乐意为您提供服务!

可伸缩性是一个可修复的实现问题 - 没有客户是存在问题.

Answer 6

好吧,人们通常会在开始部署某些东西时提出这个问题:Heroku或AWS.

我使用Heroku和AWS的实验,这是我的快速回顾和比较:

Heroku的

• 一个部署任何项目类型的命令:Ruby on Rails,Nodejs
• 如此多的单击即可集成插件和第三方:从一开始就非常容易.
• 没有自动缩放; 这意味着您需要手动放大/缩小
• 成本很高,尤其是当系统需要更多资源时
• 免费实例可用
• 如果空闲实例处于非活动状态,则它将进入休眠状
• 数据中心:仅限美国和欧盟
• 可以使用Heroku run bash(感谢,MJafar Mash的建议)深入/访问机器级别,但它有点受限!您没有完全访问权限!
• 不需要过多了解DevOps

AWS - EC2

• 这就像具有预配置OS(或不具备)的机器,因此您需要安装软件,库以使您的网站/服务上线.
• 插件和库需要手动集成,或自动化脚本(公共脚本和您编写)
• 自动扩展和负载均衡器是受支持的服务,只需了解如何配置和集成到您的系统
• 成本相当便宜,取决于您使用它的服务和小时数
• T2.micro实例有几个免费小时,但通常情况下,你每月需要支付几美元(如果仍然使用T2.micro)
• 你的免费实例不会一天24小时不睡觉(因为你可能会付钱:))
• 数据中心:遍布全球.选择最适合您的区域.
• 潜入机器级别.所以你可以享受它
• 关于DevOps的一些知识,但没关系,Stackoverflow在那里很有帮助!

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

• Elastic Beanstalk从2010年宣布为公开测试版; 它有助于我们更轻松地部署.详情请到这里

• Beanstalk是免费的,您将支付的费用将用于您使用的服务和使用小时数.

• 我使用Elastic Beanstalk很长一段时间了,我认为它可以替代Heroku并且更便宜!

摘要

• Heroku:开始时容易,免费实例,但后来很贵
• AWS:不容易,可用的免费时间,更便宜,应该关注使用Beanstalk

所以在我目前的系统中,我使用Heroku进行分段,使用Beanstalk进行制作!

Answer 7

现有答案大致准确:

• 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实例(您也可以以编程方式执行)的成本相比,它是昂贵的.

关于比较的一些想法(试图回答问题,尽管是以迂回的方式):

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

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

   使用Heroku轻松更新Git存储库时自动部署.它几乎是即时的,优雅的,因此最终用户没有中断,并且只有在测试/持续集成通过时才能设置为更新,因此如果部署损坏的代码,则不会破坏您的站点.

   您也可以使用ElasticBeanstalk进行自动部署,但要准备好花一周的时间进行首次设置 - 您可能必须更改部署和构建资产(如CSS和JS)的方式,以使用ElasticBeanstalk处理部署或构建逻辑的方式进入你的应用程序来处理部署.

   请注意估算无缝部署的成本,无需中断EB,您需要运行多个实例 - EB单独为每个服务器推出更新,以免您的服务降级 - Heroku为您提供新的dyno并且只是弃用旧服务,直到所有请求都被处理完毕(然后删除它).

   有趣的是,使用EB运行多个服务器的托管成本可能比单个Heroku实例便宜,特别是一旦包含附加组件的成本.

其他一些问题没有特别提出,但由其他答案提出:

1. 使用不同的生产和开发提供商是一个坏主意.

   我在说人们在暗示这一点.理想情况下,代码应该在任何合理的平台上运行得很好,因此它尽可能便携,每个主机上的软件版本会有很大差异,因为代码在分段中运行并不意味着它将在生产中运行(例如主要的Node.js/Ruby/Python/PHP/Perl版本在使代码不兼容的方式上可能有所不同,通常以无声的方式,即使你有不错的测试覆盖率也可能无法捕获.

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

   确保在做出决策时考虑运行生产和预生产实例的成本,而不是忘记复制整个环境的成本(包括第三方服务,如数据存储/添加,安装和配置SSL等) .

2. 如果使用AWS,请注意来自Bitnami等供应商的AWS预配置实例 - 它们是一个安全噩梦.它们可以默认暴露许多臭名昭着的易受攻击的应用程序而不在说明中提及它.

   请考虑使用支持良好的主流分发,例如Ubuntu或Debian(如果需要RPM支持,则使用CentOS).

   注意:亚马逊提供了自己的发行版,称为Amazon Linux,它使用RPM,但它是特定于EC2的,并且不太受第三方/开源软件的支持.

3. 您还可以在AWS(或Lightsail)上设置EC2实例,并在其上配置像flynn或dokku这样的东西 - 然后您可以轻松地在其上部署多个站点,如果您维护很多服务或想要成为可能的话,这是值得的.能够轻松地开发新东西.然而,设置它并不像只使用Heroku那样自动化,你最终可能会花费大量时间来配置和维护它(我发现使用Amazon集群和Docker Swarm进行部署要比设置它们更容易;因人而异).

我根据我正在进行的项目的需要,同时使用了AWS EC实例(单独和群集),Elastic Beanstalk和Lightsail以及Heroku.

我讨厌花时间配置服务,但是如果我将它用于所有事情而我的Heroku账单将是每年数千,而AWS只花费了一小部分成本.

TL;博士

如果钱从来不是问题,我会使用Heroku几乎所有东西,因为它是一个巨大的节省时间 - 但我仍然希望将AWS用于更复杂的项目,我需要灵活性和Heroku不提供的更高级服务.

对我来说理想的情况是,如果ElasticBeanstalk更像是Heroku - 即配置更简单,更快,更好的部署机制.

几乎就是这样的服务的一个例子是now.sh,它实际上在幕后使用AWS,但是使部署和集群像在Heroku上一样简单(具有自动SSL,DNS,优雅的部署,超级简单的集群设置和管理).

我对Node.js应用程序和Docker镜像部署都使用了很多,主要的警告是实例是共享的(反映在它们较低的成本中),目前没有购买专用实例的选项.但是,他们的"现在"开源部署工具也可用于部署到AWS以及Google Cloud和Azure上的专用实例.

Answer 8

我们将业务从Heroku迁移到AWS的业务占很大比例.这两者都有优势,但是在一段时间之后,它会在Heroku上变得混乱......一旦你需要一定程度的复杂性,Heroku的限制就不再容易维护.

也就是说,通过使用优秀的框架/工具在AWS上拥有Heroku的易用性和AWS的灵活性,有越来越多的选择.