[[278022]]

當我們開始推行敏捷時，還沒有容器和 Kubernetes。但是它們改變了過去最困難的部分：將敏捷性從小團隊應用到整個組織。

越來越多的企業正因為一個非常明顯的原因開始嘗試敏捷和 DevOps: 企業需要通過更快的速度和更多的實驗為創新和競爭性提供優勢。而 DevOps 將幫助我們得到所需的創新速度。但是，在小團隊或初創企業中實踐 DevOps 與進行大規模實踐完全是兩碼事。我們都明白這樣的一個事實，那就是在十個人的跨職能團隊中能夠很好地解決問題的方案，當將相同的模式應用到一百個人的團隊中時就可能無法奏效。這條道路是如此艱難，以至于 IT 者最簡單的應對就是將敏捷方法的推行再推遲一年。

但那樣的時代已經結束了。如果你已經嘗試過，但是沒有成功，那么現在是時候重新開始了。

到目前為止，DevOps 需要為許多組織提供個性化的解決方案，因此往往需要進行大量的調整以及付出額外的工作。但在今天，Linux 容器和 Kubernetes 正在推動 DevOps 工具和過程的標準化。而這樣的標準化將會加速整個軟件開發過程。因此，我們用來實踐 DevOps 工作方式的技術最終能夠滿足我們加快軟件開發速度的愿望。

Linux 容器和 Kubernetes 正在改變團隊交互的方式。此外，你可以在 Kubernetes 平臺上運行任何能夠在 Linux 運行的應用程序。這意味著什么呢？你可以運行大量的企業及應用程序（甚至可以解決以前令人煩惱的 Windows 和 Linux 之間的協調問題）。容器和 Kubernetes 能夠滿足你未來將要運行的幾乎所有工作。它們正在經受著未來的考驗，以應對機器學習、人工智能和分析工作等下一代解決問題工具。

讓我們以機器學習為例來思考一下。今天，人們可以在大量的企業數據中找到一些模式。當機器發現這些模式時（想想機器學習），你的員工就能更快地采取行動。隨著人工智能的加入，機器不僅可以發現模式，還可以對模式進行操作。如今，一個積極的軟件開發沖刺周期也就是三個星期而已。有了人工智能，機器每秒可以多次修改代碼。創業公司會利用這種能力來“打擾你”。

考慮一下你需要多快才能參與到競爭當中。如果你對于無法對于 DevOps 和每周一個迭代周期充滿信心，那么考慮一下當那個創業公司將 AI 驅動的過程指向你時會發生什么？現在是時候轉向 DevOps 的工作方式了，否則就會像你的競爭對手一樣被甩在后面。

容器技術如何改變團隊的工作？

DevOps 使得許多試圖將這種工作方式擴展到更大范圍的團隊感到沮喪。即使許多 IT（和業務）人員之前都聽說過敏捷相關的語言、框架、模型（如 DevOps），而這些都有望徹底應用程序開發和 IT 流程，但他們還是對此持懷疑態度。

向你的受眾“推銷”快速開發沖刺也不是一件容易的事情。想象一下，如果你以這種方式買了一棟房子 —— 你將不再需要向開發商支付固定的金額，而是會得到這樣的信息：“我們將在 4 周內澆筑完地基，其成本是 X，之后再搭建房屋框架和鋪設電路，但是我們現在只能夠知道地基完成的時間表。”人們已經習慣了買房子的時候有一個預先的價格和交付時間表。

挑戰在于構建軟件與構建房屋不同。同一個建筑商往往建造了成千上萬個完全相同的房子，而軟件項目從來都各不相同。這是你要克服的第一個障礙。

開發和運維團隊的工作方式確實不同，我之所以知道這一點是因為我曾經從事過這兩方面的工作。企業往往會用不同的方式來激勵他們，開發人員會因為更改和創建而獲得獎勵，而運維專家則會因降低成本和確保安全性而獲得獎勵。我們會把他們分成不同的小組，并且盡量減少互動。而這些角色通常會吸引那些思維方式完全不同的技術人員。但是這樣的解決方案注定會失敗，你必須打破橫亙在開發和運維之間的藩籬。

想想傳統情況下會發生什么。業務會把需求扔過墻，這是因為他們在“買房”模式下運作，并且說上一句“我們 9 個月后見。”開發人員根據這些需求進行開發，并根據技術約束的需要進行更改。然后，他們把它扔過墻傳遞給運維人員，并說一句“搞清楚如何運行這個軟件”。然后，運維人員勤就會勤奮地進行大量更改，使軟件與基礎設施保持一致。然而，最終的結果是什么呢？

通常情況下，當業務人員看到需求實現的最終結果時甚至根本辨認不出。在過去 20 年的大部分時間里，我們一次又一次地目睹了這種模式在軟件行業中上演。而現在，是時候改變了。

Linux 容器能夠真正地解決這樣的問題，這是因為容器彌合開發和運維之間的鴻溝。容器技術允許兩個團隊共同理解和設計所有的關鍵需求，但仍然獨立地履行各自團隊的職責。

