挑战
这家成立三年的初创公司提供一款网络应用程序，供教师在课堂上与学生互动。这款 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 对我们产生了巨大的影响，就像松了一口气，感觉我们知道发生了什么，”他说。“（Firebase 警报）只花了 45 分钟就实现了，因为我们知道 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 说。“但我们有兴趣构建自己的 WebSocket 解决方案，它不必是超级有状态的，但可能会有大约一小时的状态。”
该项目还将涉及 Prometheus，用于对 WebSocket 连接进行暗启动。“我们不知道在所有这些可怕的防火墙后面，WebSocket 连接对我们的服务器会有多可靠，”他说。“我们不知道 Firebase 做了哪些工作来提高它们的可靠性。所以我真的很期待尝试让 WebSocket 与我们的客户端建立持久连接，并拥有可选工具来了解它是否正常工作。这是我们下一个新的冒险，进入有状态服务器。”
至于 Prometheus，Eynon-Lynch 认为公司才刚刚起步。“我们还没有对所有重要功能进行检测，特别是那些依赖第三方功能，”他说。“我们必须等待那些第三方告诉我们它们已关闭，有时它们很长时间都不会告诉我们。因此，我非常兴奋，并且对我们的应用程序为实际用户服务的实际状态越来越有信心，而不仅仅是 CPU 图表所显示的数据，这都归功于 Prometheus 和 Kubernetes。”
对于一家仍在快速发展的活跃初创公司——没错，他们正在招聘！——Pear Deck 对其基础设施在云原生生态系统中的演变感到非常满意。“通常我会有一些焦虑，想要尝试新的、更好的技术，”Eynon-Lynch 说，“但就云而言，Kubernetes 和 Prometheus 能提供很多帮助。”