挑戰
在 2015 年從 Rackspace 遷移到 AWS 後，VSCO 除了執行其 PHP 單體應用 外，還開始構建 Node.js 和 Go 微服務。機器學習團隊的工程經理 Melinda Lu 表示，團隊使用 Docker 對微服務進行了容器化，但“它們都位於獨立的 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 倍，具體取決於服務，公司 EC2 賬單總體節省了約 70%。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。Lu 表示：“Kubernetes 似乎擁有最強大的開源社群。”此外，“我們已經開始在 Google 堆疊上進行標準化，Go 作為一種語言，gRPC 用於資料中心內部我們所有服務之間的通訊。因此，選擇 Kubernetes 對我們來說非常自然。”
當時，受管的 Kubernetes 產品很少，生態系統中可用的工具也較少，因此團隊搭建了自己的叢集，併為特定的部署需求構建了一些自定義元件，例如自動入口控制器和用於金絲雀部署的策略構造。Lu 表示：“我們已經開始拆分單體應用，所以我們一個接一個地遷移，從一些非常小、低風險的服務開始。”“每個新服務都部署在那裡。”第一個服務於 2016 年底遷移，一年後，包括剩餘的單體應用在內的整個堆疊的 80% 都部署在 Kubernetes 上。
其影響是巨大的。Ryan 表示，以前的部署需要“大量手動調整、我們編寫的內部指令碼，而且由於我們分散的 EC2 例項，運維人員必須從頭到尾全程看管”。“我們沒有一套系統化的測試方案，也沒有標準化地使用可複用容器或構建。”現在，入職流程更快了。以前，首次部署需要兩天的人工設定時間；現在只需兩小時。
透過轉向持續整合、容器化和 Kubernetes，速度大幅提升。一個典型服務從程式碼完成到在真實基礎設施上生產部署的時間從一到兩週縮短到兩到四小時。此外，Gattu 表示：“按工時計算，以前是一個人，現在是一個開發人員和一個 DevOps 人員同時進行。”單個生產部署的時間減少了 80%，部署次數也隨之增加，從每年 1200 次增加到每年 3200 次。
實際成本也得到了節省：透過 Kubernetes，VSCO 的 EC2 效率提高了 2 到 20 倍，具體取決於服務，公司的 EC2 賬單總體節省了約 70%。
Ryan 指出，公司能夠以“大致相同的開發團隊規模”從管理一個大型單體應用過渡到 50 多個微服務。“我們之所以能做到這一點，僅僅是因為我們對工具的信任度更高，而且當系統出現壓力點時，我們擁有更大的靈活性。你可以增加服務的 CPU 記憶體需求，而無需啟動和關閉例項，也無需閱讀 AWS 頁面來熟悉大量術語，這對於我們這種規模的公司來說是不可行的。”
Envoy 和 gRPC 也對 VSCO 產生了積極影響。Lu 表示：“我們從 gRPC 中獲得了許多開箱即用的好處：跨多種語言的型別安全、使用 gRPC IDL 輕鬆定義服務、攔截器等內建架構，以及相對於 HTTP/1.1 和 JSON 的效能提升。”
VSCO 是 Envoy 的首批使用者之一，在 Envoy 開源五天後就將其投入生產。Lu 表示：“我們希望透過我們的邊緣負載均衡器直接向移動客戶端提供 gRPC 和 HTTP/2，Envoy 是我們唯一合理的解決方案。”“預設情況下，跨所有服務傳送一致且詳細的統計資料，使得可觀察性和儀表盤標準化變得更加容易。”DevOps 工程師 Ryan Nguyen 表示，Envoy 內建的指標也“極大地幫助了除錯”。
透過部署 Kubernetes、gRPC 和 Envoy，VSCO 的總停機時間減少了 88%，這主要歸因於消除了 JSON-schema 錯誤和服務特定的基礎設施配置錯誤，以及提高了修復停機的速度。
鑑於使用 CNCF 專案的成功經驗，VSCO 正在開始嘗試其他專案，包括 CNI 和 Prometheus。Nguyen 表示：“有大型組織支援這些技術，我們對嘗試這些軟體並將其部署到生產環境更有信心。”
團隊已為 gRPC 和 Envoy 做出了貢獻，並希望在 CNCF 社群中發揮更積極的作用。Lu 表示：“我們的工程師們透過結合大量 Kubernetes 原語，想出了非常有創意的解決方案，這給我留下了深刻印象。”“將 Kubernetes 構造作為服務暴露給我們的工程師，而不是暴露更高階的構造，對我們來說非常有效。它讓你熟悉這項技術並用它做更多有趣的事情。”