有了容器技術，我們可以使得運維團隊的規模更小，但依舊能夠承擔起數百萬應用程序的運維工作，并且能夠使得開發團隊可以更加快速地根據需要更改軟件。(在較大的組織中，所需的速度可能比運維人員的響應速度更快。)

有了容器技術，你可以將所需要交付的內容與它運行的位置分開。你的運維團隊只需要負責運行容器的主機和安全的內存占用，僅此而已。這意味著什么呢？

首先，這意味著你現在可以和團隊一起實踐 DevOps 了。沒錯，只需要讓團隊專注于他們已經擁有的專業知識，而對于容器，只需讓團隊了解所需集成依賴關系的必要知識即可。

如果你想要重新訓練每個人，沒有人會精通所有事情。容器技術允許團隊之間進行交互，但同時也會為每個團隊提供一個圍繞該團隊優勢而構建的強大邊界。開發人員會知道需要消耗什么資源，但不需要知道如何使其大規模運行。運維團隊了解核心基礎設施，但不需要了解應用程序的細節。此外，運維團隊也可以通過更新應用程序來解決新的安全問題，以免你成為下一個數據泄露的熱門話題。

想要為一個大型 IT 組織，比如 30000 人的團隊教授運維和開發技能？那或許需要花費你十年的時間，而你可能并沒有那么多時間。

當人們談論“構建新的云原生應用程序將幫助我們擺脫這個問題”時，請批判性地進行思考。你可以在 10 個人的團隊中構建云原生應用程序，但這對《財富》雜志前 1000 強的企業而言或許并不適用。除非你不再需要依賴現有的團隊，否則你無法一個接一個地構建新的微服務：你最終將成為一個孤立的組織。這是一個誘人的想法，但你不能指望這些應用程序來重新定義你的業務。我還沒見過哪家公司能在如此大規模的并行開發中獲得成功。IT 預算已經受到限制；在很長時間內，將預算翻倍甚至三倍是不現實的。

當奇跡發生時：你好，速度

Linux 容器就是為擴容而生的。一旦你開始這樣做，Kubernetes 之類的編制工具就會發揮作用，這是因為你將需要運行數千個容器。應用程序將不僅僅由一個容器組成，它們將依賴于許多不同的部分，所有的部分都會作為一個單元運行在容器上。如果不這樣做，你的應用程序將無法在生產環境中很好地運行。

思考一下有多少小滑輪和杠桿組合在一起來支撐你的業務，對于任何應用程序都是如此。開發人員負責應用程序中的所有滑輪和杠桿。（如果開發人員沒有這些組件，你可能會在集成時做噩夢。）與此同時，無論是在線下還是在云上，運維團隊都會負責構成基礎設施的所有滑輪和杠桿。做一個較為抽象的比喻，使用Kubernetes，你的運維團隊就可以為應用程序提供運行所需的燃料，但又不必成為所有方面的專家。

開發人員進行實驗，運維團隊則保持基礎設施的安全和可靠。這樣的組合使得企業敢于承擔小風險，從而實現創新。不同于打幾個孤注一擲的賭，公司中真正的實驗往往是循序漸進的和快速的。

從個人經驗來看，這就是組織內部發生的顯著變化：因為人們說：“我們如何通過改變計劃來真正地利用這種實驗能力？”它會強制執行敏捷計劃。

舉個例子，使用 DevOps 模型、容器和 Kubernetes 的 KeyBank 如今每天都會部署代碼。（觀看視頻，其中主導了 KeyBank 持續交付和反饋的 John Rzeszotarski 將解釋這一變化。）類似地，Macquarie 銀行也借助 DevOps 和容器技術每天將一些東西投入生產環境。

一旦你每天都推出軟件，它就會改變你計劃的每一個方面，并且會加速業務的變化速度。Macquarie 銀行和金融服務集團的 CDO，Luis Uguina 表示：“創意可以在一天內觸達客戶。”(參見對 Red Hat 與 Macquarie 銀行合作的案例研究)。

是時候去創造一些偉大的東西了

Macquarie 的例子說明了速度的力量。這將如何改變你的經營方式？記住，Macquarie 不是一家初創企業。這是 CIO 們所面臨的顛覆性力量，它不僅來自新的市場進入者，也來自老牌同行。

開發人員的自由還改變了運營敏捷商店的 CIO 們的人才方程式。突然之間，大公司里的個體（即使不是在最熱門的行業或地區）也可以產生巨大的影響。Macquarie 利用這一變動作為招聘工具，并向開發人員承諾，所有新招聘的員工將會在第一周內推出新產品。

與此同時，在這個基于云的計算和存儲能力的時代，我們比以往任何時候都擁有更多可用的基礎設施?？紤]到機器學習和人工智能工具將很快實現的飛躍，這是幸運的。

所有這些都說明現在正是打造偉大事業的好時機。考慮到市場創新的速度，你需要不斷地創造偉大的東西來保持客戶的忠誠度。因此，如果你一直在等待將賭注押在 DevOps 上，那么現在就是正確的時機。容器技術和 Kubernetes 改變了規則，并且對你有利。