由于當(dāng)今大多數(shù)工作負(fù)載都運行在虛擬機(jī)或裸機(jī)上，因此云遷移變得復(fù)雜。這導(dǎo)致許多公司的工作負(fù)載面臨是否可遷移的問題。

[[284985]]

在2019年，越來越多的企業(yè)和組織正在評估本地數(shù)據(jù)中心(或私有云)中的現(xiàn)有工作負(fù)載應(yīng)如何遷移到公共云以及它們?nèi)绾卫霉苍品?wù)提供的許多好處。為了滿足要求，我們在公共云服務(wù)領(lǐng)域中扮演著重要角色：AWS、Azure和GCP。當(dāng)前，這些公共云公司提供的服務(wù)和利益對于運營數(shù)字業(yè)務(wù)至關(guān)重要，而后者要更多地關(guān)注用例，而不是對IT基礎(chǔ)設(shè)施架構(gòu)進(jìn)行投資。此類投資可以根據(jù)人力需求，也可以用于管理基礎(chǔ)設(shè)施的人工任務(wù)。

但是云遷移的路線并不像看起來那么簡單。正確的云遷移策略應(yīng)該到位。

云遷移風(fēng)險

遷移依賴于數(shù)據(jù)的應(yīng)用程序時，始終存在風(fēng)險。這些應(yīng)用程序移動應(yīng)該產(chǎn)生最小的影響。任何故障或停機(jī)都可能導(dǎo)致客戶失去對業(yè)務(wù)的關(guān)注。

在將應(yīng)用程序和相關(guān)數(shù)據(jù)移動到云中時，應(yīng)該有在新環(huán)境中測試應(yīng)用程序運行時的檢查點。云遷移變得復(fù)雜，因為當(dāng)今的大多數(shù)工作負(fù)載都在虛擬機(jī)或裸機(jī)上。這導(dǎo)致許多公司的工作負(fù)載可遷移性問題。然而，許多問題與應(yīng)用程序的可遷移性有關(guān)，并且數(shù)據(jù)可以通過公共云供應(yīng)商提供的現(xiàn)有服務(wù)來解決。

對于某些組織來說，云遷移策略是如何將敏感信息移動到云上。對于從醫(yī)療、金融等機(jī)構(gòu)收集專有和關(guān)鍵信息的大型組織來說，這一問題常常會出現(xiàn)。應(yīng)該有一個檢查點來評估GDPR等法律行為，以評估特定地區(qū)或國家的數(shù)據(jù)主權(quán)。

物聯(lián)網(wǎng)的用例正在迅速增長，這反過來又推動了對延遲敏感的基礎(chǔ)設(shè)施的需求。當(dāng)移動到云平臺時，一個問題可能會涉及到各種數(shù)據(jù)處理請求可能來自的位置的支持和距離。遷移到云平臺可能會對現(xiàn)有的一些應(yīng)用程序產(chǎn)生影響。對延遲敏感的應(yīng)用程序可能會在響應(yīng)時間上發(fā)生變化。

在物聯(lián)網(wǎng)用例中，可以選擇分布式云架構(gòu)。但是存在潛在的陷阱。如果將應(yīng)用程序移至公共云，則需要在代碼級別進(jìn)行修改以啟用分布式級別的支持。

另一個大問題是供應(yīng)商鎖定。轉(zhuǎn)移所有工作負(fù)載后，如果出于任何原因計劃遷移到另一個云選項，則可能會在應(yīng)用程序設(shè)置和數(shù)據(jù)服務(wù)方面鎖定供應(yīng)商。在遷移到云平臺時，這是一個很大的風(fēng)險，大多數(shù)企業(yè)必須評估測試用例。因此，建議先進(jìn)行少量的概念驗證(PoC)，然后再將所有工作負(fù)載遷移到云中。

容器化在云遷移中的作用

許多企業(yè)選擇在遷移到公共云之前或之后對工作負(fù)載和數(shù)據(jù)進(jìn)行容器化。他們中的一些人選擇了容器化微服務(wù)架構(gòu)，以幫助他們分別維護(hù)不同的子服務(wù)，并允許這些服務(wù)在主服務(wù)應(yīng)用程序中重用。

如果企業(yè)已經(jīng)將工作負(fù)載放在基于容器的系統(tǒng)上，并且已使用諸如Kubernetes或Docker引擎之類的容器編排引擎進(jìn)行了編排，則遷移到云中會變得非常容易。AWS和Azure云為Kubernetes以及其他引擎提供了特定的幫助，進(jìn)一步幫助了遷移過程。眾所周知，Kubernetes的主要特點是工作負(fù)載應(yīng)該是可遷移的，無論是任何類型的云平臺還是裸機(jī)。

總結(jié)

隨著時間的推移，由于組織可能希望轉(zhuǎn)向基于容器的基礎(chǔ)結(jié)構(gòu)，因此在遷移工作負(fù)載方面，云遷移已成為一項繁瑣的任務(wù)。但是，大多數(shù)挑戰(zhàn)已由公共云參與者解決。不過，停機(jī)時間或供應(yīng)商鎖定等問題仍然很關(guān)鍵。