挑战
这家成立三年的初创公司提供了一个网络应用程序，供教师在课堂上与学生互动。该 JavaScript 应用程序基于 Google 的网络应用程序开发平台 Firebase，使用 Heroku 构建。随着用户群的稳步增长，开发团队也随之壮大。“当我们开始想要拥有多个服务时，我们超出了 Heroku 的承受能力，并且部署过程变得非常糟糕。我们很沮丧，因为我们无法让开发人员快速地进行版本化，”首席执行官 Riley Eynon-Lynch 说。“跟踪和监控基本上变得不可能。”最重要的是，Pear Deck 的许多客户都位于政府防火墙后面，并且通过 Firebase 连接，而不是 Pear Deck 的服务器，这使得故障排除更加困难。
解决方案
2016 年，该公司开始将代码从 Heroku 迁移到运行在 Google Kubernetes Engine 上的容器，由 Kubernetes 进行编排，并使用 Prometheus 进行监控。
影响
新的云原生堆栈立即改善了开发工作流程，加快了部署速度。Prometheus 为 Pear Deck 带来了“很大的信心，因为它知道人们一直在登录应用程序并一直使用它，”Eynon-Lynch 说。“最大的影响是能够在 git 中以拉取请求的形式作为一个团队来协同配置，而最大的信心来自抽象的坚固性和我们对 Kubernetes 能够真正将我们的 yaml 文件变成现实的信任。”
作为一名前高中数学老师，首席执行官 Riley Eynon-Lynch 感到迫切需要为那些难以在短时间内与每个学生互动的课堂提供技术解决方案。“Pear Deck 是一个应用程序，学生可以使用它与老师同时互动，”他说。“当老师提问时，不是只有坐在教室前排的孩子再次回答，而是每个人都可以回答每一个问题。这对学生来说是一个巨大的根本性转变，它表明我们有多在乎他们，以及他们对课堂的参与度有多高。”
Eynon-Lynch 和他的合作伙伴在 Google 的网络应用程序开发平台 Firebase 上快速构建了一个 JavaScript 网络应用程序，并在 Heroku 上发布了最小可行产品 [MVP]， “因为它又快又简单，”他说。“我们尽力让一切变得尽可能简单。”
但发布后，用户群以每月 30% 的速度稳定增长。“我们的 Heroku 账单变得非常疯狂，”Eynon-Lynch 说。但更重要的是，随着公司聘用更多开发人员以跟上步伐，“我们超出了 Heroku 的承受能力。我们想要拥有多个服务，并且部署过程变得非常糟糕。我们很沮丧，因为我们无法让开发人员快速地进行版本化。跟踪和监控基本上变得不可能。”
最重要的是，Pear Deck 的许多客户都位于政府防火墙后面，并且通过 Firebase 连接，而不是 Pear Deck 的服务器，这使得故障排除更加困难。
团队开始寻找其他解决方案，最终决定在 2016 年初开始将应用程序从 Heroku 迁移到运行在 Google Kubernetes Engine 上的容器，由 Kubernetes 进行编排，并使用 Prometheus 进行监控。
他们曾考虑过其他选择，例如 Google 的 App Engine（他们已经将其用于一项服务）和 Amazon 的 Elastic Compute Cloud (EC2)，同时尝试在 Kubernetes 中运行一项不向互联网公开的小型服务。“当 Google Kubernetes Engine 明显将获得 Google 的大力支持并成为一个完全托管的 Kubernetes 平台时，我们觉得这似乎是最好的选择，”Eynon-Lynch 说。“我们并没有真正考虑 Terraform 和其他竞争对手，因为 Kubernetes 提供的抽象概念对我们来说太明显了。”
一旦团队开始将 Heroku 应用程序移植到 Kubernetes 中，这“非常简单，”他说，影响是立竿见影的。“之前，要创建应用程序的新版本意味着要转到 Heroku 并重新配置 10 个新服务，因此基本上没有人愿意这样做，我们也从来没有进行过版本化，”他说。“现在，我们可以在 30 秒内在许多不同的集群中部署我们完全相同的配置。我们拥有一个始终运行的完整设置，然后我们任何开发人员或设计师都可以使用一个命令来进行版本化，包括他们的最新更改。我们现在一直在进行版本化，每个人都停止谈论它的酷炫程度，因为它已经变得不再可见了，它的优越性已经显而易见。”
与 Kubernetes 一起出现的是 Prometheus。“直到最近，我们还没有任何关于聚合服务器指标或性能的可见性，”Eynon-Lynch 说。团队曾尝试使用 Google Kubernetes Engine 的 Stackdriver 监控，但遇到了问题，并考虑过使用 New Relic。当他们于 2016 年秋季开始关注 Prometheus 时，“Prometheus 中的抽象概念与我们对系统工作方式的思考方式之间的契合非常清晰明显，”他说。
与 Kubernetes 的集成使得设置变得非常容易。一旦 Helm 安装了 Prometheus，“我们立即开始获得所有 Kubernetes 节点和 Pod 健康状况的图表。我认为我们当时已经上瘾了，”Eynon-Lynch 说。“然后，我们在 15 分钟内就让自己的自定义检测正常运行，并且能够实时更新请求计数，并能够对这些计数进行评分，并了解在特定时间有多少用户连接。然后，在不到一个小时的时间里，我们让警报自动显示在 Slack 频道中。所有这一切都在一个下午完成。那是一个令人惊喜的下午，基本上！”
考虑到 Pear Deck 特有的挑战——流量通过 Firebase 以及政府防火墙——Prometheus 是一个改变游戏规则的工具。“我们甚至没有意识到我们对缺乏对应用程序发生的事情的洞察力的压力有多大，”Eynon-Lynch 说。之前，当客户报告应用程序无法正常运行时，团队必须手动调查问题，而不知道是否影响了世界各地的客户，或者 Firebase 是否宕机，以及在哪。
为了帮助解决这个问题，团队编写了一个脚本，从多个不同的地理位置 ping Firebase，然后将响应以直方图的形式报告给 Prometheus。“Prometheus 对我们最大的影响就是让我们松了一口气，感觉我们知道发生了什么，”他说。“它花了 45 分钟来实现 [Firebase 警报]，因为我们知道我们拥有这个可靠的指标平台 Prometheus。我们不需要再去想，'我们要把这些指标发送到哪里？如何聚合指标？如何理解它们？'”
此外，Prometheus 还允许 Pear Deck 为业务目标构建警报。其中一项指标衡量的是应用程序成功加载的速率，如果当天的加载量低于前七天加载量的 90%，则会触发警报。“我们在极其荒谬的防火墙后面运行一个 JavaScript 应用程序，各种疯狂的浏览器扩展会对它进行干扰——Chrome 会推出一个功能，导致我们使用的某些 CSS 出现故障，”Eynon-Lynch 说。“所以这给了我们很大的信心，我们至少知道人们一直在登录应用程序并一直使用它。”
现在，当客户抱怨时，如果没有任何警报触发，团队就可以自信地认为这不是一个普遍存在的问题。“为了确保，我们可以查看图表，并说，'是的，目前有 10,000 人连接到该 Firebase 节点。它肯定可以正常运行。让我们调查一下你的网络设置，客户，”他说。“我们可以将这个问题反馈给我们的支持代表，而不是让整个开发团队都担心 Firebase 宕机。”
Pear Deck 也在回馈社区，构建并开源了一个 指标聚合器，它允许在 Prometheus 中进行最终用户监控。“例如，我们可以衡量网络客户端上的交互式 DOM 的时间，”他说。“用户将这些信息报告给我们的聚合器，然后聚合器报告给 Prometheus。这样我们就可以为一些客户端错误设置警报。”
Pear Deck 的大多数服务现在已经迁移到 Kubernetes。并且团队的所有新代码都将在 Kubernetes 上运行。“Kubernetes 让我们可以同时对服务配置进行实验并在暂存集群中进行版本化，测试不同的场景并讨论它们，作为查看代码的开发团队，而不仅仅是讨论作为人类我们将最终采取的步骤，”Eynon-Lynch 说。
展望未来，团队计划探索 Kubernetes 上的自动缩放功能。用户遍布全球，但主要集中在美国，因此流量存在高峰和低谷。一项仍在 App Engine 上运行的服务在白天每秒可以收到 10,000 个请求，但在晚上却少得多。“我们晚上为相同的服务器付费，所以我知道我们可以利用自动缩放，”他说。“实施它是一个很大的问题，会让我们接触到其他 Kubernetes 集群，并且可能会造成混乱。但我们的最终目标是将所有东西都迁移过来，因为现在没有开发人员愿意再处理那个应用程序了，因为它部署起来太麻烦了。”
他们也渴望探索 Kubernetes 在有状态集方面所做的工作。“现在，我们在 Kubernetes 中运行的所有服务都是无状态的，Google 基本上为我们运行数据库并管理备份，”Eynon-Lynch 说。“但我们有兴趣构建自己的网络套接字解决方案，它不需要完全有状态，但可能会有一个小时的状态。”
该项目还将涉及 Prometheus，用于 WebSocket 连接的暗启动。"我们不知道这些糟糕的防火墙后面的 WebSocket 连接到我们服务器的可靠性如何，"他说。"我们不知道 Firebase 为了提高其可靠性做了哪些工作。因此，我非常期待尝试通过 WebSocket 与我们的客户端建立持久连接，并提供可选的工具来了解它是否有效。这是我们进入有状态服务器的下一个新冒险。"
关于 Prometheus，Eynon-Lynch 认为该公司才刚刚开始。"我们还没有对所有重要的功能进行监控，特别是那些依赖于第三方服务的，"他说。"我们必须等待这些第三方告诉我们它们宕机了，而有时它们很长时间都不会通知我们。因此，由于 Prometheus 和 Kubernetes，我对应用程序实际用户体验的实际状态越来越兴奋，并且越来越有信心，而不仅仅是 CPU 图表所说的那样。"
对于一家正在快速增长的敏捷创业公司来说——是的，他们正在 招聘！——Pear Deck 对其基础设施在云原生生态系统中的发展感到非常满意。"通常我会有一些焦虑，想要使用最新、更好的技术，"Eynon-Lynch 说，"但就云而言，Kubernetes 和 Prometheus 提供了太多东西。"