挑戰
全球最大的資產管理公司 貝萊德 營運著一套受到嚴格控制的靜態部署方案，多年來這套方案讓他們實現了可擴展性。但在他們的資料科學部門中，需要更動態的資源存取方式。「我們希望能夠讓每位投資者都能使用資料科學，這表示可以使用 Python 筆記本，甚至是更進階的功能，例如基於 Spark 的 MapReduce 引擎。」貝萊德產品集團董事總經理 Michael Francis 說道，該集團負責營運公司的投資管理平台。「在使用者桌面上管理複雜的 Python 安裝非常困難，因為每個人最終都會得到稍微不同的環境。我們現有的環境可以做到這些事，但我們需要使其更真實、更廣泛且更具擴展性。能夠根據需求啟動、關閉，並使其更具動態性，成為我們一個關鍵的思考過程。重點不是我們必須解決我們主要的核心生產問題，而是我們如何擴展它？我們如何演進？」
解決方案
Francis 從去年使用 Docker 環境進行的試驗計畫中所學到的經驗，組建了一個由 20 人組成的跨部門團隊，使用 Kubernetes 開發投資者研究網路應用程式，目標是在一個季度內將其投入生產環境。
影響
Francis 說：「我們的目標是：如何在不必在使用者桌面上安裝工具的情況下，快速地提供人們工具？」而團隊在 100 天內達成了目標。Francis 對於結果感到滿意並表示：「隨著時間的推移，我們將把這個基礎架構用於許多其他的應用程式工作負載。不僅僅是資料科學；而是這種需要動態性的應用程式類型。但我認為我們距離做出[大規模]決策還有 6-12 個月的時間。我們需要獲得在生產環境中運行系統的經驗，我們需要了解故障模式以及如何最好地管理營運問題。有趣的是，僅僅擁有這項技術就正在改變我們的開發人員開始思考他們未來開發的方式。」
在 2017 年，貝萊德產品集團員工的管理目標之一是「開發酷炫的東西」。在董事總經理 Michael Francis 的領導下，一個由 20 人組成的跨部門團隊做到了：他們部署了一個完整的生產 Kubernetes 環境，並在其上發布了一個新的投資者研究網路應用程式。在 100 天內。
資深系統管理員 Karl Wieman 說：「對於像貝萊德這樣全球最大的資產管理公司來說，『僅僅設備採購有時就需要 100 天，更不用說從概念到交付了。』」這是一個積極的時程表。但它推動了進展。事實上，該專案實現了兩個目標：它解決了一個業務問題（創建所需的網路應用程式），並提供了 Kubernetes 的真實生產環境經驗，Kubernetes 是一種雲原生技術，公司渴望探索。「重點不是我們必須解決我們主要的核心生產問題，而是我們如何擴展它？我們如何演進？」Francis 說道。這個專案的最終成功，除了交付應用程式之外，還在於「我們成功地將一種全新的思維模式整合到我們不想改變的受控基礎架構中。」
Francis 說：「畢竟，在成立三十年後，貝萊德擁有『一個非常完善的環境來管理我們的運算資源。』」我們在機器上管理大型叢集程序，因此我們以非常雲端化的概念方式，為我們的主要生產流程進行大量的協調和管理。我們能夠以非常受控的靜態部署方案來管理它們，這為我們帶來了巨大的可擴展性。」
雖然這對於核心生產來說運作良好，但公司發現某些資料科學工作負載需要更動態的資源存取方式。「這是一個非常突發的過程，」Francis 說道，他是公司 Aladdin 投資管理平台部門的資料主管。
Aladdin 連接了即時貨幣管理所需的人員、資訊和技術，它在內部使用，也作為平台銷售給其他資產管理公司和保險公司。「我們希望能夠讓每位投資者都能使用資料科學，這表示可以使用 Python 筆記本，甚至是更進階的功能，例如基於 Spark 的 MapReduce 引擎。」Francis 說道。但是，「在使用者桌面上管理複雜的 Python 安裝非常困難，因為每個人最終都會得到稍微不同的環境。Docker 允許我們扁平化該環境。」
儘管如此，挑戰依然存在。「如果你有一個共享叢集，你就會遇到這種蜂擁而至的問題，每個人都想同時做同樣的事情，」Francis 說道。「你可以對其設定限制，但你必須建立一個基礎架構來定義我們流程的限制，而 Python 筆記本並非真正為此設計。我們現有的環境可以做到這些事，但我們需要使其更真實、更廣泛且更具擴展性。能夠根據需求啟動、關閉，並使其更具動態性，成為我們一個關鍵的思考過程。」
Francis 的團隊由來自技術、基礎架構、生產營運、開發和資訊安全的經理組成，能夠全面地看待問題，並提出對貝萊德來說有意義的解決方案。「我們最初的初步構想是，我們將使用 Ansible 建構一切，並使用一些完全不同的分散式環境來運行所有內容，」Francis 說道。「那絕對是錯誤的做法。如果我們作為開發團隊自行開發這個解決方案，那將會是一個非常不同的產品。而且會非常昂貴。我們不會走在我們現有的協調系統下運行的路線。因為我們不了解它。這些人[在營運和基礎架構部門]了解它。擁有跨領域團隊讓我們能夠找到正確的解決方案，而這實際上意味著我們最終建構的數量遠遠少於我們原先認為的數量。」
為了尋找一種可以在使用者層級管理使用量的解決方案，Francis 的團隊傾向於 Red Hat 的 OpenShift Kubernetes 產品。公司已經試驗過其他雲原生環境，但團隊喜歡 Kubernetes 是開源的，並且「我們感覺長期而言，趨勢是朝著 Kubernetes 發展，」Francis 說道。「通常，我們在做出技術選擇時，會相信這些技術在未來 5-10 年內將以某種形式存在。而現在，在這個領域，Kubernetes 感覺像是會持續存在的技術。」生產營運副總裁 Uri Morris 補充說道：「當你看到非 Google 的 Kubernetes 提交者超過 Google 的提交者時，這就是一個動能的指標。」
一旦做出這個決定，主要的挑戰就是弄清楚如何讓 Kubernetes 在貝萊德現有的框架內運作。「專案經理 Michael Maskallis 說：『這關係到了解除了將 Kubernetes 附加到我們現有的技術平台上之外，我們如何才能操作、管理和支援像這樣的平台。』我們現有的所有控制措施、變更管理流程、軟體開發生命週期、我們經歷的入職流程——我們如何才能完成所有這些事情？」
第一個（預期的）障礙是解決貝萊德企業防火牆後面的問題。「Francis 說：『我們的挑戰之一是大多數開源軟體中沒有防火牆。因此，幾乎所有的安裝腳本都會以某種奇怪的方式失敗，而拉取套件不一定能運作。』團隊在使用 Minikube 時遇到了這些類型的問題，並向開源專案進行了一些小的回饋。
還有關於服務發現的問題。「Francis 說：『你可以將 Aladdin 視為一個服務雲，它們之間有 API，讓我們能夠快速建構應用程式。』這一切都基於專有的訊息匯流排，這給了我們各種優勢，但同時，這在第三方[平台]中如何運作呢？」
他們必須解決的另一個問題是，在貝萊德現有的系統中，訊息傳輸協定在不同的開發、測試和生產環境中具有不同的實例。雖然 Kubernetes 實現了更 DevOps 風格的模型，但它對貝萊德來說沒有意義。「Francis 說：『我認為我們非常自豪的是，在這個[新的]基礎架構中，我們仍然能夠非常快速地推動生產，但我們有控制點到位，而且我們不必破壞一切。』這次開發的大部分成本都在於思考如何最好地利用我們的內部工具。因此，它比我們原先認為的要便宜。」
例如，該專案利用了與訊息匯流排相關的工具。「Morris 說道：『Kubernetes 叢集與我們的內部訊息平台通訊的方式是透過閘道程式，而這個閘道程式已經內建了檢查和節流機制。』我們可以利用它們來控制，並可能節流從 Kubernetes 非常彈性的基礎架構到生產基礎架構的請求。我們將繼續朝著這個方向發展。它使我們能夠從營運的角度根據需要進行擴展。」
該解決方案還必須與貝萊德的集中式營運支援團隊結構互補。「Morris 解釋道：『Kubernetes 的核心基礎架構組件已連結到我們現有的協調框架，這表示我們支援團隊中的任何人都可以使用現有的營運工具來控制和查看叢集。』這表示我不需要僱用更多人。」
在確立了這些要點之後，團隊為該專案制定了一個程序：「Maskallis 說道：『我們首先將其部署到開發環境，然後轉移到測試環境，最後依序部署到兩個生產環境。』這推動了我們學習曲線的發展。我們有所有這些移動部件、基礎架構端的軟體組件、直接與 Kubernetes 相關的軟體組件、與我們在貝萊德運營的其餘環境的互連性，以及我們如何連接所有這些部分。如果我們遇到問題，我們會修復它們，然後轉移到不同的環境來複製它，直到我們最終到達我們的生產環境，這個特定的叢集應該位於該處。」
團隊每週舉行一次一小時的工作會議，所有成員（他們分佈在世界各地）都參與其中，以及較小的分組或深入會議，重點討論特定的技術細節。可能的解決方案將會回報給團隊，並在下週進行辯論。「副總裁兼軟體開發人員 Fouad Semaan 說：『我認為使其成為一個成功的實驗的原因是人們必須努力學習，並且他們與他人分享了他們的經驗。』然後，Francis 說：『我們給予我們的工程師空間去做他們擅長的事情。這不是由上而下的。』」
他們遵循一個關鍵的原則：保持專注並避免範圍蔓延。這意味著他們不會使用 Kubernetes 和 Docker 核心中沒有的功能。但如果真的有需要，他們會自己建構這些功能。幸運的是，Francis 說：『由於開發的快速性，許多我們認為必須自己建構的東西都已經被納入核心產品中。[套件管理器 Helm 就是一個例子]。人們有類似的問題。』
在 100 天結束時，該應用程式已為貝萊德內部使用者啟動並運行。最初 30 個使用者的容量在幾小時內就被用完，並迅速增加到 150 個。「Francis 說道：『人們立刻蜂擁而至。』在這個專案的下一個階段，他們計劃擴展叢集以獲得更大的容量。」
更重要的是，他們現在擁有 Kubernetes 的生產環境經驗，可以繼續以此為基礎發展——以及一個完整的框架來部署新的應用程式。「Francis 說：『隨著時間的推移，我們將把這個基礎架構用於許多其他的應用程式工作負載。不僅僅是資料科學；而是這種需要動態性的應用程式類型。』將我們的核心生產流程轉移到其上是正確的地方嗎？ 可能是。我們還沒有到可以說「是」或「否」的地步，但我們認為，在某種形式和規模上擁有 Kubernetes 等技術的真實生產經驗，將使我們能夠理解這一點。我認為我們距離做出[大規模]決策還有 6-12 個月的時間。我們需要獲得在生產環境中運行系統的經驗，我們需要了解故障模式以及如何最好地管理營運問題。」
對於其他正在考慮類似專案的大型公司，Francis 說承諾和奉獻精神是關鍵：「我們從第一天就獲得了[高階管理層]的批准，並承諾我們能夠找到合適的人。如果我必須指出是什麼讓像這樣複雜的事情成功，我會說能夠實際推動它的資深實務人員會產生巨大的影響。」他補充說：「我想對其他像我們這樣的企業傳達的訊息是，你們實際上可以將 Kubernetes 整合到現有的、完善協調的機制中。你們不必拋棄你們所做的一切。而使用 Kubernetes 讓複雜的問題變得 значительно 更容易。」