您的位置:首页 > 其它

Heroku与AWS Elastic Beanstalk

2020-08-21 16:02 357 查看

We deploy a web application to Heroku and to AWS Elastic Beanstalk in production configurations; contrasting their implementations and pricing.

我们在生产配置中将Web应用程序部署到Heroku和AWS Elastic Beanstalk。 对比其实施和定价。

note: This is not to say that AWS Elastic Beanstalk is the only comparable way to run workloads in AWS; it, however, is the one that most closely resembles Heroku.

注意 :这并不是说AWS Elastic Beanstalk是在AWS中运行工作负载的唯一可比方法; 但是,它与Heroku最相似。

TL;DR: The 30-thousand-foot comparison of these, Heroku and AWS Elastic Beanstalk, solutions (production configurations) is that they have comparable features and pricing. One big difference is that Heroku’s pricing takes exponential price jumps as one adds common additional features, e.g., auto-scaling, where-as AWS pricing is fairly linear. On the other hand, Heroku is generally simpler to get up and running as AWS has a fairly steep initial learning curve.

TL; DR :Heroku和AWS Elastic Beanstalk的解决方案(生产配置)在3万英尺处的比较是它们具有可比的功能和价格。 一个很大的不同是,Heroku的价格上涨了指数级,因为它增加了一些常见的附加功能,例如自动缩放,而AWS的价格则是线性的。 另一方面,由于AWS具有相当陡峭的初始学习曲线,因此Heroku通常更易于启动和运行。

The Application

应用程序

The web application is a minimal Node.js application that depends on a PostgreSQL database. Using two environment variables:

Web应用程序是一个最小的Node.js应用程序,它依赖于PostgreSQL数据库。 使用两个环境变量:

  • DATABASE_URL: PostgreSQL Connection URL

    DATABASE_URL :PostgreSQL连接URL

  • PORT: HTTP listener port

    PORT :HTTP侦听器端口

and exposing two endpoints:

并公开两个端点:

  • /: responds with Hello World!

    / :用Hello World回应!

  • /db: Executes a PostgreSQL query and responds with result; Hello db!

    / db :执行PostgreSQL查询并返回结果; 你好分贝!

Heroku Application

Heroku应用

Following the instructions, Preparing a Codebase for Heroku Deployment and Deploying Node.js Apps on Heroku, we start by adding the engines property to package.json; specifying the Node.js version to use:

按照说明为Heroku部署准备代码库 以及 在Heroku上部署Node.js应用程序的说明 ,我们首先将engines属性添加到package.json ; 指定要使用的Node.js版本:

We also create a file, Procfile, to specify how to start the Dynos:

我们还创建一个文件Procfile ,以指定如何启动Dynos:

Finally, we push the application to a Heroku App configured with a Heroku Postgres resource.

最后,我们将应用程序推送到配置了Heroku Postgres资源的Heroku App。

The Heroku components and pricing is:

Heroku组件和定价为:

  • Heroku Standard Support (business hours, 1 day response): No Cost

    Heroku标准支持(营业时间,1天响应):无需付费
  • 2 x Professional Standard 1X Dynos (512 MB memory): $25 / Dyno / month

    2 x Professional Standard 1X Dynos(512 MB内存):$ 25 / Dyno /月
  • Premium-0 Heroku Postgres (4 GB memory, 64 GB storage): $200 / month

    Premium-0 Heroku Postgres(4 GB内存,64 GB存储):每月200美元

Thus the total monthly cost is $250.

因此,每月总费用为250美元。

A network diagram illustrating the components and a representative communication flow:

网络图说明了组件和代表性的通信流程:

note: Blue components are associated with the Heroku App. Dashed components in the diagram are those that are managed by Heroku behind the scene.

注意 :蓝色组件与Heroku应用程序关联。 图中的虚线组件是由Heroku在后台管理的组件。

  1. Browser (Br.) makes request to the Load Balancer (LB) in an Availability Zone (AZ). Availability Zones are isolated logical data centers

    浏览器( Br。 )向可用区( AZ )中的负载均衡器( LB )请求。 可用区是隔离的逻辑数据中心

  2. Load Balancer (LB) routes the request to one of the Dynos managed by a horizontal scaling group (H. Scaling). Dynos are randomly distributed across Availability Zones

    负载平衡器( LB )将请求路由到由水平缩放组( H. Scaling)管理的Dyno之一。 测功机随机分布在可用区中

  3. Dyno executes a query against a database on the PostgreSQL primary instance (PG P.). The PostgreSQL cluster (PG) has a standby instance (PG S.) in a different Availability Zone

    Dyno对PostgreSQL主实例( PG P. )上的数据库执行查询。 PostgreSQL集群( PG )在不同的可用区中有一个备用实例( PG S. )

