挑战
这家成立三年的初创公司为教师提供了一个网络应用程序，以便在课堂上与学生互动。这个 JavaScript 应用程序构建在 Google 的网络应用程序开发平台 Firebase 上，并使用 Heroku。随着用户群的稳步增长，开发团队也在不断壮大。首席执行官 Riley Eynon-Lynch 表示：“当我们开始想要拥有多个服务时，我们已经超出了 Heroku 的能力范围，部署过程变得非常糟糕。我们感到沮丧的是，我们无法让开发人员快速搭建一个版本。跟踪和监控基本上是不可能的。”最重要的是，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 网络应用程序，并在 Heroku 上推出了最小可行产品 [MVP]，他说：“因为这既快速又简单。我们尽可能地简化了一切。”
但一旦推出，用户群就开始以每月 30% 的速度稳步增长。Eynon-Lynch 说：“我们的 Heroku 账单变得非常离谱。”但更重要的是，随着公司雇佣更多开发人员来跟上步伐，“我们已经超出了 Heroku 的能力范围。我们想要拥有多个服务，部署过程变得非常糟糕。我们感到沮丧的是，我们无法让开发人员快速搭建一个版本。跟踪和监控基本上是不可能的。”
最重要的是，Pear Deck 的许多客户都在政府防火墙之后，并通过 Firebase 而不是 Pear Deck 的服务器进行连接，这使得故障排除变得更加困难。
该团队开始寻找其他解决方案，并最终在 2016 年初决定开始将应用程序从 Heroku 迁移到 Google Kubernetes Engine 上运行的容器中，由 Kubernetes 进行编排，并使用 Prometheus 进行监控。
他们曾考虑过其他选择，比如 Google 的 App Engine（他们已经在为一项服务使用它）和 Amazon 的 弹性计算云 (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 为业务目标构建警报。其中一个指标衡量应用程序成功加载的速率，如果当天的加载量低于 7 天前的 90%，就会发出警报。Eynon-Lynch 说：“我们运行着一个 JavaScript 应用程序，它位于荒谬的防火墙后面，各种疯狂的浏览器扩展程序都在干扰它——Chrome 会推送一个功能，破坏我们正在使用的一些 CSS。所以这给了我们很大的信心，我们至少知道人们一直在登录应用程序并使用它。”
现在，当客户抱怨，并且没有任何警报发出时，团队可以确信这不是一个普遍的问题。他说：“为了确保万无一失，我们可以去仔细检查图表，然后说，‘是的，目前有 10,000 人连接到那个 Firebase 节点。它肯定在工作。让我们来调查一下你的网络设置，客户。’我们可以把这个问题交给我们的支持代表，而不是让整个开发团队都担心 Firebase 宕机了。”
Pear Deck 也在回馈社区，构建并开源了一个 指标聚合器，该聚合器支持在 Prometheus 中进行最终用户监控。他说：“例如，我们可以测量网络客户端上交互式 DOM 的时间。所有用户都将数据报告给我们的聚合器，然后聚合器再报告给 Prometheus。所以我们可以为一些客户端错误设置警报。”
Pear Deck 的大部分服务现在已经迁移到了 Kubernetes 上。该团队的所有新代码都将在 Kubernetes 上运行。Eynon-Lynch 说：“Kubernetes 让我们可以尝试服务配置，并将它们一次性地部署到一个暂存集群中，测试不同的场景，并以开发团队查看代码的方式进行讨论，而不仅仅是讨论我们最终将作为人类采取的步骤。”
展望未来，该团队计划探索 Kubernetes 上的自动扩展功能。他们的用户遍布全球，但主要集中在美国，因此流量存在峰谷。一项仍在 App Engine 上运行的服务在白天每秒可以收到多达 10,000 个请求，但在夜间则要少得多。他说：“我们在夜间也要为相同的服务器付费，所以我明白我们可以利用自动扩展功能。实施它是一个很大的担忧，因为它会将我们 Kubernetes 集群的其余部分暴露出来，并可能造成混乱。但这绝对是我们的目标，因为现在没有开发人员愿意再开发那个应用程序了，因为部署它太痛苦了。”
他们还渴望探索 Kubernetes 在有状态集方面所做的工作。Eynon-Lynch 说：“目前，我们在 Kubernetes 中运行的所有服务都是无状态的，而 Google 基本上为我们运行数据库并管理备份。但我们有兴趣构建自己的 WebSocket 解决方案，它不需要超级有状态，但可能需要一个小时的状态。”
该项目还将涉及 Prometheus，用于 WebSocket 连接的灰度发布。他说：“我们不知道在所有这些可怕的防火墙后面，WebSocket 连接到我们服务器的可靠性如何。我们不知道 Firebase 做了哪些工作来提高它们的可靠性。所以我真的很期待尝试与我们的客户端建立持久的 WebSocket 连接，并拥有可选的工具来了解它是否正常工作。这是我们的下一个新冒险，进入有状态服务器。”
至于 Prometheus，Eynon-Lynch 认为该公司才刚刚起步。他说：“我们还没有对所有重要功能进行检测，尤其是那些依赖于第三方的功能。我们必须等待这些第三方告诉我们他们宕机了，而他们有时要等很长时间才会告诉我们。所以我真的很兴奋，并且对我们应用程序对实际用户的实际状态越来越有信心，而不仅仅是 CPU 图表所显示的内容，这要归功于 Prometheus 和 Kubernetes。”
对于一家正在快速成长的朝气蓬勃的初创公司（是的，他们正在 招聘！），Pear Deck 对其基础设施在云原生生态系统中的发展感到非常满意。Eynon-Lynch 说：“通常情况下，我会有一些焦虑的事情，想要使用更新、更好的技术，但在云方面，Kubernetes 和 Prometheus 能提供的太多了。”