主流技術(shù)企業(yè)構(gòu)建和思考IT解決方案的方式正在發(fā)生轉(zhuǎn)變。關(guān)注一下廠商的最新發(fā)布，就會發(fā)現(xiàn)其重點都是“集成”以及“互操作性”。管理服務(wù)提供商(MSP)和系統(tǒng)集成商本是各占山頭，當(dāng)他們決定成為伙伴而不是構(gòu)建自己的云服務(wù)的時候，就會變身成一個巨大的云提供商。從技術(shù)觀點或者是合同的角度來看，這里可能就會導(dǎo)致他們變成云鎖定的受害者。但是如果說團(tuán)隊可以在咨詢時候詢問得當(dāng)，作出正確的開發(fā)決定的話，云鎖定的威脅可能就會減緩。

如果我們不能花費(fèi)足夠的經(jīng)歷得出怎么會失去關(guān)聯(lián)，怎樣來遷移應(yīng)用和數(shù)據(jù)，數(shù)據(jù)構(gòu)成的形式以及誰擁有這些數(shù)據(jù)，這些數(shù)據(jù)存儲在哪里，云鎖定肯定就會不請自來。但是很多時候，我們在本地操作這些在進(jìn)入云環(huán)境的時候并沒有考慮的足夠多，也沒有咨詢得夠仔細(xì)。云集成商應(yīng)該主要關(guān)注兩類云鎖定：隱藏在契約或者服務(wù)水平協(xié)議(SLA)中鎖定;再者技術(shù)問題可能對于集成商來說很難，尤其是把應(yīng)用或者數(shù)據(jù)從一個云提供商遷移到期望中的另一個云提供商上。我們要明確的是云鎖定在我們熟悉環(huán)境的情況下說不定也不錯，但是這完全取決于場景。

下面我們搜集了一些資料，為云集成商和MSP最小化他們在結(jié)合的時候?qū)⒁媾R的困境：

1.評估云提供商財務(wù)是否正常。盡管這樣做似乎挺正常的，但是不要忽視檢查參考資料的需求，并確保所選擇的云服務(wù)提供商有資本可以繼續(xù)運(yùn)營。提供商要是陷入麻煩，他們可能會變賣控制權(quán)和資產(chǎn)。

2.確保提供商有完整的數(shù)據(jù)備份和災(zāi)難恢復(fù)計劃。這一點解決了云鎖定的一個不同類型，這種情況下，合作伙伴將用戶數(shù)據(jù)或者自己的數(shù)據(jù)放到云端，可能由于云提供商忽視保護(hù)自己的基礎(chǔ)設(shè)施導(dǎo)致他們再也看不到數(shù)據(jù)了。這個和第一點有一定的相關(guān)性，但是去年亞馬遜Web服務(wù)宕機(jī)的案例足夠讓我們警醒。在一些案例中，有些數(shù)據(jù)的丟失是永久性的。云計算畢竟不是完全成熟的技術(shù)。

3.理解數(shù)據(jù)遷移計劃。如果MSP或者云集成商決定讓其基礎(chǔ)設(shè)施隨處可需，那么使用數(shù)據(jù)將會變得多么容易。在很多例子中，可真不是這樣。云鎖定就涉及到這方面的內(nèi)容。云會導(dǎo)致鎖定，因為數(shù)據(jù)混合、存儲共享，存儲和備份數(shù)據(jù)的方式不同。有時候，遷移數(shù)據(jù)的流程可能要花費(fèi)的資金比MSP或者云集成商去另外一個云提供商那里重新開始做一遍都要多。這也正是我們?yōu)槭裁匆斫庠瓶梢浦残院瓦w移實施的重要性了，可能我們都需要在合同一開始就運(yùn)行一個測試來看看能不能輕松導(dǎo)出這些內(nèi)容。

4.研究合同要點。集成商和MSP對云要謹(jǐn)慎，必須理解如果業(yè)務(wù)需求合理變化時候，是否會在法律上破壞這份合同。比如說，你的客戶不在需要服務(wù)器或者一些功能了，是否可以以極少的罰金關(guān)閉呢?服務(wù)器上所使用的任何軟件的許可證歸誰所有?這些問題都是在遭遇云鎖定之前值得反復(fù)估量的。

5.避免直接開發(fā)云服務(wù)提供商專有的應(yīng)用程序接口(API)。簡單地將應(yīng)用遷移到云托管的服務(wù)器上并不是個問題，但是將應(yīng)用轉(zhuǎn)移到云托管的開發(fā)平臺可能就會造成問題了(像Azure、Google App Engine)。盡管直接開發(fā)具體的API可以獲得性能優(yōu)勢，但是集成商和MSP應(yīng)該考慮下假如他們要一個本地的解決方案的話，這樣的遷移如何實現(xiàn)。

上面這些問題是我們對于已有資料的搜索總結(jié)，可能在實際情況中，集成商和MSP會面臨更多的挑戰(zhàn)。但是至少從上面總結(jié)的內(nèi)容上，可以避免一些不必要的麻煩，少走一些彎路。