Observations:

观察结果:

  • Heroku automatically manages, e.g, performs upgrades for, the Dynos and Heroku Postgres resources

    Heroku自动管理Dynos和Heroku Postgres资源,例如对其进行升级
  • Heroku automatically manages the DATABASE_URL and PORT environment variables

    Heroku自动管理DATABASE_URL和PORT环境变量

  • Professional level Dynos are required to enable horizontal scaling and thus high availability (or something approximating it)

    需要专业水平的Dynos来实现水平扩展,从而实现高可用性(或近似水平的扩展)

The Heroku Platform is spread across multiple AWS availability zones and application dynos are provisioned automatically so there is no guarantee that your dynos will be evenly balanced across availability zones (it is effectively random allocation).

Heroku平台分布在多个AWS可用区中,并且自动配置了应用程序测功机,因此无法保证您的测功机将在各个可用区之间平均平衡(实际上是随机分配)。

Basically, the dynos themselves can bounce between AZ’s but if an AZ becomes unavailable, the affected dynos would be started another AZ.

基本上,测功器本身可以在AZ之间反弹,但是如果AZ不可用,则受影响的测功将从另一个AZ开始。

— Heroku — How do multi-availability zones work on Heroku?

— Heroku — Heroku上的 多可用性区域如何工作?

  • Premium level Heroku Postgres is required for high availability

    高级级别需要Heroku Postgres

For premium tier database plans, the failover database is in a separate availability zone automatically.

对于高级层数据库计划,故障转移数据库自动位于单独的可用性区域中。

— Heroku — How do multi-availability zones work on Heroku?

— Heroku — Heroku上的 多可用性区域如何工作?

  • The final and important observation is that the PostgreSQL instances are publicly available; secured using SSL and an username / password pair

    最终的重要发现是PostgreSQL实例是公开可用的。 使用SSL和用户名/密码对进行安全保护

note: The application adapted to Heroku is available in the heroku branch of the larkintuckerllc / heroku-aws GitHub repository.

注意 :适用于Heroku的应用程序可在larkintuckerllc / heroku-aws GitHub存储库的heroku分支中找到。

AWS Elastic Beanstalk Application: Create Application

AWS Elastic Beanstalk应用程序:创建应用程序

Because we are deploying a production configuration, we first need to follow the instructions in Using Elastic Beanstalk with Amazon VPC to create a Public / Private VPC. Because the instructions provide an AWS CloudFormation template, this is close to a one-click experience.

因为我们正在部署生产配置,所以我们首先需要遵循将Elastic Beanstalk与Amazon VPC一起使用来创建公共/私有VPC。 由于说明提供了一个AWS CloudFormation模板,因此这接近于一键式体验。

Next we need to create the PostgreSQL database using AWS Relational Database Service (RDS). We start by creating a RDS Subnet Group consisting of the two private Subnets created in the previous step. We create the Database using the following (non-default) parameters:

接下来,我们需要使用AWS Relational Database Service(RDS)创建PostgreSQL数据库。 我们首先创建一个RDS子网组,该组由上一步中创建的两个专用子网组成。 我们使用以下(非默认)参数创建数据库:

  • Standard Create

    标准创建
  • Amazon Aurora

    亚马逊极光
  • Amazon Aurora with PostgreSQL compatibility

    具有PostgreSQL兼容性的Amazon Aurora
  • Templates: Production

    模板:生产
  • DB instance size: db.t3.medium

    数据库实例大小:db.t3.medium
  • VPC: The VPC from the first step

    VPC:第一步的VPC
  • Subnet group: The Subnet Group from the previous step

    子网组:上一步中的子网组
  • VPC security group: Create new

    VPC安全组:新建

Next we create the AWS Elastic Beanstalk Application using the following (non-default) parameters:

