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