大約每隔10年左右，整個數據中心業界就會開始關注下一個大的抽象化概念，這一新的抽象化概念將激發出令人振奮的新服務器操作系統的形式因素。正如Redmonk公司的分析師Stephen O'Grady在他的一篇題為《抽象之路( The Road to Abstraction)》的博文中所說的那樣：“計算機是很難的，這就是為什么說整個技術行業歷史上的長期趨勢之一便是抽象化并不奇怪的原因所在了。“
有了容器集裝箱技術，數據中心業界的一個普遍的共識就是：最新的抽象單位正式到來，并將要開始取代虛擬機了。企業開發人員們現在更喜歡采用容器來打包應用程序(根據市場調研機構451 Research公司的報告顯示，到2020年，這一市場規模將達到27億美元)。而這對于數據中心運營商們需要如何支持這些應用程序及開發人員的創建工作將具有深遠的影響。但是，與虛擬化技術的最后一個主要抽象轉換相比，今天整個業界對于容器集裝箱技術的采用曲線其實存在著很大的差異。
下面，讓我們大家一起來看看當下廣泛采用的容器集裝箱技術對數據中心運營商們所帶來的影響吧，同時，我們還將探討我們當前在該技術方面處于怎樣的水平，以及我們從以前的朝著虛擬化技術轉向的趨勢中所學到的經驗教訓。
為什么開發人員們開始青睞容器集裝箱技術?
容器集裝箱技術的普及采用可以說是開發人員們朝著數據中心運營商們發起的“反叛起義”。而影子IT則是這次“反叛起義”的第一次迭代，由于此前需要花費幾周的時間才能在企業內部配置好虛擬機，迫使開發人員們直接轉向采用亞馬遜網絡服務(AWS)，并直接使用信用卡支付來獲取服務器資源。
現在，容器集裝箱技術允許開發人員們實現更快地遷移。因為即使在AWS上，采用一臺虛擬機也需要幾分鐘的時間，而容器集裝箱則僅僅只需要幾毫秒的時間。隨著企業組織越來越傾向于優先考慮更快地發布新產品和功能，以便能夠跟上當下這個軟件消費的世界的大趨勢，開發人員傾向于采用那些允許他們能夠比公共云和私有云服務可支持的傳統虛擬機更快地擴展應用程序和部署資源的技術。而諸如Twitter和Netflix以及其他規模化網絡公司(其應用程序和平臺團隊具有基礎設施自主權)的開發人員模式，已經開始將容器集裝箱技術作為提升靈活敏捷方法的最佳實踐方案(將能夠幫助任何開發團隊真正實現“快速的遷移”)，并將其納入主流了。
更進一步分析，我們可以看到：較之虛擬機，容器集裝箱技術具有各種成本和性能優勢，這有助于解釋該技術在當下流行的原因所在了。其第一個主要的益處便是：能夠在同一臺服務器上運行多款應用程序或操作系統，無需虛擬機管理程序，進而消除了系統資源管理程序的阻力，所以您企業的工作負載可以有一個較輕的足跡——容器足跡為零，因為其在Linux系統中只是一個邊界的權限和資源。
與虛擬機相比，容器集裝箱的啟動和關閉非常快速——完美契合企業組織當下短暫的工作負載的短暫性質，因為這些工作往往是現實世界中的事件，并和“突發性”相關聯。最后但并非最不重要的是，鑒于具備更多的靈活性，可以在不同的云服務供應商和操作系統上部署應用程序，使得容器集裝箱對于操作系統的依賴關系越來越少，進而起到了使得這些應用程序避免被企業組織的目標鎖定的的作用。當然，還沒有VMware軟件許可證費用。畢竟，這一軟件許可證費用對于任何主要數據中心而言，都會大大增加其運營費用成本。
但是，這一優勢并未像虛擬機那樣發揮出來
容器集裝箱規則的特征之一是沒有規則。一大現實案例便是Docker容器模式已經在市場上贏了。但隨之而來的技術選擇和豐富的快速開源平臺比比皆是。您企業可以使用任何您所希望的Linux模式。您可以選擇快速發展的容器orchestration業務流程平臺，如Kubernetes、Mesosphere DC / OS和Docker Swarm。
即使是在當下的容器集裝箱模式級別(假定Docker已經贏得了市場)，現在也面臨一種更開放的標準容器模式的挑戰。因此，數據中心運營商們會很快發現自己陷入了更深層次的問題，這些問題很多是尚未標準化的問題：包括配置容器存儲和網絡化，以及對運行中的容器的洞察，這些問題與運營商們曾希望借助虛擬機技術的采用所達到的成熟度相當。
其真正的原因可以歸結為企業現在實施容器集裝箱的能力還相當不均勻，包括系統成熟度方面的，也有用戶意識方面的原因。
容器集裝箱的世界沒有VMware。基本上，Docker是最接近通用品牌的容器集裝箱了，但Docker遠不及VMware在虛擬機發展的早期所具備的技術鎖定。一方面，容器集裝箱技術的早期采用者們有很多的選擇和靈活性，但也意味著它們必須是自己的系統集成商，并將許多這些工具集成在一起。
從1997年至2002年期間，VMware大概花費了五年的時間圍繞著虛擬機技術創造了一個市場。在這五年的時間里，他們可以說是這一市場唯一的玩家，并有一段時間，通過打造像VMotion技術，VRS資源平衡等等方式來建立起了企業級的護欄，來進一步封閉了該技術。
而在另一方面，Docker幾乎立即開源了其圍繞著容器集裝箱的核心技術。紅帽、Canonical、Mirantis以及幾乎每家主要的開源供應商都在商業上得到支持。所以盡管Docker是第一個推動者，但是他們失去了控制權。許多人會認為，他們花了太長時間來強調orchestration業務流程，這就是為什么他們在Swarm采用大潮流中遠遠落在了Kubernetes和Mesosphere DC / OS之后的原因所在了，盡管他們原本在容器模式方面擁有巨大的先發優勢。
今天的容器集裝箱產品生態系統是數十年來我們在數據中心領域所看到的最大的地雷之一，無數供應廠商爭相擁有現代應用程序“堆棧”的各個部分。但隨著可選擇的開放源代碼平臺的大量開發，數據中心運營商也面臨著挑戰，需要選擇合適的技術，并實現高度定制化的整合。如果您企業是像Netflix，Ebay或PayPal這樣的網絡規模化巨頭，并且具備足夠的工程師，那么采用容器的經濟性是有道理的。但對于需要可預測結果的市場上的其余企業而言，這可能相當危險。
今天，我們在容器集裝箱技術的采用確切的處于什么水平?
SHOW FULLSCREEN
資料來源： Google Trends
沒有人會對容器集裝箱的重要性提出異議。在過去三年中，Docker本身登上頭條新聞的次數已經呈直線上升趨勢，而Kubernetes也正在開始引發業界的廣泛興趣逐漸達到臨界，由上圖中的Google Trends即可看出。
但企業在實際生產過程中對于容器集裝箱的采用究竟在何處呢?雖然我相信容器集裝箱所帶來的正面積極效應是如此令人興奮，企業將持續推動，直到該技術的采用變得無所不在，但我聽到和看到的是，集裝箱技術通常仍然停留在第一檔，其受歡迎程度仍更多地局限于開發人員的筆記本電腦，而幾乎沒有用于主流企業生產部署的用例。
今天的容器集裝箱技術：好的方面
從我的觀點看來，今天的容器集裝箱對于企業的吸引力主要包括：
面向消費者的服務轉移到容器集裝箱化的DevOps工作流程(更廣泛的生產實例包括Viacom、Bloomberg和Ticketmaster等大品牌)。
借助狀態應用程序和數據庫進行實時分析(Verizon、Google、Apple和Uber便是其中記錄其案例研究中的大品牌企業)。
容器集裝箱可實現從微服務到數據庫的端到端自動化DevOps。
今天的容器集裝箱技術：壞的方面
在這一技術朝著主流方向推動的過程中，我認為也有兩大主要障礙繼續存在：
容器集裝箱自身不穩定的技術基礎：太多的業務流程、網絡、存儲、安全選項。無限排列。對于大多數典型的企業(并非所有企業全都是Google或Facebook這樣的網絡規模化的企業)都不能支持。今天的容器集裝箱技術，將需要在這個問題上消耗大量的人力物力，需要更多的工具和支持才能取得成功。
數據庫和分析引擎：容器集裝箱系統一直在努力滿足持久存儲的需求，自動擴展以跟上微服務，性能和延遲，以滿足業務的預期。在這個方面上大量的投錢是典型的答案，這導致了過度配置的問題。
雖然您可以使用容器集裝箱技術，并在虛擬機上運行，以利用現有的基礎設施，但我們所看到的是，今天的終端用戶(在沒有成熟的容器特定生產工具的情況下)正在經歷這兩個世界的最差體驗——容器技術工具的復雜性和虛擬機的大開銷。嘗試這樣做的企業通常會以如下兩種方式之一：
簡單模型：每臺虛擬機一個容器
易于開始。每個容器都安裝單一的網絡和存儲(VM!)。現有的工具在某一點上起作用。
但是，在經歷了短暫的時間后，卻會變得非常痛苦和昂貴。虛擬機蔓延。高度浪費/間接費用開銷龐大。存儲和網絡管理是依賴于管理程序的舊的/慢的/昂貴的模型。這種方法在開發環境與操作環境之間造成了重大的脫節。
高級模型：每臺虛擬機多個容器
創建了直接暴露于容器的不同的網絡/存儲模型。虛擬機的抽象無法解決這些問題。
最有可能的是，您企業將傳統IT模型的新容器堆棧分層，而這正是開發人員將其遷往公共云服務的重點原因。
數據中心運營商的結論
在本周的CoreOS Fest上，Ticketmaster平臺的高級副總裁分享了他們早期主要的容器集裝箱生產用戶常見的問題，當時他說：“我們實際上并不想再建立更多的軟件，那些是我們不需要維護的東西，我們寫的每一塊軟件都應該是商品，這是我們永遠擁有的技術債務。“
容器的早期路徑是DIY，極端定制和技術債務之一。對于太多看到容器上升態勢太快，而不能再觀望的企業組織而言，我想提供一些關鍵性的建議來降低風險：
1、為您的客戶(開發人員)提供他們所需要的：容器本機，整個應用程序的自動化體驗，可輕松擴展和管理。
2、選擇開源方法，減少鎖定并提供多種支持選項。目前，開放性最好的“堆棧”組件包括Kubernetes，用于Linux的開放API(網絡、存儲，以便您企業可以在不同的云基礎設施上部署應用程序)、CNI和Flex Volume。
不要等待解決方案成熟，屆時就太遲了。Dev開發將在公共云端，而ops運維將成為新的大型機，逐漸萎縮。使用開放API構建適度的容器集群并不需要大量投資，這對大多數企業組織來說都是正確的起點。
京公網安備 11010502049343號