接下来,我们使用以下(非默认)参数创建AWS Elastic Beanstalk应用程序:

  • Platform: Node.js

    平台:Node.js
  • Application code: Leave the Sample application for now

    应用程序代码:现在保留示例应用程序
  • Capacity > Environment type: Load Balanced (Min and Max: 2)

    容量>环境类型:负载均衡(最小和最大:2)
  • Network > VPC: The VPC from the first step

    网络> VPC:第一步中的VPC
  • Network > Load Balancer subnets: The two public Subnets from the first step

    网络>负载均衡器子网:第一步中的两个公共子网
  • Network > Instance subnets: The two private Subnets from the first step

    网络>实例子网:第一步中的两个专用子网

Before deploying our code, let us first review the AWS components and pricing:

在部署代码之前,让我们首先回顾一下AWS组件和定价:

  • AWS Developer Support Plan (business hours, 1 day response): $29 / month

    AWS开发人员支持计划(营业时间,1天响应):29美元/月
  • VPC with its Subnets, Security Groups, Internet Gateway: No Cost

    VPC及其子网,安全组,Internet网关:免费
  • VPC NAT Gateway: $0.045 / hour + Data (~$30 / month)

    VPC NAT网关:$ 0.045 /小时+数据(〜$ 30 /月)
  • Aurora Database Instances: 2 x db.t3.medum (4 GB memory): $0.082 / hour (~60 / month)

    Aurora数据库实例:2 x db.t3.medum(4 GB内存):$ 0.082 /小时(〜60 /月)
  • Aurora Database Storage and IOs: $0.10 / GB / month + IO (~$6 / month)

    Aurora数据库存储和IO:$ 0.10 / GB /月+ IO(〜$ 6 /月)
  • Load Balancer: Application Load Balancer: $0.0225 / hour + Data (~$17 / month)

    负载均衡器:应用程序负载均衡器:每小时$ 0.0225 +数据(每月约$ 17)
  • EC2 Auto Scaling Group (ASG): No Cost

    EC2 Auto Scaling Group(ASG):无费用
  • EC2: 2 x t2-micro (1 CPU, 1 GB memory): $0.0116 / hour (~$9 / month)

    EC2:2 x t2-micro(1 CPU,1 GB内存):$ 0.0116 /小时(〜$ 9 /月)
  • EC2 Storage: 2 x EBS gp2 8 GB: $0.10 / GB / month (~$1 / month)

    EC2存储:2 x EBS gp2 8 GB:$ 0.10 / GB /月(〜$ 1 /月)

note: Generally the Data and IO charges are minimal under most circumstances.

注意 :通常,在大多数情况下,数据和IO费用很少。

Thus the total monthly cost is approximately $214.

因此,每月总费用约为214美元。

A network diagram illustrating the components and a representative communication flow:

网络图说明了组件和代表性的通信流程:

note: Orange components are associated with the Aurora Database. Blue components are associated with the Elastic Beanstalk Application. Dashed components in the diagram are those that are managed by AWS behind the scene.

注意 :橙色组件与Aurora数据库关联。 蓝色组件与Elastic Beanstalk应用程序关联。 图中的虚线组件是由AWS在后台管理的组件。

  1. Browser (Br.) makes a request to the Load Balancer (LB) in a public Subnet (SN)

    浏览器( Br。 )向公共子网( SN )中的负载均衡器( LB )发出请求

  2. Load Balancer (LB) routes the request to one of the EC2 Instances (EC2) in a private Subnet (SN) managed by an Auto Scaling Group (ASG). EC2 Instances are evenly distributed across Availability Zones (in their respective private Subnets)

    负载均衡器( LB )将请求路由到由Auto Scaling组( ASG)管理的专用子网( SN )中的EC2实例( EC2 )之一。 EC2 实例均匀分布在可用区中(在其各自的专用子网中)

  3. EC2 Instance executes a query against a database on the PostgreSQL Writer Instance (PG W.) in a private Subnet (SN). There is also a PostgreSQL Reader Instance (PG R.) in a private Subnet in a different Availability Zone

    EC2实例对私有子网( SN )中PostgreSQL编写器实例( PG W. )上的数据库执行查询。 在不同可用区中的专用子网中还有一个PostgreSQL阅读器实例( PG R. )

