陸志宏

趨勢(shì)一：云端工作負(fù)載在流程編排層實(shí)現(xiàn)自動(dòng)化

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

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

但問(wèn)題的關(guān)鍵是找到一個(gè)支持跨平臺(tái)戰(zhàn)略的集成點(diǎn)。

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

因此，企業(yè)開(kāi)始尋找一個(gè)在流程編排層之上的集成點(diǎn)，可以實(shí)現(xiàn)跨多個(gè)廠商平臺(tái)的自動(dòng)化部署。

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

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

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

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

趨勢(shì)二：企業(yè)正在轉(zhuǎn)向管理服務(wù)，以確?；旌显浦械膽?yīng)用性能

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

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

這些自動(dòng)化的、軟件驅(qū)動(dòng)的管理服務(wù)能夠?yàn)槠髽I(yè)提供他們非常需要的功能，例如：

一致的服務(wù)等級(jí)協(xié)議（SLA），無(wú)論工作負(fù)載的部署模式如何，是部署在公有云、私有云和供應(yīng)商云上，還是部署在本地；

無(wú)縫的工作負(fù)載轉(zhuǎn)移和自動(dòng)遷移；

跨用戶基礎(chǔ)和部署模型的治理、風(fēng)險(xiǎn)和合規(guī)性保證；

隱私設(shè)計(jì)。

看到了這些優(yōu)勢(shì)，如果你仍然還未考慮在混合云平臺(tái)上采用自動(dòng)化管理服務(wù)，那么在進(jìn)入2017年之前可要仔細(xì)想想了。

趨勢(shì)三：容器（Container）T具正在成為新的作為服務(wù)的平臺(tái)

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

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

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

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

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

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

趨勢(shì)四：網(wǎng)絡(luò)功能虛擬化是通向混合云理想狀態(tài)的路徑

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

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

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

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

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

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

趨勢(shì)五：NFV也正成為容器化的首選推動(dòng)者

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

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

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

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

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

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