挑戰
在 2015 年從 Rackspace 遷移到 AWS 之後，VSCO 開始建置 Node.js 和 Go 微服務，同時也運行其 PHP 單體式架構。團隊使用 Docker 將微服務容器化，但機器學習團隊的工程經理 Melinda Lu 表示：「它們都位於獨立的 EC2 執行個體群組中，每個服務都專用。」社群團隊的資深軟體工程師 Naveen Gattu 補充說：「這造成了大量資源浪費。我們開始尋找一種方法來整合，並提高 AWS EC2 執行個體的效率。」
解決方案
該團隊開始探索排程系統的想法，並研究了包括 Mesos 和 Swarm 在內的幾種解決方案，然後決定採用 Kubernetes。VSCO 在其雲端原生堆疊中也使用了 gRPC 和 Envoy。
影響
資深軟體工程師 Brendan Ryan 表示，以前，部署需要「大量手動調整、我們編寫的內部腳本，而且由於我們分散的 EC2 執行個體，維運團隊必須從頭到尾監控整個過程」。 「我們實際上沒有關於以有條理的方式進行測試，以及以標準化方式使用可重複使用的容器或建置的方案。」現在有了更快的入門流程。以前，首次部署的時間需要兩天的實際操作設定時間；現在只需兩個小時。透過轉向持續整合、容器化和 Kubernetes，速度顯著提高。從程式碼完成到在實際基礎架構上部署到生產環境的時間，從一到兩週縮短到一般服務的兩到四小時。Gattu 補充說：「以人工時計算，這是一個人對比一個開發人員和一個 DevOps 人員同時進行。」生產環境中單次部署的時間減少了 80%，部署次數也從每年 1200 次增加到每年 3200 次。也確實節省了資金：透過 Kubernetes，VSCO 的 EC2 效率提高了 2 倍到 20 倍，具體取決於服務，總計為公司節省了約 70% 的 EC2 費用。Ryan 指出，公司能夠從管理一個大型單體式應用程式轉變為管理 50 多個微服務，「開發團隊的規模大致相同。而我們之所以能夠做到這一點，是因為我們對我們的工具和更大的彈性增加了信任，因此我們不需要聘請 DevOps 工程師來調整每個服務。」借助 Kubernetes、gRPC 和 Envoy，VSCO 的總停機時間減少了 88%，主要原因是消除了 JSON-schema 錯誤和特定於服務的基礎架構配置錯誤，並提高了修復停機的速度。
在 VSCO 於 2015 年遷移到 AWS 且使用者群超過 3000 萬之後，團隊很快意識到這種設定不再可行。開發人員已開始建置一些 Node 和 Go 微服務，團隊嘗試使用 Docker 將其容器化。但機器學習團隊的工程經理 Melinda Lu 表示：「它們都位於獨立的 EC2 執行個體群組中，每個服務都專用。」社群團隊的資深軟體工程師 Naveen Gattu 補充說：「這造成了大量資源浪費。我們開始尋找一種方法來整合，並提高 EC2 執行個體的效率。」
該團隊評估了包括 Mesos 和 Swarm 在內的一些排程解決方案，並考慮了易用性和實作、支援程度以及是否為開放原始碼等檢查清單，然後決定採用 Kubernetes。「Kubernetes 似乎擁有最強大的開放原始碼社群，」Lu 說。此外，「我們已開始將許多 Google 堆疊標準化，以 Go 作為語言，gRPC 用於我們資料中心內部自身服務之間幾乎所有的通訊。因此，對我們來說，選擇 Kubernetes 看起來非常自然。」
當時，託管 Kubernetes 產品很少，生態系統中可用的工具也較少，因此團隊建立了自己的叢集，並為其特定的部署需求建置了一些自訂組件，例如自動 Ingress 控制器和金絲雀部署的政策建構。「我們已經開始分解單體式架構，因此我們逐一遷移，從非常小的、低風險的服務開始，」Lu 說。「每個新服務都部署在那裡。」第一個服務於 2016 年底遷移，一年後，整個堆疊的 80% 都部署在 Kubernetes 上，包括其餘的單體式架構。
影響非常巨大。Ryan 說，以前，部署需要「大量手動調整、我們編寫的內部腳本，而且由於我們分散的 EC2 執行個體，維運團隊必須從頭到尾監控整個過程」。 「我們實際上沒有關於以有條理的方式進行測試，以及以標準化方式使用可重複使用的容器或建置的方案。」現在有了更快的入門流程。以前，首次部署的時間需要兩天的實際操作設定時間；現在只需兩個小時。
透過轉向持續整合、容器化和 Kubernetes，速度顯著提高。從程式碼完成到在實際基礎架構上部署到生產環境的時間，從一到兩週縮短到一般服務的兩到四小時。此外，Gattu 說，「以人工時計算，這是一個人對比一個開發人員和一個 DevOps 人員同時進行。」生產環境中單次部署的時間減少了 80%，部署次數也從每年 1200 次增加到每年 3200 次。
也確實節省了資金：透過 Kubernetes，VSCO 的 EC2 效率提高了 2 倍到 20 倍，具體取決於服務，總計為公司節省了約 70% 的 EC2 費用。
Ryan 指出，公司能夠從管理一個大型單體式應用程式轉變為管理 50 多個微服務，「開發團隊的規模大致相同。而我們之所以能夠做到這一點，是因為我們對我們的工具和更大的彈性增加了信任，當我們的系統中出現壓力點時更是如此。您可以增加服務的 CPU 記憶體需求，而無需啟動和關閉執行個體，並閱讀 AWS 頁面只是為了熟悉許多術語，這對於我們這種規模的公司來說並不可行。」
Envoy 和 gRPC 也對 VSCO 產生了積極的影響。「我們從 gRPC 中獲得了許多開箱即用的好處：跨多種語言的類型安全、使用 gRPC IDL 輕鬆定義服務、內建架構（如攔截器）以及相較於 HTTP/1.1 和 JSON 的效能改進，」Lu 說。
VSCO 是 Envoy 的首批使用者之一，在 Envoy 開源後五天就將其投入生產環境。「我們希望透過邊緣負載平衡器直接向行動用戶端提供 gRPC 和 HTTP/2，而 Envoy 是我們唯一合理的解決方案，」Lu 說。「預設情況下，跨所有服務發送一致且詳細的統計資訊的能力，使儀表板的可觀察性和標準化變得更加容易。」DevOps 工程師 Ryan Nguyen 表示，Envoy 內建的指標也「對除錯有很大幫助」。
借助 Kubernetes、gRPC 和 Envoy，VSCO 的總停機時間減少了 88%，主要原因是消除了 JSON-schema 錯誤和特定於服務的基礎架構配置錯誤，並提高了修復停機的速度。
鑑於使用 CNCF 專案的成功經驗，VSCO 開始嘗試其他專案，包括 CNI 和 Prometheus。「有一個大型組織支持這些技術，我們更有信心嘗試這個軟體並將其部署到生產環境，」Nguyen 說。
該團隊為 gRPC 和 Envoy 做出了貢獻，並希望在 CNCF 社群中更加活躍。「我真的印象深刻，看到我們的工程師如何透過簡單地結合許多 Kubernetes 基礎組件，想出真正創新的解決方案，」Lu 說。「將 Kubernetes 建構公開為我們工程師的服務，而不是公開更高階的建構，對我們來說效果很好。它可以讓您熟悉這項技術，並用它做更多有趣的事情。」