誰來解決應(yīng)用跨云平臺難題？

隨著移動互聯(lián)網(wǎng)、云計(jì)算、大數(shù)據(jù)等技術(shù)的深化應(yīng)用和交叉融合，不僅企業(yè)的IT應(yīng)用和管理模式發(fā)生了變化，員工的工作、生活也在隨之改變。原來裝在本地環(huán)境的軟件現(xiàn)在變成了一個個服務(wù)；以往企業(yè)的IT部門需要承擔(dān)繁重的系統(tǒng)和網(wǎng)絡(luò)運(yùn)維工作，現(xiàn)在云計(jì)算服務(wù)商將它們解放了出來。Cloud的靈活性和可擴(kuò)展性使得以前的不可能變?yōu)榭赡?，徹底轉(zhuǎn)變了用戶的業(yè)務(wù)運(yùn)營模式。

然而，傳統(tǒng)企業(yè)的云計(jì)算之路并非一帆風(fēng)順。當(dāng)前的最主要障礙之一是，在國內(nèi)云計(jì)算基礎(chǔ)設(shè)施（IaaS）與云計(jì)算軟件服務(wù)（SaaS）之間，缺乏了一個通用性的服務(wù)平臺（PaaS或CaaS）。以至頂網(wǎng)剛剛完成的主流云計(jì)算廠商網(wǎng)絡(luò)應(yīng)用性能測試（http://net.zhiding.cn/network_security_zone/2017/1109/3100268.shtml）為例：在測試初期，原本計(jì)劃是采用專業(yè)的網(wǎng)絡(luò)應(yīng)用性能測試儀表來完成本次測試工作，但是，在經(jīng)過近一個月的嘗試之后，最后還是放棄了這個想法而采用Linux上的小測試工具來進(jìn)行測試。

不能輕視的對接問題

為什么會出現(xiàn)這種情況？最主要的原因就是缺乏一個通用的接口服務(wù)平臺在測試軟件和不同公有云基礎(chǔ)設(shè)施間進(jìn)行對接。當(dāng)前的云計(jì)算基礎(chǔ)設(shè)施技術(shù)發(fā)展，還沒有成熟到出現(xiàn)一個統(tǒng)一的技術(shù)標(biāo)準(zhǔn)，各個云計(jì)算廠商均是按照自身對云計(jì)算技術(shù)的理解，來打造自己的云計(jì)算基礎(chǔ)設(shè)施產(chǎn)品，并在各有自身特色的云計(jì)算基礎(chǔ)設(shè)施之上開發(fā)自己的服務(wù)中間件接口，然后在上面搭建各種軟件應(yīng)用系統(tǒng)。這樣的應(yīng)用系統(tǒng)，首先滿足的也是廠商自身的云計(jì)算應(yīng)用需求。這也是當(dāng)前主流云計(jì)算廠商均是主流互聯(lián)網(wǎng)廠商的主要原因之一。

但這為傳統(tǒng)企業(yè)的云轉(zhuǎn)型帶來了很大的阻礙。以前，傳統(tǒng)企業(yè)的整個IT系統(tǒng)基本上都是構(gòu)建在物理服務(wù)器上面的，網(wǎng)絡(luò)、計(jì)算、存儲都是標(biāo)準(zhǔn)接口的硬件產(chǎn)品。一套硬件構(gòu)建一個基礎(chǔ)架構(gòu)，滿足某些特定企業(yè)應(yīng)用，這些應(yīng)用基本上是不同年份、不同環(huán)境開發(fā)出來的，Windows、UNIX、Linux各種類型應(yīng)用可能會并存，而且有很多還是企業(yè)的核心應(yīng)用，是企業(yè)開展業(yè)務(wù)的重要依賴，其對可靠性、安全性的要求也非常的高。

這些企業(yè)IT系統(tǒng)如果要向云計(jì)算遷移，就會產(chǎn)生一個傳統(tǒng)IT系統(tǒng)物理端口與云計(jì)算虛擬端口進(jìn)行對接問題：各大云計(jì)算廠商所提供的網(wǎng)絡(luò)資源接口、存儲資源接口、計(jì)算資源接口各有不同，需要如何去一一進(jìn)行適配？適配后如果感到應(yīng)用效果不理想，需要再次進(jìn)行遷移時，這些適配工作是否要再重新進(jìn)行一次，所需要付出的工人成本、時間成本、業(yè)務(wù)穩(wěn)定性問題要如何解決？而且從上次云主機(jī)網(wǎng)絡(luò)應(yīng)用測試結(jié)果來看，不同云計(jì)算廠商所提供的云計(jì)算產(chǎn)品應(yīng)用側(cè)重點(diǎn)也各不相同。這樣的話，未來企業(yè)IT系統(tǒng)還需要考慮如何在不同云計(jì)算系統(tǒng)上進(jìn)行部署，適配任務(wù)會更加繁重。