Observations:

观察结果:

  • AWS automatically manages, e.g, performs upgrades for, the PostgreSQL and EC2 Instances

    AWS自动管理PostgreSQL和EC2实例,例如对其执行升级
  • AWS Elastic Beanstalk automatically manages the PORT environment variable

    AWS Elastic Beanstalk自动管理PORT环境变量

  • The final and important observation is that the EC2 and PostgreSQL Instances are in private Subnets and further secured using Security Groups. The PostgreSQL Instances are also secured using SSL and a username / password pair

    最终的重要发现是EC2和PostgreSQL实例位于专用子网中,并使用安全组进一步保护了它们的安全。 PostgreSQL实例也使用SSL和用户名/密码对进行保护。

AWS Elastic Beanstalk Application: Deployment

AWS Elastic Beanstalk应用程序:部署

We roughly follow the instruction, Launching and connecting to an external Amazon RDS instance in a default VPC, and first update the RDS Instances’ Security Group to allow inbound PostgreSQL traffic from itself.

我们大致遵循以下说明: 在默认VPC中启动并连接到外部Amazon RDS实例 ,然后首先更新RDS实例的安全组,以允许来自其本身的入站PostgreSQL通信。

We then add the RDS Instances’ Security Group to the Elastic Beanstalk’s EC2 Instance configuration.

然后,我们将RDS实例的安全组添加到Elastic Beanstalk的EC2实例配置中。

The last step in the instructions is to add database connection information to the Elastic Beanstalk’s software configuration environment variables. For our application, we will need to add a DATABASE_URL environment variable with the PostgreSQL Connection URL, e.g,:

说明中的最后一步是将数据库连接信息添加到Elastic Beanstalk的软件配置环境变量中。 对于我们的应用程序,我们将需要在PostgreSQL连接URL中添加DATABASE_URL环境变量,例如:

postgres://USERNAME:PASSWORD@INSTANCE/DATABASE

Parameters:

参数:

  • USERNAME: The username provided when creating database

    USERNAME :创建数据库时提供的用户名

  • PASSWORD: The password provided when creating database

    密码 :创建数据库时提供的密码

  • INSTANCE: The Database Writer endpoint

    实例 :数据库编写器端点

  • DATABASE: The same as USERNAME

    数据库 :与USERNAME相同

Roughly following the instructions, Deploying Node.js applications to Elastic Beanstalk, we add a start script to package.json.

大致按照将Node.js应用程序部署到Elastic Beanstalk中的说明进行操作,我们将开始脚本添加到package.json中

note: It is important to observe, that we do not do the Heroku steps here; i.e., engines in package.json and creating Procfile.

注意 :请务必注意,我们此处不执行Heroku步骤; 即,在package.json中的 引擎并创建Procfile 。

We then zip the application files, excluding the GIT and Node.js modules files, with:

然后,我们使用以下命令压缩应用程序文件(不包括GIT和Node.js模块文件):

zip -r application.zip . -x *.git* node_modules/\*

Finally, we upload it to the Elastic Beanstalk application (technically its single Environment).

最后,我们将其上传到Elastic Beanstalk应用程序(从技术上讲是其单个环境)。

note: The application adapted to AWS Elastic Beanstalk is available in the aws branch of the larkintuckerllc / heroku-aws GitHub repository.

注意 :适用于AWS Elastic Beanstalk的应用程序可在larkintuckerllc / heroku-aws GitHub存储库的aws分支中找到。

Contrasting Solutions

对比解决方案

The first observation is that these solutions are roughly comparable with the same cost; $250 (Heroku) v.s. $214 (AWS Elastic Beanstalk) per month.

第一个观察结果是,这些解决方案在成本相同的情况下大致可比。 每月$ 250(Heroku)与$ 214(AWS Elastic Beanstalk)。

The next observation is that the AWS Elastic Beanstalk solution’s PostgreSQL Instances, being in private Subnets with restricted Security Groups, are more secure than the publicly available PostgreSQL Instances in the Heroku solution.

下一个观察结果是,在具有受限安全组的私有子网中,AWS Elastic Beanstalk解决方案的PostgreSQL实例比Heroku解决方案中的公共可用PostgreSQL实例更安全。

