挑戰
Zalando，歐洲領先的線上時尚平臺，自2008年成立以來經歷了指數級增長。2015年，Zalando計劃進一步擴充套件其原有電商網站，增加新的服務和產品，並進行了一次徹底的轉型，形成了自主自組織團隊。這一變革需要一個能夠隨著工程組織發展而擴充套件的基礎設施。Zalando 的技術部門開始重寫其應用程式以適應雲環境，並開始將其基礎設施從本地資料中心遷移到雲端。雖然起初並未立即考慮編排，但隨著團隊遷移到 Amazon Web Services (AWS)：“我們看到了團隊在 AWS 上處理基礎設施和 Cloud Formation 時遇到的痛苦，”開發人員生產力主管 Henning Jacobs 說。“團隊和合規性方面的運營開銷仍然過大。” 為了提供更好的支援，叢集管理被引入。
解決方案
該公司現在使用 Kubernetes 編排在 AWS 上執行其 Docker 容器。
影響
Jacobs 說，舊的基礎設施“難以真正採用新技術，而且 DevOps 團隊被認為是瓶頸。”“現在，有了這個雲基礎設施，他們擁有這種打包格式，可以包含任何在 Linux 核心上執行的東西。這讓很多人都非常高興。工程師們熱愛自主性。”
Zalando 開發人員生產力主管 Jacobs 說：“它最初是一個 PHP 電子商務網站，很容易上手，但無法滿足業務需求。”
當時，該公司開始將其業務從德國本土擴充套件到其他歐洲市場。快進到今天，Zalando 現有員工超過 14,000 人，2016 年營收 36 億歐元，業務遍及 15 個國家。“在各個方面都取得了增長，並且不斷擴充套件，這真是一生難得的經歷，”他說。
更不用說像 Jacobs 這樣的基礎設施專家所擁有的獨特機會。他剛加入後，公司就開始內部重寫所有應用程式。“這通常是我們的策略，”他說。“例如，我們最初使用自己的物流倉庫，但一開始你不知道如何開發物流軟體，所以你會使用一些供應商軟體。然後我們用自己的軟體替換了它，因為現成的軟體沒有競爭力。你需要根據你具體的業務需求來最佳化這些流程。”
在重寫應用程式的同時，Zalando 還設定了一個目標，即從基本的電子商務擴充套件到一個提供多租戶、大幅增加產品種類和款式、當日達甚至您自己的個人線上造型師的平臺。
規模化需求最終促使公司踏上了雲原生之旅。同時，它也採用了基於微服務的軟體架構，這使得工程團隊在專案上擁有更大的自主權和所有權。Jacobs 說：“這種向雲的遷移是必要的，因為在資料中心，你無法擁有自主團隊。你擁有相同的基礎設施，並且它非常同質化，所以你只能執行你的 Java 或 Python 應用程式。”
Zalando 開始將其基礎設施從兩個本地資料中心遷移到雲端，這需要將舊應用程式遷移以適應雲環境。“我們決定徹底改變，”Jacobs 說。“我們的亞馬遜網路服務基礎設施設定如下：每個團隊都有自己的 AWS 賬戶，這是完全隔離的，這意味著沒有‘直接遷移’。你基本上必須重寫你的應用程式，使其適應雲環境，甚至包括持久層。我們勇敢地從頭開始，重新構建了一切，首先選擇 Docker 作為通用的容器化技術，然後在此基礎上構建基礎設施。”
該公司決定最初暫緩編排，但隨著團隊遷移到 AWS，“我們看到了團隊在 AWS 上處理基礎設施和雲形成時遇到的痛苦，”Jacobs 說。
Zalando 的 200 多個自主工程團隊決定使用什麼技術，並可以使用自己的 AWS 賬戶操作自己的應用程式。這種設定被證明是一個合規性挑戰。即使有嚴格的操作規範和自動化的合規性檢查，工程團隊和 IT 合規部門在處理合規性問題時也感到不堪重負。“當掃描雲基礎設施時，我們檢測到不合規行為，並出現違規，”Jacobs 說。“一切皆有可能，沒有強制執行，因此你不得不面對違規（並解決它們），而不是在一開始就預防錯誤。這意味著團隊的開銷——以及合規和運營的開銷。在 AWS 上啟動新的 EC2 例項也需要時間，這影響了我們的部署速度。”
團隊意識到他們需要“利用叢集管理帶來的價值”，Jacobs 說。當他們最初在 2015 年考慮平臺即服務（PaaS）選項時，市場是分散的；但“現在似乎有一個明顯的贏家。選擇 Kubernetes 似乎是一個不錯的選擇。”
向 Kubernetes 的過渡始於 2016 年 Zalando 的駭客周，期間參與者將其專案部署到 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 說。“我們不希望有‘寵物叢集’（pet clusters）。我們不想去了解他們有什麼工作負載；它應該開箱即用。考慮到這一點，叢集自動擴縮非常重要。叢集管理有許多不同的方法，但這不屬於核心部分。因此，我們建立了兩個元件來提供叢集、擁有叢集登錄檔以及管理整個叢集生命週期。”
Jacobs 的團隊還致力於改進 Kubernetes-AWS 整合。“因此你受到很大的限制。你需要基礎設施來擴充套件每個自主團隊的想法。”此外，“仍然缺少許多最佳實踐，”Jacobs 說。例如，團隊最近解決了一個 Pod 安全策略問題。“Kubernetes 中已經有一個概念，但沒有文件說明，所以有點棘手，”他說。龐大的 Kubernetes 社群對解決這個問題幫助很大。為了幫助其他公司走上同樣的道路，Jacobs 將團隊的經驗教訓彙編成一份名為《在生產環境中執行 Kubernetes》的文件。
最終，Kubernetes 讓 Zalando 能夠引入並維護公司設想的新產品，以發展其平臺。“時尚建議產品使用 Scala，而在我們以前的基礎設施上實現這一點非常困難，”Jacobs 說。“這是一種權宜之計，而且那個團隊需要平臺團隊越來越多的支援，僅僅因為他們使用了不同的技術。現在有了 Kubernetes，它是自主的。無論工作負載是什麼，那個團隊都可以按照自己的方式行事，Kubernetes 避免了其他的瓶頸。”
展望未來，Jacobs 認為 Zalando 的新基礎設施是公司正在進行的許多其他事情的強大推動者，從新的物流軟體，到連線品牌的平臺功能，再到資料科學家夢想中的產品。“一個願景是，如果你觀看下一部詹姆斯·邦德電影，看到他穿的西裝，你應該能夠自動訂購，並在一個小時內送達你，”Jacobs 說。“這是關於連線整個時尚領域。如果你在同一個資料中心執行所有東西，並且因此受到很大的限制，那麼這絕對是不可能的。你需要基礎設施來擴充套件每個自主團隊的想法。”
對於考慮這項技術的其他公司，Jacobs 表示他不一定會建議他們完全按照 Zalando 的方式去做。“如果你準備好在某些方面失敗，那也沒關係，”他說。“你需要設定正確的期望。並非所有事情都會奏效。重寫應用程式和這種組織變革可能會帶來破壞性。我們遷移的第一個產品至關重要。它有很多依賴關係，而且花費的時間比預期的要長。也許我們應該從一些不那麼複雜、不那麼關鍵的業務開始，只是為了試水。”
但一旦他們到達彼岸，“每個人都很清楚沒有大的替代方案，”雅各布斯補充道。“Kubernetes API 允許我們以與雲提供商無關的方式執行應用程式，這使我們能夠在未來幾年內重新審視 IaaS 提供商。Zalando Technology 受益於遷移到 Kubernetes，因為我們能夠利用現有知識建立工程平臺，為工程師提供靈活性和速度，同時顯著減少運營開銷。我們期望 Kubernetes API 成為 PaaS 基礎設施的全球標準，並對持續的旅程感到興奮。”