挑戰
Zalando 是歐洲領先的線上時尚平台，自 2008 年成立以來，經歷了指數級的成長。2015 年，為了進一步擴展其原始電子商務網站，納入新的服務和產品，Zalando 展開了徹底轉型，促成了自主的自組織團隊。這種改變需要能夠隨著工程組織的成長而擴展的基礎架構。Zalando 的技術部門開始重寫其應用程式，使其能夠在雲端環境中運行，並開始將其基礎架構從內部部署資料中心遷移到雲端。雖然協調並非立即被考慮，但隨著團隊遷移到 Amazon Web Services (AWS)：「我們看到了團隊在使用 AWS 上的基礎架構和 Cloud Formation 時遇到的痛點」，開發者生產力主管 Henning Jacobs 說。「對於團隊來說，仍然有太多的營運負擔和合規性問題。」為了提供更好的支援，叢集管理開始發揮作用。
解決方案
公司現在使用 Kubernetes 協調在 AWS 上運行其 Docker 容器。
影響
Jacobs 說，使用舊的基礎架構「很難適當地擁抱新技術，而 DevOps 團隊被認為是瓶頸」。 「現在，有了這種雲端基礎架構，他們擁有這種封裝格式，可以包含任何在 Linux 核心上運行的東西。這讓很多人非常高興。工程師們喜歡自主性。」
「它最初是一個 PHP 電子商務網站，很容易上手，但無法隨著業務需求擴展」，Zalando 開發者生產力主管 Jacobs 說。
當時，公司開始將業務從德國本土擴展到其他歐洲市場。快轉到今天，Zalando 現在擁有超過 14,000 名員工，2016 年的收入為 36 億歐元，業務遍及 15 個國家。「隨著各方面的成長和不斷的擴張，這是一次千載難逢的經歷」，他說。
更不用說對於像 Jacobs 這樣的基礎架構專家來說，這是一個獨特的機會。就在他加入後不久，公司開始內部重寫所有應用程式。「這總體上是我們的策略」，他說。「例如，我們從自己的物流倉庫開始，但起初你不知道如何做物流軟體，所以你使用了一些供應商軟體。然後我們用自己的軟體取代了它，因為使用現成的軟體你沒有競爭力。你需要根據你的特定業務需求來優化這些流程。」
在並行重寫其應用程式的同時，Zalando 設定了一個目標，即從基本的電子商務擴展到提供多租戶、大幅增加商品種類和款式、當日送達甚至 您自己的個人線上造型師 的平台。
擴展的需求最終引導公司走上了雲原生之旅。它也擁抱了基於微服務的軟體架構，這種架構賦予工程團隊更多的自主性和專案所有權。「遷移到雲端是必要的，因為在資料中心你無法擁有自主團隊。你擁有相同的基礎架構，而且非常同質化，所以你只能運行你的 Java 或 Python 應用程式」，Jacobs 說。
Zalando 開始將其基礎架構從兩個內部部署資料中心遷移到雲端，這需要遷移舊的應用程式以實現雲端就緒。「我們決定徹底決裂」，Jacobs 說。「我們的 Amazon Web Services 基礎架構的設置是這樣的：每個團隊都有自己的 AWS 帳戶，這是完全隔離的，這意味著沒有『直接轉移』。你基本上必須重寫你的應用程式，使其雲端就緒，甚至包括持久層。我們勇敢地回到繪圖板，重新做了所有事情，首先選擇 Docker 作為通用的容器化技術，然後從那裡構建基礎架構。」
公司決定在開始時暫緩協調，但隨著團隊遷移到 AWS，「我們看到了團隊在使用 AWS 上的基礎架構和雲端組態時遇到的痛點」，Jacobs 說。
Zalando 超過 200 個自主工程團隊決定使用哪些技術，並且可以使用自己的 AWS 帳戶來營運自己的應用程式。這種設置被證明是一個合規性挑戰。即使制定了嚴格的遊戲規則和自動化的合規性檢查，工程團隊和 IT 合規部門也因應對合規性問題而負擔過重。「當掃描雲端基礎架構時，我們會檢測到不合規行為的違規情況」，Jacobs 說。「一切皆有可能，沒有任何強制執行，所以你必須接受違規（並解決它們），而不是從一開始就防止錯誤。這意味著團隊的負擔—以及合規和營運的負擔。在 AWS 上啟動新的 EC2 執行個體也需要時間，這會影響我們的部署速度。」
團隊意識到他們需要「利用從叢集管理中獲得的價值」，Jacobs 說。當他們在 2015 年首次研究平台即服務 (PaaS) 選項時，市場是分散的；但是「現在似乎有一個明顯的贏家。使用 Kubernetes 似乎是一個不錯的選擇。」
遷移到 Kubernetes 的過程始於 2016 年 Zalando 的 Hack Week，參與者將他們的專案部署到 Kubernetes 叢集。從那裡，技術基礎架構部門的 60 名成員加入了—然後工程團隊也一個接一個地加入。「我們總是先與他們交談，並確保每個人的期望都很明確」，Jacobs 說。「然後我們進行一些 Kubernetes 訓練，這主要是針對我們的 CI/CD 設置的訓練，因為我們使用者的使用者介面主要透過 CI/CD 系統。但他們必須了解基本的 Kubernetes 概念和 API。接下來是每週與每個團隊同步，以檢查他們的進度。一旦他們有東西在生產環境中運行，我們想看看一切是否正常，以及我們可以改進哪些方面。」
目前，Zalando 正在運行最初的 40 個 Kubernetes 叢集，並計劃在可預見的未來進行擴展。一旦 Zalando 開始將應用程式遷移到 Kubernetes，結果立竿見影。「Kubernetes 是我們無縫端到端開發者體驗的基石。我們能夠使用單一一致且宣告式的 API 將想法交付到生產環境」，Jacobs 說。「自我修復的基礎架構提供了流暢的體驗，較高層次的抽象概念建立在低層次的最佳實務之上。我們預想所有 Zalando 交付團隊都能在由 Kubernetes 提供的最先進、可靠且可擴展的叢集基礎架構上運行其容器化應用程式。」
Jacobs 說，使用舊的內部部署基礎架構「很難適當地擁抱新技術，而 DevOps 團隊被認為是瓶頸」。 「現在，有了這種雲端基礎架構，他們擁有這種封裝格式，可以包含任何在 Linux 核心中運行的東西。這讓很多人非常高興。工程師們喜歡自主性。」
Zalando 的 Kubernetes 實施過程中遇到了一些挑戰。「我們是一個七人團隊，為不同的工程團隊提供叢集，我們的目標是為他們所有人提供堅如磐石的體驗」，Jacobs 說。「我們不想要寵物叢集。我們不想了解他們有什麼工作負載；它應該開箱即用。考慮到這一點，叢集自動擴展非常重要。叢集管理有很多不同的方法，這不是核心的一部分。所以我們創建了兩個組件來佈建叢集、擁有叢集註冊表以及管理整個叢集生命週期。」
Jacobs 的團隊還致力於改進 Kubernetes-AWS 整合。「因此，你受到很大的限制。你需要基礎架構來擴展每個自主團隊的想法。」此外，「仍然有很多最佳實務缺失」，Jacobs 說。例如，該團隊最近解決了一個 Pod 安全策略問題。「Kubernetes 中已經有一個概念，但它沒有文檔記錄，所以有點棘手」，他說。龐大的 Kubernetes 社群為解決這個問題提供了很大的幫助。為了幫助其他公司走上相同的道路，Jacobs 將他團隊的學習成果編寫成一份名為 在生產環境中運行 Kubernetes 的文檔。
最終，Kubernetes 使 Zalando 能夠推出和維護公司預想的新產品，以擴展其平台。「時尚建議 產品使用了 Scala，並且使用我們以前的基礎架構很難實現這一點」，Jacobs 說。「這是一個權宜之計，而且該團隊需要平台團隊越來越多的支持，只是因為他們使用了不同的技術。現在有了 Kubernetes，它是自主的。無論工作負載是什麼，該團隊都可以按照自己的方式進行，而 Kubernetes 可以防止其他瓶頸。」
展望未來，Jacobs 認為 Zalando 的新基礎架構是公司正在進行的其他工作的巨大推動者，從其新的物流軟體到連接品牌的平台功能，再到資料科學家夢想的產品。「一個願景是，如果你觀看下一部詹姆士·龐德電影，看到他穿的西裝，你應該能夠自動訂購它，並在一個小時內送到你手中」，Jacobs 說。「這是關於連接整個時尚領域。如果每個人都在同一個資料中心運行，並且因此受到很大限制而造成瓶頸，那麼這絕對是不可能的。你需要基礎架構來擴展每個自主團隊的想法。」
對於其他正在考慮這項技術的公司，Jacobs 說他未必建議完全按照 Zalando 的方式去做。「如果你準備好在某些事情上失敗，那麼這樣做是可以的」，他說。「你需要設定正確的期望。並非一切都會奏效。重寫應用程式和這種組織變革可能會帶來破壞。我們遷移的第一個產品至關重要。有很多依賴關係，而且花費的時間比預期的要長。也許我們應該從一些不那麼複雜、不那麼業務關鍵的事情開始，只是為了試水。」
但是一旦他們到達彼岸，「每個人都很清楚，沒有其他更好的替代方案」，Jacobs 補充說。「Kubernetes API 允許我們以雲端供應商不可知的方式運行應用程式，這使我們能夠在未來幾年重新評估 IaaS 供應商。Zalando 技術受益於遷移到 Kubernetes，因為我們能夠利用我們現有的知識來創建一個工程平台，為我們的工程師提供靈活性和速度，同時顯著降低營運負擔。我們期望 Kubernetes API 成為 PaaS 基礎架構的全球標準，並對持續的旅程感到興奮。」