挑战
这家成立三年的初创公司为教师提供一个网络应用程序，让他们在课堂上与学生互动。这个 JavaScript 应用程序是基于谷歌的网络应用程序开发平台 Firebase 构建的，并使用了 Heroku。随着用户群的稳步增长，开发团队也在壮大。“当我们开始需要多个服务时，我们就超过了 Heroku 的能力，而且部署过程变得非常糟糕。我们感到沮丧的是，开发人员无法快速部署一个版本，”首席执行官 Riley Eynon-Lynch 说。“追踪和监控基本上变得不可能。”最重要的是，Pear Deck 的许多客户都位于政府防火墙之后，并通过 Firebase 连接，而不是 Pear Deck 的服务器，这使得故障排除更加困难。
解决方案
2016 年，该公司开始将其代码从 Heroku 迁移到在 Google Kubernetes Engine 上运行的容器中，由 Kubernetes 编排，并使用 Prometheus 进行监控。
影响
新的云原生堆栈立即改进了开发工作流程，加快了部署速度。Prometheus 让 Pear Deck “非常自信，知道人们一直在登录并使用该应用程序，”Eynon-Lynch 说。“最大的影响是能够作为一个团队在 git 中通过 pull request 处理配置，最大的信心来自于抽象的稳固性以及我们对 Kubernetes 实际上将我们的 yaml 文件变成现实的信任。”
作为一名前高中数学教师，首席执行官 Riley Eynon-Lynch 感到迫切需要为那些在短时间内难以与每位学生互动的课堂提供技术解决方案。“Pear Deck 是一款学生可以用来与老师同时互动的应用程序，”他说。“当老师提出问题时，不再只是教室前面的孩子回答，而是每个人都可以回答每个问题。这在向学生传达我们对他们的关心以及他们对课堂的参与程度方面是一个巨大的根本性转变。”
Eynon-Lynch 和他的合作伙伴在谷歌的网络应用程序开发平台 Firebase 上快速构建了一个 JavaScript 网络应用程序，并在 Heroku 上推出了最小可行产品 [MVP]，“因为它快速且易于使用，”他说。“我们尽可能地简化了一切。”
但是一旦发布，用户群就开始以每月 30% 的速度稳步增长。“我们在 Heroku 上的账单变得完全疯狂，”Eynon-Lynch 说。但更重要的是，随着公司聘请更多的开发人员来跟上步伐，“我们超过了 Heroku 的能力。我们想要拥有多个服务，而且部署过程变得非常糟糕。我们感到沮丧的是，开发人员无法快速部署一个版本。追踪和监控基本上变得不可能。”
最重要的是，Pear Deck 的许多客户都位于政府防火墙之后，并通过 Firebase 连接，而不是 Pear Deck 的服务器，这使得故障排除更加困难。
该团队开始寻找其他解决方案，最终在 2016 年初决定开始将应用程序从 Heroku 迁移到在 Google Kubernetes Engine 上运行的容器中，由 Kubernetes 编排，并使用 Prometheus 进行监控。
他们考虑过其他选项，例如谷歌的 App Engine（他们已经将其用于一项服务）和亚马逊的 弹性计算云 (EC2)，同时尝试在 Kubernetes 中运行一个无法访问互联网的小型服务。“当清楚地看到 Google Kubernetes Engine 将获得谷歌的大力支持，并将成为一个完全托管的 Kubernetes 平台时，我们认为这显然是正确的选择，”Eynon-Lynch 说。“我们没有真正考虑 Terraform 和其他竞争对手，因为 Kubernetes 提供的抽象概念对我们来说非常有吸引力。”
一旦团队开始将 Heroku 应用程序移植到 Kubernetes 中，这“超级容易”，他说，影响是立竿见影的。“以前，制作应用程序的新版本意味着要转到 Heroku 并重新配置 10 个新服务，所以基本上没有人愿意这样做，而且我们从不部署任何东西，”他说。“现在我们可以在 30 秒内在许多不同的集群中部署完全相同的配置。我们有一个始终运行的完整设置，然后我们的任何开发人员或设计师都可以通过一个命令来部署新版本，包括他们最近的更改。我们现在一直在部署，每个人都不再谈论它有多酷了，因为它已经变得不那么引人注目了。”
Prometheus 与 Kubernetes 一起出现。“直到最近，我们还没有任何类型的可见性来了解汇总的服务器指标或性能，”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 对我们产生的一个巨大影响是，我们感到如释重负，感觉我们知道发生了什么，”他说。“[Firebase 警报] 的实施花了 45 分钟，因为我们知道我们在 Prometheus 中有一个值得信赖的指标平台。我们不必去弄清楚，“我们将这些指标发送到哪里？我们如何聚合这些指标？我们如何理解它们？”
此外，Prometheus 还允许 Pear Deck 为业务目标构建警报。一个测量应用程序成功加载的速率，如果当天的加载次数少于七天前的 90%，则会触发警报。“我们运行一个 JavaScript 应用程序，该应用程序位于令人难以置信的防火墙之后，并且有各种疯狂的浏览器扩展程序在搞破坏，Chrome 会推送一个破坏我们正在使用的某些 CSS 的功能，”Eynon-Lynch 说。“因此，这给了我们很大的信心，并且我们至少知道人们仍然在登录并一直使用该应用程序。”
现在，当客户抱怨时，如果没有触发任何警报，该团队可以确信这不是一个普遍存在的问题。“为了确保这一点，我们可以去仔细检查图表，然后说，“是的，目前有 10,000 人连接到该 Firebase 节点。它绝对在工作。让我们调查一下您的网络设置，客户，”他说。“我们可以将其转交给我们的支持代表，而不是让整个开发团队都担心 Firebase 宕机了。”
Pear Deck 也在回馈社区，构建并开源了一个 指标聚合器，该聚合器支持在 Prometheus 中进行最终用户监控。“例如，我们可以测量 Web 客户端上的交互式 DOM 的时间，”他说。“用户都将此报告给我们的聚合器，然后聚合器将此报告给 Prometheus。因此，我们可以为某些客户端错误设置警报。”
Pear Deck 的大多数服务现在都已迁移到 Kubernetes 上。并且团队的所有新代码都将在 Kubernetes 上运行。“Kubernetes 允许我们试验服务配置，并在一个临时集群上同时部署它们，并测试不同的场景，并以开发团队查看代码的方式进行讨论，而不仅仅是讨论我们最终将作为人类采取的步骤，”Eynon-Lynch 说。
展望未来，团队计划探索 Kubernetes 上的自动扩缩容。 用户的分布遍布全球，但主要集中在美国，因此流量会出现高峰和低谷。 有一个仍在 App Engine 上运行的服务，白天每秒可能会收到多达 10,000 个请求，而晚上则少得多。“我们晚上也为同样的服务器付费，所以我知道我们可以利用自动扩缩容，”他说。“实现自动扩缩容是一个很大的顾虑，这会将我们 Kubernetes 集群的其他部分暴露出来，并可能搞砸。但将所有内容都迁移过来是我们的既定目标，因为现在没有任何开发人员愿意再在这个应用程序上工作，因为它部署起来太痛苦了。”
他们也很渴望探索 Kubernetes 在有状态集合方面的工作。“目前，我们在 Kubernetes 中运行的所有服务都是无状态的，Google 基本上为我们运行数据库并管理备份，” Eynon-Lynch 说。“但我们有兴趣构建自己的 Web 套接字解决方案，该解决方案不必是完全有状态的，但可能会保留一个小时左右的状态。”
该项目还将涉及 Prometheus，用于暗启动 Web 套接字连接。“我们不知道在所有这些糟糕的防火墙后面，Web 套接字连接到我们服务器的可靠性如何，”他说。“我们不知道 Firebase 在提高其可靠性方面做了哪些工作。因此，我真的很期待尝试与客户端建立持久的 Web 套接字连接，并拥有可选的工具来了解它是否在工作。这是我们下一个新的冒险，进入有状态服务器领域。”
至于 Prometheus，Eynon-Lynch 认为公司才刚刚开始。“我们还没有对所有重要功能进行监控，特别是那些依赖于第三方的功能，”他说。“我们必须等待这些第三方告诉我们他们宕机了，有时他们会很长时间不这样做。因此，我真的很兴奋，并且对我们实际用户的应用程序的实际状态越来越有信心，而不仅仅是 CPU 图表所显示的，这要归功于 Prometheus 和 Kubernetes。”
对于一家仍在快速增长的充满活力的初创公司——是的，他们正在招聘！——Pear Deck 对其基础设施在云原生生态系统中的演变感到非常满意。“通常我会有一些焦虑的事情，比如我想使用新的、更好的技术，”Eynon-Lynch 说，“但在云方面，Kubernetes 和 Prometheus 可以提供很多东西。”