挑戰
這家成立三年的新創公司為教師提供一個網路應用程式，讓他們在課堂上與學生互動。這個 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 中的組態上進行 pull request，而最大的信心來自於抽象化的穩固性，以及我們對 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 說。「但我們有興趣建立我們自己的網路插槽解決方案，該解決方案不必是超級有狀態的，但可能會有大約一小時的狀態在其上。」
該專案也將涉及 Prometheus，用於網路插槽連線的暗啟動。「我們不知道在所有這些可怕的防火牆之後，網路插槽連線對我們的伺服器有多可靠，」他說。「我們不知道 Firebase 為使其更可靠做了哪些工作。所以我非常期待嘗試獲得與我們用戶端的持久連線，並擁有可選工具來了解它是否正在運作。那是我們的下一個新冒險，進入有狀態伺服器。」
至於 Prometheus，Eynon-Lynch 認為公司才剛剛開始。「我們還沒有監控我們所有重要的功能，尤其是那些依賴第三方的功能，」他說。「我們必須等待這些第三方告訴我們他們當機了，但有時他們很久都不會說。所以我現在真的感到非常興奮，並且對我們的應用程式對於實際使用者的真實狀態越來越有信心，而不僅僅是 CPU 圖表所顯示的數據，這都要歸功於 Prometheus 和 Kubernetes。」
對於一家持續快速成長的敏捷新創公司——而且是的，他們正在 徵才！——Pear Deck 對於其基礎架構在雲原生生態系統中的發展顯然感到滿意。「通常我會有一些焦慮的事情，想要獲得更新、更好的技術，」Eynon-Lynch 說，「但就雲端而言，Kubernetes 和 Prometheus 提供了非常多的價值。」