挑戰
這家成立三年的初創公司提供一款網路應用程式，供教師在課堂上與學生互動。這款 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 能提供很多幫助。”