在新環(huán)境中抽象失敗是向云遷移過程中面臨的最大挑戰(zhàn)之一。通常，應(yīng)用程序的體系結(jié)構(gòu)取決于其下面的一些本地化API.這在大規(guī)模運(yùn)行的系統(tǒng)中特別常見，因?yàn)樘囟ǖ膯栴}只能在一定的規(guī)模中才能看得見。工程團(tuán)隊(duì)經(jīng)常使用一些類似黑客的程序和補(bǔ)丁來修復(fù)系統(tǒng)，但是黑客會(huì)在系統(tǒng)遷移過程中進(jìn)行攻擊。定期代碼審核在一定程度上有助于減輕這些問題。

2. 部署過程中的差異

所有的現(xiàn)代持續(xù)集成和持續(xù)交付（CI/CD平臺(tái)都支持多個(gè)云提供商，但這還不夠。具有復(fù)雜設(shè)置和啟動(dòng)過程的應(yīng)用程序通常需要人工干預(yù)部署。近幾年來，這一點(diǎn)通過使用Puppet，Chef和Ansible等工具在很大程度上可以實(shí)現(xiàn)自動(dòng)化。但是這種自動(dòng)化通常與供應(yīng)商特定的API聯(lián)系在一起，這些API需要配置，監(jiān)控和拆卸服務(wù)器。但是，除非工程團(tuán)隊(duì)花時(shí)間自己構(gòu)建，否則這些API不適合小型的本地?cái)?shù)據(jù)中心。

3. 重新架構(gòu)

現(xiàn)代應(yīng)用程序分布在多個(gè)不同區(qū)域的多個(gè)數(shù)據(jù)中心。這是遷移到基于云計(jì)算的部署的主要好處之一。企業(yè)正在逐漸從單一的應(yīng)用程序基礎(chǔ)轉(zhuǎn)變?yōu)榛谖⒎?wù)的方法。一個(gè)本地?cái)?shù)據(jù)中心遷移到多地點(diǎn)部署需要適當(dāng)?shù)刂匦聵?gòu)建應(yīng)用程序。這意味著除了開發(fā)新版本之外，工程團(tuán)隊(duì)還必須關(guān)心現(xiàn)有的安裝情況。遷移系統(tǒng)的關(guān)鍵部分經(jīng)常會(huì)導(dǎo)致停機(jī)，新的部署仍然不能保證在首次運(yùn)行中取得成功。建議在出現(xiàn)問題時(shí)對(duì)原有部署進(jìn)行故障切換，以防出錯(cuò)。大型遷移可能需要幾個(gè)月的時(shí)間才能完成，并可能需要額外的員工來完成。

4. 傳輸大量的數(shù)據(jù)

想象一下，必須將移動(dòng)社交應(yīng)用Instagram的業(yè)務(wù)從AWS云平臺(tái)遷移到微軟Azure云平臺(tái)上。傳輸這些海量的圖像本身就是一項(xiàng)艱巨的任務(wù)。認(rèn)為有時(shí)最好的措施是物理運(yùn)送數(shù)據(jù)，而不是將數(shù)據(jù)上傳到云計(jì)算提供商，這種行為并不瘋狂。這兩種策略都經(jīng)過多年的分析，行業(yè)仍然沒有確定哪個(gè)策略才是正確的做法。這個(gè)問題不是取決于正在遷移的系統(tǒng)的類型，因此不能通過僅僅改變架構(gòu)來緩解。一些企業(yè)從一開始就選擇使用云存儲(chǔ)，即使涉及到基于本地?cái)?shù)據(jù)中心的部署。當(dāng)數(shù)據(jù)不太活躍或者不需要立即處理時(shí)，這種方法特別普遍。Amazon S3存儲(chǔ)已經(jīng)成為許多企業(yè)多年來的可靠存儲(chǔ)解決方案，并且一直是這一領(lǐng)域的領(lǐng)跑者。

如今的許多企業(yè)都喜歡快速收購和出售市場(chǎng)型的初創(chuàng)公司。遷移到云端或從一個(gè)提供商轉(zhuǎn)換到另一個(gè)提供商是這類業(yè)務(wù)的非常普遍的任務(wù)。通常情況下，需要使用當(dāng)前的一套應(yīng)用程序來制作新獲得的應(yīng)用程序。有時(shí)，新產(chǎn)品轉(zhuǎn)移到新的云計(jì)算提供商或從云端遷移到自我托管的設(shè)置，以利用已經(jīng)購買的合同或硬件，就像Instagram遷移到Facebook的數(shù)據(jù)中心，這實(shí)質(zhì)上形成了Facebook的私有云平臺(tái)。

無論是什么原因，遷移到基于云計(jì)算的系統(tǒng)是許多組織的必要條件。最好是以一種與供應(yīng)商無關(guān)的方式編寫應(yīng)用程序，并在適當(dāng)?shù)牡胤竭M(jìn)行適當(dāng)?shù)某橄?，以便縮短可能長(zhǎng)達(dá)幾個(gè)月的考驗(yàn)過程。