一旦企業承諾在雲中執行關鍵業務應用程式,他們就很少求助於其他提供商,這也是他們經常被鎖定在他們選擇的供應商生態系統中的重要原因之一。 Gartner 雲服務和技術副總裁 Sid Nag 表示,遷移成本實在是太高了。 “但是,如果你的規劃正確,你就不必遷移你的應用程式。 ”
專業服務公司 Globant 的雲運營和網路安全工作室合夥人 Pablo del Giudice 補充說,如果您正確定位您的組織,遷移是可能的。 他和他的團隊已經成功地做到了這一點。 “關鍵是戰略性地採用開放平台和框架,將雲提供商降級為基礎設施層的角色,”他說。 他說,雖然這種方法具有更陡峭的習曲線,但它將在中長期內產生更有利的結果。 “關鍵是要引入乙個平台中立的軟體架構師,他可以劃定業務邊界,並建立與特定供應商糾纏較少的解決方案。 ”
美國專利商標局(USPTO)的首席資訊官傑公尺·霍爾科姆(Jamie Holcombe)的觀點稍微偏向於此:他希望保留在雲服務提供商之間移動應用程式的選擇權,並與所有主要提供商進行市場研究。 但要做到這一點,你需要在首次將應用遷移到雲之前提前計畫。
將鎖定風險降至最低
在利用每個供應商的雲原生服務時,您需要仔細權衡利弊。 “如果你選擇不使用雲提供商的原生服務來確保你是'雲不可知論者',你就會錯過很多'更好、更便宜、更快'的商業案例指標,”Holcombe說。 因此,這是有代價的,就像供應商鎖定是有代價的一樣。 ”
Jamie Holcombe,美國專利商標局首席資訊官。
Del Giudice 將雲供應商鎖定分為三種形式。 當您擁有完整的雲基礎架構配置(資源分組、策略、RBAC、混合連線、監視、合規性等)時,就會發生平台鎖定,並且在新平台上重新建立所有這些配置的複雜性使得遷移到另乙個平台變得困難。
架構鎖定是指應用程式依賴於來自雲提供商的多個託管服務。 在這種情況下,必須先重新生成應用,然後才能遷移它。
然後是法律鎖定,即您在預定的時間段內承諾簽訂企業服務協議。 “這些承諾很難結束,使得執行遷移變得非常困難,”他說。 ”
有時,儘管首席資訊官盡了最大努力避免供應商鎖定,但供應商鎖定還是會發生。 根據 NAG 的說法,合併和收購通常會使組織擁有多雲架構,雖然 CIO 經常想要整合,但成本往往太高而無法證明其合理性。 大多數時候,這些首席資訊官決定保留多雲模型,因為他們被鎖定了。 “你被困住了,它太大了。 ”
Del Giudice表示,儘管存在障礙,但組織可能有充分的理由在IaaS提供商之間遷移。 最常見的是在價值和運營支出之間獲得更好的成本比,以利用競爭雲服務提供商的大幅折扣,並在組織想要提高可靠性時利用多雲架構。
提前規劃未來可能發生的遷移
然而,NAG表示,在雲提供商之間遷移關鍵應用程式的願望(Gartner稱之為“雲遣返”)通常是規劃不善的結果,例如在遷移到雲的過程中,或者當組織決定使用負擔得起的雲原生中介軟體和開發工具在完成後將應用程式遷移回本地私有雲時。
Sid Nag,Gartner 雲服務和技術副總裁。
他建議保留 MSP 或系統整合商的服務來規劃並確保選擇正確的應用程式以遷移到雲。 “這很重要,因為一旦你移動了應用程式,你就同意被鎖定在這個平台上。 ”
金融服務公司 USAA 精心挑選了四家雲服務提供商中的哪一家將託管其每個工作負載和一般業務應用程式。 “我們將雲提供商與他們最擅長的業務或技術服務相結合,”該公司高階副總裁兼首席技術官Jeff Calusinski說。
USAA 的多雲戰略基於他所謂的“設計開放”原則。 “我們使用開放標準,這減少了供應商鎖定的可能性,”他說。 但他承認,一些本地服務提供了令人信服的價值主張,必須權衡鎖定的可能性。
Nag 說,開放式設計原則在鎖定方面只能走到這一步,因為即使你使用的是現代服務,每個平台上的實現也是不同的。 例如,Amazon 的 EC2 和 Google 的 GCP 做同樣的事情,但是在 EC2 上執行的應用程式如果不進行大量昂貴的返工,就無法在 GCP 上執行。 雖然 Kubernetes 是行業標準,但其實現(例如 Azure 通訊服務和 Google Kubernetes 引擎)有所不同。
但是,雲提供商和應用程式之間已經存在一些抽象層,“Del Giudice 說,即使使用本地雲提供商服務,也可以簡化遷移。 “這些服務,如發布-訂閱、服務呼叫、機密管理、狀態管理等,抽象了應用程式的元件,而不管是雲提供商。 因此,底線是,“您的選擇仍然開放,但需要做一些事情才能從乙個雲提供商遷移到另乙個雲提供商。 ”
Pablo del Giudice,Globant 雲運營和網路安全工作室合夥人。
資料需求是另乙個需要仔細規劃的方面。 “跨雲遷移應用程式的成本很高,因為您需要移動其他相關資料,而將資料移出是一項非常昂貴的工作,”Nag 說。 ”
因此,請提前計畫,holcomble補充道。 “除非您達成協議,知道如何取出資料以及如何在其他地方複製這些軟體服務,否則不要與提供商簽約。 ”
但是,根據 Del Giudice 的說法,即使您制定了正確的 ETL 策略來確保您可以以結構化的方式和可用的格式在提供商之間遷移資料,這些計畫通常也不存在。 “儘管雲服務提供商強調使用開放平台和資料訪問協議,理論上易於使用,但訪問這些服務的網路限制和安全性往往被忽視。 ”
在決定使用哪些雲原生服務時,有時組織別無選擇。 安全性就是乙個很好的例子。 “如果你的安全需求很高,通用的網路安全可能還不夠。 “您的需求越具體,在業務鎖定方面的服務要求就越嚴格。 他表示,資料密集型運營的企業同時面臨儲存和頻寬問題,而PaaS和IaaS提供商將這兩個因素作為其競爭優勢。 “如果你想同時獲得高效能的儲存和頻寬,那麼問題就很棘手了。 ”
霍爾科姆遵循他所謂的“黑雲杉”方法,利用本地服務進行定製。 他說,就像黑雲杉的樹枝靠近樹幹一樣,美國專利商標局也使定製盡可能“瘦”。 這不僅減少了鎖定,而且還確保組織不會面臨負擔過重、成本高昂的版本控制路徑的壓力。
卡盧辛斯基也採取了類似的方法。 “大多數 PaaS 都具有核心功能和一些輔助功能,我們限制了輔助功能的數量,並專注於核心功能。 ”
Jeff Calusinski 是 USAA 的高階副總裁兼首席技術官。
Holcombe補充說,基於SaaS的應用程式也是如此,他的團隊在從Remedy遷移到ServiceNow和Salesforce後遵循了這一原則。 “不要做太多的定製,並在需要時進行更改,我們不依賴它們,這是乙個很棒的結構平台,”他說。 但是,如果你優化得太多,你就會陷入困境。 ”
然而,這一次,卡盧辛斯基的處理方式有所不同。 “對於SaaS平台,我們試圖盡可能多地採用它們,因為作為一家企業,我們在供應商能力方面沒有看到足夠的差異化,而且改變的可能性很低。 ”
避免潛在的遷移痛點
顯然,在雲提供商之間遷移會帶來無數挑戰,包括相容性問題、安全問題、大規模應用程式重新配置的需求,以及處理基於傳統作業系統和過時技術堆疊的映像,這些映像無法無縫整合到新環境中。 傳輸大量資料還可能導致停機和潛在的資料丟失,因此在遷移過程中確保一致的效能和可擴充套件性至關重要。 “應對這些挑戰需要細緻的規劃、徹底的測試和明確的回滾策略,”Del Giudice 說。
此外,PaaS 遷移的關鍵故障點包括未滿足的成本或業務期望、資源技能不足、缺乏標準化和安全基礎、未能利用雲原生能力、安全性和合規性問題以及未能採用雲運營模式。
Del Giudice 建議任何組織在考慮雲提供商之間的遷移時採用六步方法。 首先,評估訂閱模式,確保它符合你的投資回報率目標。 採用混合雲方法。 盡可能使用與雲無關的解決方案,以保持未來的遷移選項開放。 使用本機雲服務時,請使用抽象層來設計應用。 投資於資料遷移規劃、測試和備份策略,以降低風險。 根據需要檢視和調整許可協議。
仔細權衡您的選擇
Calusinski說,在考慮任何雲提供商遷移時,你總是必須考慮遷移的成本和資料的所有權。
Holcombe 表示,當您需要平衡使用本地雲服務(增加鎖定)與保持雲不可知性時,沒有乙個正確的答案,只有適合您的組織及其使命的最佳答案。 他說,問題在於基於雲的應用程式是否與組織的使命保持一致,並隨著時間的推移提供實現這一目標的最佳價值。 “如果你的成本基礎設施太複雜,當商業模式發生變化時,你就無法改變它,”他說,並補充說,保持你的選擇開放,就像美國專利商標局用多雲架構設計一樣。 “主要原因是服務提供商之間存在競爭。 ”
根據 Del Giudice 的說法,在制定雲遷移策略時,請務必注意定價模型。 “探索潛在的成本節約計畫並考慮資料傳輸成本對於防止雲運營費用意外激增和確保遵守預算限制至關重要。 他補充說,在執行遷移策略時,還需要考慮另外兩個因素。 首先,雲服務提供商(如微服務或無伺服器)可以提供哪些服務來促進遷移?您需要決定是使用自定義解決方案還是來自雲提供商的託管服務,這存在供應商鎖定的風險。 其次,雲提供商可能會為遷移應用程式提供激勵計畫,這對於大型遷移來說可能很重要。
就其本質而言,雲遷移可能存在風險。 但是,那些未雨綢繆並有毅力完成這一過程的首席資訊官可能會看到更具成本效益的雲服務和定價模式,改進的可擴充套件性和資源分配,以及增強的效能和響應能力。 Del Giudice表示:“減少供應商鎖定可以帶來更大的敏捷性和創新,最終,雲遷移可以推動競爭力、創新和效率。 ”