如何彌補(bǔ)這缺失的一環(huán)

目前國內(nèi)云計(jì)算廠商已經(jīng)開始對此類對接問題產(chǎn)生重視，并且也正在試圖通過Docker、微服務(wù)、云計(jì)算物理主機(jī)，以及對多種不同存儲、數(shù)據(jù)庫的支持，解決這類問題。但是“通用性”的問題依然無法解決，而且對于云計(jì)算廠商而言，也不會有解決這方面問題的動力。畢竟作為廠商而言，肯定會希望通過各種方式將用戶留住，而不是向競爭對手那里進(jìn)行流失。

從當(dāng)前的情況來看，要解決云計(jì)算應(yīng)用的PaaS層通用性問題，有一條路就是依賴一個強(qiáng)有力的第三方服務(wù)商，讓他們在不同云計(jì)算廠商的IaaS平臺上，搭建出一個標(biāo)準(zhǔn)的、具有通用性的PaaS接口，讓用戶的上層應(yīng)用可以如同在物理服務(wù)器上部署一樣在不同的公有云、私有云上任意部署。

這個想法很好，但是有實(shí)力進(jìn)行通用性PaaS接口開發(fā)的企業(yè)，通常也會推出自身的公有云或私有云產(chǎn)品，有了這些產(chǎn)品后，通用性就又會再次成為問題……

還好，這個問題現(xiàn)在已經(jīng)看到了答案，這就是容器技術(shù)：將傳統(tǒng)企業(yè)打包進(jìn)容器，然后部署到云環(huán)境不失為一種解決辦法。其實(shí)，容器不僅是解決不同私有云平臺，同時也是解決跨不同云平臺問題的有效解決辦法。

不過之前由于容器底層的調(diào)度平臺存在K8S與Mesos、Swarm三強(qiáng)之爭，給企業(yè)的選項(xiàng)帶來了困擾，好在如今這三強(qiáng)之爭已經(jīng)結(jié)束，目前K8S主導(dǎo)PaaS平臺基本已成定局。實(shí)際上，不少此前通過提供不同Docker調(diào)度引擎的各種服務(wù)商（比如Rancher）如今已經(jīng)轉(zhuǎn)移到K8S技術(shù)路線上了，同時，過去一直猶豫的一些廠商也終于選擇了這條路。

不過，光有Docker+K8S距離商業(yè)應(yīng)用還有不少距離，比如，在管理和監(jiān)控方面，特別是多集群的管理方面都還存在有不少不做，這就給了一些CaaS平臺供應(yīng)商以機(jī)會。實(shí)際上，CaaS眼下是如此之熱，算得上是企業(yè)級市場的一個風(fēng)口。

順便一提的是，曾經(jīng)的應(yīng)用虛擬化技術(shù)在一定程度上也可以達(dá)到這個目的：由于應(yīng)用完全運(yùn)行在后臺服務(wù)器上，所以它在一定程度上也可以實(shí)現(xiàn)應(yīng)用跨平臺。不過，這種技術(shù)更像是“野路子”，它的原本是要解決安全問題（應(yīng)用和數(shù)據(jù)不落地），跨平臺只是它的“副作用”。如今，在云環(huán)境中這項(xiàng)技術(shù)找到了新的存在價值。據(jù)悉，思杰已經(jīng)提供了一個XenAPP工具套件，作為幫企業(yè)云化的一個伙伴或者說一個推手，助力企業(yè)的應(yīng)用向云計(jì)算進(jìn)行遷移。

生成海報

免責(zé)聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準(zhǔn)確性及可靠性，但不保證有關(guān)資料的準(zhǔn)確性及可靠性，讀者在使用前請進(jìn)一步核實(shí)，并對任何自主決定的行為負(fù)責(zé)。本網(wǎng)站對有關(guān)資料所引致的錯誤、不確或遺漏，概不負(fù)任何法律責(zé)任。任何單位或個人認(rèn)為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識產(chǎn)權(quán)或存在不實(shí)內(nèi)容時，應(yīng)及時向本網(wǎng)站提出書面權(quán)利通知或不實(shí)情況說明，并提供身份證明、權(quán)屬證明及詳細(xì)侵權(quán)或不實(shí)情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關(guān)文章源頭核實(shí)，溝通刪除相關(guān)內(nèi)容或斷開相關(guān)鏈接。