現(xiàn)如今，云服務(wù)主要集中在流程編排層的自動化。但客戶需求不斷發(fā)展，我們的客戶越來越多地想將自動化置于編排層之上。他們希望跨所有云基礎(chǔ)架構(gòu)自動執(zhí)行整個應(yīng)用程序的部署過程。

　　擁有一個部署云端應(yīng)用的自動化架構(gòu)可加快初始部署和持續(xù)進行的DevOps集成速度。這不僅使應(yīng)用程序管理更容易，而且還加快了應(yīng)用程序所有者的業(yè)務(wù)目標(biāo)的交付。

　　但問題的關(guān)鍵是找到一個支持跨平臺戰(zhàn)略的集成點。

　　一些客戶轉(zhuǎn)向OpenStack希望尋找到答案，但他們很快就意識到，在OpenStack內(nèi)部或是其自身都并不能真正實現(xiàn)這些目標(biāo)。由于OpenStack部署的獨特性，它不支持單組應(yīng)用程序編程接口（API）的交叉部署。因此客戶不得不去部署特定腳本和工具集，從而放棄轉(zhuǎn)向一個通用API的努力。

　　因此，企業(yè)開始尋找一個在流程編排層之上的集成點，可以實現(xiàn)跨多個廠商平臺的自動化部署。

　　有些客戶在使用例如LibCloud庫這樣的抽象DevOps工具集，無需創(chuàng)建自己的額外API庫就能在表層上被應(yīng)用部署在其他環(huán)境中。這讓你可以基于業(yè)務(wù)需要（比如地理位置和服務(wù)等級協(xié)議）來選擇云環(huán)境，同時有機會利用其他的云進行未來部署。這樣也降低了供應(yīng)商鎖定的風(fēng)險。

　　然而，重要的是要了解諸如LibCloud、Terraform、Ansible、StackStorm、Chef和Puppet之類的工具集背后的機制，正是這些機制使它們呈現(xiàn)出差異化特點，看看哪一個能夠最好地滿足應(yīng)用程序的真實業(yè)務(wù)需求。

　　為基于公有云、私有云和混合云的開發(fā)團隊提供自助服務(wù)和自動化是必須的，而不是可選項。那些在自動化服務(wù)方面部署較慢的企業(yè)將會發(fā)現(xiàn)他們的開發(fā)團隊也將落后于人。

　　可編程網(wǎng)絡(luò)也是混合云的強大驅(qū)動力，使你能夠更快地推出新的運營網(wǎng)站。而以前，你需要購買設(shè)備，在某個地方對其進行配置，把它應(yīng)用在新的網(wǎng)站中，同時你還需要一個精湛的工程師來安裝它。現(xiàn)在，使用通用可編程設(shè)備和云端應(yīng)用程序，你就可以按照自己的方式進行模板化。你可以使用一個簡單的設(shè)備，將其置于云端，并請一位水平一般的工程師來安裝設(shè)備和分支軟件，所有的這些都在云端完成。

　　無論工作負載之下的基礎(chǔ)架構(gòu)如何，每個人都希望獲得持續(xù)在線的應(yīng)用體驗。公司越來越多地使用混合云作為管理服務(wù)平臺來實現(xiàn)這一目標(biāo)。

　　隨著云越來越多地被采用，行業(yè)正在從配置基礎(chǔ)架構(gòu)的單一自助服務(wù)門戶，轉(zhuǎn)向完全基于軟件的管理服務(wù)平臺。

　　這些自動化的、軟件驅(qū)動的管理服務(wù)能夠為企業(yè)提供他們非常需要的功能，例如：

　　當(dāng)Docker于2013年推出時，虛擬化開始從機器級別轉(zhuǎn)移到應(yīng)用程序級別。

　　作為可在軟件容器內(nèi)自動進行應(yīng)用部署的開源項目，Docker讓應(yīng)用程序在混合云和本地基礎(chǔ)架構(gòu)之間更具有可移植性。

　　這一開源容器集群管理器最初由谷歌設(shè)計，通過與Kubernetes相結(jié)合，它快速替代了市場上的Heroku云作為服務(wù)平臺的產(chǎn)品。

　　在2017年，我們將看到容器受到更廣泛的采用，但是完全過渡到容器化（containerised）的世界仍需要幾年時間。在初始階段，我們將看到使用Kubernetes作為部署復(fù)雜工作負載模型的趨勢。

