今天，幾乎每個企業都在處理影響多個領域的數字化轉型，包括DevOps、微服務和雲的戰略。容器在每個領域都發揮著特殊的作用。

DevOps戰略

IT機構分為運營和應用開發。他們作為兩個獨立的團隊運作，每個團隊都有自己的一套目標。大多數企業正在朝著DevOps的方向發展，將這兩個團隊結合到一起。

容器在DevOps計劃的成功中發揮著重要作用。DevOps成功的關鍵標準之一是提升開發對運營的影響力。開發人員不應該只將程式碼丟給運營操作，還應該關心程式碼如何在生產環境中執行。常見的技術是將“基礎設施作為程式碼”。開發團隊應該把環境設定作為程式碼提供，而不是提供容易出錯的安裝指令頁面。

這正是容器所解決的問題。容器映像是容器的模板，包括整個堆疊，從基本作業系統到應用程式程式碼。使用容器，開發人員不會僅僅構建從Dev到QA到Prod的應用程式工件（例如.jar檔案），相反，他們將傳遞一個版本化的容器映像，其中包括構建的工件和工件執行所在的環境。容器是包括所有的，把從作業系統庫到中介軟體到應用程式捆綁成一個映像。因此，容器在開發中執行的方式與在QA和生產中執行的方式完全相同。容器是DevOps成功的關鍵因素。

此外，容器平臺正在進一步發展。典型的持續整合和交付（CICD）工具（如Jenkins）可用作在容器平臺本身上執行整個CICD過程的容器，而不需要額外的基礎設施。現在，你可以使用PaaS平臺構建和執行CICD管道。

微服務戰略

微服務是另一個熱門話題。將應用程式分解為分離的小型服務，每個小型服務都很好地完成一個小任務——這是應用程式的設計方式。每個微服務可以基於適合的技術以不同的語言編寫。它們將由小型團隊建立和管理，並且可以快速更改。所有這些要求再次指向容器。容器足夠小，是微服務的基礎。容器可以支援你選擇的任何技術和語言。它們易於建立和執行，並且可以快速更改。微服務和容器被認為已經結合了——如果人們談論在不使用容器的情況下實現微服務，這聽起來很奇怪。

事實上，雖然微服務承諾簡易性，但其擴散增加了複雜性。需要一些微服務設計和部署模式出現以簡化微服務的實施。這意味著開發人員現在需要一個平臺，讓他們可以輕鬆部署和協調這些微服務，並且：

1.以與語言無關的方式實現這些微服務的設計模式

2.不增加程式碼入侵的複雜性，使開發人員必須在其業務邏輯中包含大量的模式程式碼

3.有足夠的靈活性部署在你所選擇的基礎設施上，而不是把你繫結到特定的雲。

這就意味著選擇一個正確的容器平臺。以特定供應商的方式在特定基礎架構上實現這些微服務將使應用程式與這些供應商平臺相關聯。使用諸如符合OCI的容器的標準技術來容器化微服務，將確保你的微服務可以在任何符合OCI的平臺上執行。

選擇正確的容器平臺來執行微服務是另一個重要的決定。現在的選擇很少。而如果在做這個選擇時出現失誤，可能會走上非標準、供應商鎖定的道路。

雲戰略

雲戰略又是一個熱門話題。不管你喜歡還是不喜歡，“即服務”模式是一個不可避免的變化。如果你不通過IT提供這項服務，你的開發團隊可能會找到到達雲的方法。此外，雖然使用雲將使你從資本支出轉移到運營支出，但管理雲支出是一個不斷升級的挑戰。

雲提供虛擬機器。你會希望確保在啟動其他虛擬機器之前，最佳地使用此雲上的CPU、記憶體和網路資源。容器在這裡起著重要的作用。因為容器比VM小得多，並且如果你的應用程式在容器中執行，則可以在VM中安裝更多的容器，而不是為每個VM執行一個應用程式元件。

公有云供應商眾多，其中亞馬遜網路服務（AWS）、微軟Azure和谷歌雲是最受歡迎的。此外，你可能希望在基於OpenStack的資料中心中擁有自己的私有云。每個雲環境都有自己的協議、API和工具。當你希望應用程式在雲上執行時，你就不希望應用程式編排是雲供應商特定的，並且不想維護任何特定於雲的程式碼。被特定雲供應商鎖定就好比在未來幾年向供應商簽發空白支票一樣。

跨雲的可移植性對雲戰略至關重要。你可以編寫應用程式，而不必擔心它們在哪裡執行，容器平臺遮蔽了特定的雲供應商協議，防止你被一個雲供應商鎖定。

遺留系統

微服務架構帶來的好處很多，但不是每個應用程式都可以重構到微服務中，有些只能部分地重構。傳統應用程式遺留後，需要維護和管理。雖然容器支援微服務，但容器不僅僅是微服務。可以想象，你可以將大型應用程式和非微服務作為容器執行，因此只要你選擇正確的容器技術和正確的應用程式平臺，就可以執行許多（也許不是全部）的遺留應用程式作為容器。

小結

希望對各種策略和容器的解讀有助於企業評估下一步，也很期待大家的反饋，分享經驗教訓以及為什麼沒有采取行動。

本文轉自K8S技術社群