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