　　由于公有云平臺之間對Docker的支持是可變的，企業(yè)們可能不愿意在多個云之間使用Docker。他們很可能會在單一的云平臺上使用它，并結(jié)合他們本地部署來實現(xiàn)混合。

　　當(dāng)采用Docker和Kubernetes（或類似的管理器）時，企業(yè)們應(yīng)確保他們在映像管理、網(wǎng)絡(luò)訪問和安全補丁、服務(wù)發(fā)現(xiàn)和容器監(jiān)視方面擁有一個明確的策略。

　　混合云的理想狀態(tài)是這樣的：服務(wù)的一部分運行在自己的數(shù)據(jù)中心當(dāng)中，第二部分運行在公有云提供商A上，其余部分在公有云提供商B上�；�于性能、可用性、隱私或成本的考慮，你可以自由決定服務(wù)的任意組成部分運行在什么地方。

　　我們尚未實現(xiàn)這種理想狀態(tài)的主要原因之一是這些混合域中的網(wǎng)絡(luò)元素必須被綁定在一起。

　　首先，答案被認為存在于軟件定義網(wǎng)絡(luò)（SDN）中。一些企業(yè)試圖使用SDN來使得他們的混合云環(huán)境重組，但后來發(fā)現(xiàn)SDN非常復(fù)雜。因此這仍然是大多數(shù)企業(yè)尚未克服的障礙。

　　相比之下，與之相關(guān)但又存在細微差別的網(wǎng)絡(luò)功能虛擬化（NFV）有望成為連接混合云和混合IT環(huán)境的更簡單方式。NFV是將諸如防火墻、負載平衡和入侵防御系統(tǒng)之類的服務(wù)，從專用硬件移動到虛擬化環(huán)境（例如虛擬設(shè)備）中的過程。

　　NFV的優(yōu)點之一是，它所使用的虛擬網(wǎng)絡(luò)和安全設(shè)備允許你在連接網(wǎng)絡(luò)時保持對IP尋址、DNS和路由選擇的控制。它們允許你將云端作為自己網(wǎng)絡(luò)的擴展，使用你所熟悉的網(wǎng)絡(luò)技術(shù)、工具和供應(yīng)商。

　　這就是為什么在基于云的現(xiàn)實網(wǎng)絡(luò)中我們對NFV更感興趣，并希望通過混合云構(gòu)建新的網(wǎng)絡(luò)系統(tǒng)。

　　容器網(wǎng)絡(luò)與傳統(tǒng)網(wǎng)絡(luò)不同。容器是非常動態(tài)且短暫的，導(dǎo)致了很多不可預(yù)測的流量。

　　當(dāng)容器被啟動時，我們需要在某個目錄中注冊它；當(dāng)它停止運行時，我們需要讓大家都知道。這是通過運行在控制臺的服務(wù)發(fā)現(xiàn)層和進程來完成的，使用了例如CoreOS或Apache ZooKeeper之類的工具。

　　Kubernetes網(wǎng)絡(luò)模型要求容器可以與網(wǎng)絡(luò)節(jié)點以及另一個容器直接進行通信，容器將自己視為與其他人所看到的相同的IP。在Kubernetes中，IP地址范圍是一個pod：一個pod中的所有容器共享相同的IP地址，并且必須使用本地主機結(jié)構(gòu)來相互進行通信。

　　現(xiàn)在有許多方法可以解決這些容器化網(wǎng)絡(luò)的挑戰(zhàn)：從Docker網(wǎng)絡(luò)選項到以容器為中心的選項，再到SDN和NFV。

　　然而，如果我們認為相比于混合部署，一個尚未開發(fā)的Docker部署更加不可能實現(xiàn)，那么就可以歸納出一個簡單的命題：如果容器與現(xiàn)有VM實現(xiàn)并行運行，NFV方法最有可能成功地解決容器化網(wǎng)絡(luò)挑戰(zhàn)。

　　我們相信，技術(shù)是釋放業(yè)務(wù)和全世界潛力的關(guān)鍵，我們剛剛開始了解通過何種方式才能實現(xiàn)。憑借在混合云、數(shù)字基礎(chǔ)架構(gòu)、未來工作空間和網(wǎng)絡(luò)安全領(lǐng)域應(yīng)用我們的專長，我們期待2017年繼續(xù)幫助我們的客戶加速實現(xiàn)其業(yè)務(wù)的數(shù)字化。