为什么 DEV 托管在 Heroku 上（以及我们如何配置我们的服务）

披露：Heroku 是 DEV 赞助商，但这篇文章本身并不是“赞助”的。

我选择写这篇文章，是因为我想谈谈我们在 DEV 是如何看待这些事情的。我经常收到这类问题，我的答案通常是“视情况而定”。话虽如此，我已经是 Heroku 的忠实用户近十年了，所以肯定有什么因素让我（以及 DEV）能够继续使用。

有很多很棒的云选择，包括我们的另一个赞助商：DigitalOcean。对于开发者来说，托管/云环境越来越好，但这并不是一个公平的讨论。它们不是商品，而是具体的服务，具有不同的服务、不同的用户体验关注点，以及许多权衡取舍。

我们绝不会只使用 Heroku ，但由于该平台提供的开发人员经验，我们一直在一些核心工作中使用它。

首先，Heroku 到底是做什么的？

Heroku 自称是“平台即服务”，本质上意味着它比其他云服务集成度更高。我一直不太确定该如何准确描述这些内容；但原则上，Heroku 捆绑了运行时环境、插件生态系统以及对集成开发者体验的总体关注。

最大的好处是什么？

总而言之，我们使用 Heroku 多年，是因为它帮我们节省了时间，而且真的不需要学习。也就是说，Heroku 的入门流程基本上可以直观地逐步完成，而不必为了使用该服务而去学习。他们通过出色的指南，几乎概述了我们需要的每一条路径。

Heroku CLI 和 Web 界面均提供了与服务交互的有效方式。我发现不同的团队成员在这方面会做出不同的选择，而不会导致团队内部沟通不畅。

以不同的方式与 Heroku 进行交互（例如与附加组件生态系统）通常是通过命令行完成的，如下所示：

heroku addons:create rediscloud:100

但如果我想直接进入 Web 界面，我通常觉得挺顺手的，而且可以在两个环境之间切换。我们团队里有些人甚至会直接在浏览器中使用我们应用的控制台……如果这符合他们的工作流程的话。

与英雄互动

无锁定集成

我们坚持使用 Heroku 的最大原因或许在于，我们从未发现自己被 Heroku 的生态系统牢牢束缚。我们需要构建的组件的第一个版本几乎总是在 Heroku 的附加组件生态系统中可用，但当我们出于任何原因需要切换时，总是可以轻松地移除这些附加组件，因为集成几乎总是可以通过应用配置进行定义，从而实现服务间的交换。

我们的 Heroku 配置

我们在一台Performance L Dyno上运行，并配置了自动缩放功能，以便在流量出现任何下降时并行到 2+ 台。我们使用 Puma 对应用程序进行分叉，以便在一台 Heroku 机器（即一台 Dyno）上运行并发实例。早期我们使用 Standard 2x Dyno，直到最终在一台大型 Dyno 上运行时，效率更高。

我们的核心数据库由 Heroku 管理，Postgres 也是其中之一，而我们的其他服务大多并非 Heroku 产品，但通常仍通过 Heroku 提供的附加组件系统进行管理。然而，当附加组件系统能够以最简便的方式访问仪表板等满足我们的需求时，我们也可以将其移除。附加组件系统是一个很好的默认设置，但同样重要的是，我们可以在必要时调整使用方法。

为了进一步阅读，这里有一篇对 Heroku 服务进行深入介绍的文章...

Heroku 与自托管 PaaS

马格努斯·斯科格・19年7月18日

#heroku #托管 #自托管

编码愉快！