Heroku’s Private Spaces feature can be used to address this issue; the problem though is that this feature is only available with custom pricing (assuming going to be expensive).

Heroku的Private Spaces功能可用于解决此问题。 但问题在于,此功能仅适用于自定义定价(假设价格昂贵)。

Another observation is that Heroku’s Dyno high availability, by randomly distributing across Availability Zones, is less robust than the AWS Elastic Beanstalk’s (actually powered by an EC2 Auto Scaling Group) active distribution across Availability Zones.

另一个观察结果是,通过在可用区之间随机分布,Heroku的Dyno高可用性不如AWS Elastic Beanstalk(实际上由EC2 Auto Scaling Group提供支持)在可用区之间进行主动分布强大。

While we did not explore AWS Elastic Beanstalk’s Auto Scaling Group feature, it is available at no cost. For Heroku, however:

虽然我们没有探索AWS Elastic Beanstalk的Auto Scaling Group功能,但它是免费提供的。 但是,对于Heroku:

Autoscaling is currently available only for Performance-tier dynos and dynos running in Private Spaces.

当前,自动缩放仅适用于性能层测功和在专用空间中运行的测功。

— Heroku — Scaling Your Dyno Formation

— Heroku — 扩大您的Dyno阵型

The price of a Performance-tier Dyno is $250 / Dyno / month and as we saw earlier Private Spaces is only available with custom pricing. This is exponentially more than the $9 / Instance / month for AWS Elastic Beanstalk.

高性能层级Dyno的价格为$ 250 / Dyno /月,正如我们之前看到的,Private Spaces仅可按自定义价格提供。 这比AWS Elastic Beanstalk每月每个实例9美元的费用成倍增加。

With Heroku’s simple pricing model one often has to over-provision features for a particular result.

使用Heroku的简单定价模型,通常必须为特定结果过度配置功能。

For example, we used Premium-0 Heroku Postgres (4 GB memory, 64 GB storage) in the Heroku solution for $200 / month. In order to get more storage, we have to jump to Premium-2 Heroku Postgres (8 GB memory, 256 GB) for $350 / month (an extra $150 / month). Because AWS decouples the Aurora Database Instance from the Storage, we can scale them independently; at $0.10 / GB / month, getting to 256 GB (from 64 GB) only costs an additional $19 / month.

例如,我们在Heroku解决方案中使用Premium-0 Heroku Postgres(4 GB内存,64 GB存储),每月费用为200美元。 为了获得更多存储空间,我们必须跳至Premium-2 Heroku Postgres(8 GB内存,256 GB),月费为$ 350(额外的月费为$ 150)。 由于AWS将Aurora数据库实例与存储分离,因此我们可以独立扩展它们。 每月每GB $ 0.10,从64 GB升级到256 GB仅需每月额外支付$ 19。

The last, obvious, observation is that working with Heroku is generally simpler to get up and running with as compared to AWS. At the same time, once one already tackled the fairly steep initial AWS learning curve, incremental learning AWS features is relatively easy (features build off the same core functionality).

最后一个明显的观察结果是,与AWS相比,使用Heroku通常更容易启动和运行。 同时,一旦解决了相当陡峭的初始AWS学习曲线,增量学习AWS功能就相对容易了(功能建立在相同的核心功能之上)。

Wrap Up

结语

The 30-thousand-foot comparison of these, Heroku and AWS Elastic Beanstalk, solutions (production configurations) is that they have comparable features and pricing. One big difference is that Heroku’s pricing takes exponential price jumps as one adds common additional features, e.g., auto-scaling, where-as AWS pricing is fairly linear. On the other hand, Heroku is generally simpler to get up and running as AWS has a fairly steep initial learning curve.

这些解决方案(生产配置),Heroku和AWS Elastic Beanstalk的3万英尺的比较是,它们具有可比的功能和价格。 一个很大的不同是,Heroku的价格上涨了指数级,因为它增加了一些常见的附加功能,例如自动缩放,而AWS的价格则是线性的。 另一方面,由于AWS具有相当陡峭的初始学习曲线,因此Heroku通常更易于启动和运行。

翻译自: https://codeburst.io/heroku-v-s-aws-elastic-beanstalk-1cc6f12ca3c7

内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: