您的位置:首頁>科技>正文

“現在上雲是最好的時機嗎?”“是”

很多企業最初選擇雲端可能僅僅是出於戰術性上的考慮, 但是隨著資料移轉/備份工具的可用性逐漸提高、雲端資料引力的形成, 業務因此獲得的可擴展性便可以看作是這一戰術所帶來的豐厚投資回報。

為什麼是雲端?

根據調研機構IDC的調查, 70%的企業CIO擁有雲端策略, 而且絕大多數企業都擁有多雲基礎架構, 可以將應用程式部署在最適合的雲端, 包括私有雲、公共雲以及混合雲。 除了保護遷移到雲端的整個應用程式之外, 企業還可以將資料集移動到雲端進行測試、開發或分析, 將非核心資料移轉到雲端上以實現成本效益。

Gartner預測, 未來五年內, IT開支中1萬億美元以上價值將直接或間接受到轉向雲服務這個重大改變的影響。 業務流程外包將是“雲轉換”背後最大的推動力。 至2020年, 業務流程外包比例約占IT開支的43%。

大多數組織現在已經實施了包括計算、存儲、網路在內的一種或多種虛擬化戰略,

這使得雲計算的升級更加可行。 但是更可能的是, 這些應用程式和其他系統基礎設施只是出於組織雲遷移的熱情。 當本地部署的資料中心需要擴大規模, 並且成本、資源和管理限制不再適用時, 企業業務移動到像雲端之類的需要擴展的彈性平臺。

資料一直以來被看作是一種“生成物”, 然而當資料像雪球一樣滾動時, 資料的品質就會越來越大。 根據萬有引力定律, 當物體距離一定時, 品質越大, 引力越大。 隨著引力的出現, 越來越多的應用開始圍繞資料而產生或者開始向資料方向傾斜。 因此, 一個明智的方法是儘早的完成資料的雲端遷移, 避免你的雲上應用被本地資料引力所拖累。

如果你已經下定決定實施雲端遷移計畫, 並且所選擇的是公有雲, 那麼還有一些因素仍然需要仔細考慮, 比如:

1、在無法正確預測未來業務發展時, 儘量選擇彈性更好的雲平臺;

2、避免造成資料孤島;

3、即使雲端的安全性越來越高, 但是瞭解有關加密和金鑰管理、身份和訪問管理(IAM)、審核和遵守當地法規的合規性和安全性等問題依然有其必要性;

4、解長期雲存儲潛在的高成本, 做好資料重要性與數量的選擇備份;

5、多個雲端共生的局面正在破壞基礎架構世界的應用層, 因此, 軟體的橫向與縱向的通用性將至關重要。

如何遷移?

任何技術都可以看作為一種媒介。 比如, 如果你在沙灘散步時, 涼鞋是隔開燙腳的沙子的“技術”, 而沙子則可以看成推進“涼鞋”的發展的重要方式, 在《第四次革命》一書中, 作者盧西亞諾•弗洛裡迪將其定義為“敦促者”, 可以簡答理解為“痛點”。

當技術介於人(使用者)和敦促者之間時, 我們稱之為“一級技術”, 比如我們所使用筷子、汽車、手機等各種工具。

隨著技術的不斷發展, 慢慢的一種介於人(使用者)與“一級技術”之間的另一種技術形式開始出現, 我們可以簡單的稱之為“二級技術”, 也就是這這種技術的另一端不再連結敦促者, 而是連結另一種技術。 比如螺絲釘, 它是介於螺絲刀和兩塊木板之間的技術。 許多一級技術在缺少與之配對的二級技術輔助時無法正常發揮作用, 最簡單的例子就是要麼同時擁有螺母和螺釘, 要麼兩者都沒有。

我們今天講的“雲遷移”就是一種“二級技術”。

遷移所指向的一級技術就是業務重啟與存儲、網路等多方位的現實因素。 雖然許多廠商在遷移的過程中會提供相應的資料抽取與校驗工具, 並且這些工具在一定範圍內解決了資料移轉問題, 但這些工具基本都不能自動完成資料的抽取,使用者還需利用這些工具編寫適當的轉換程式來提高效率,更為重要的是,在遷移的過程中往往還需要業務的停機,延長業務恢復的時間視窗。

一個典型的需求場景是這樣的:

最開始設計的是冷資料歸檔,具體做法是手動將生產庫的資料批次遷移到歷史庫。但手動操作的方式費時費力,因此就有了自動遷移的需求,但由於資料是與應用災備結合在一起的,因此就需要一個能保持生產庫和歷史庫的一致性的無狀態工具來保證應用切過去之後這個歸檔功能也能繼續。

在實際工作中,並不是所有的伺服器都可以遷移到雲端,也並不是所有的遷移都能夠成功,所以,一個完整的遷移方案是必不可少的,以英方i2Move產品為例遷移過程一般包括評估和分析、方案設計、環境準備、遷移實施、測試驗證和系統割接等6個階段。

總體來說,不管是應用程式遷移、還是資料移轉都不是一個孤立的決斷。遷移最終的目的是保證資料的一致性,減少對現有系統的影響,並保證業務的快速恢復。遷移的方式可以簡單、快速,但遷移之前的抉擇與遷移之後的維護則需要放入到一個更廣泛的環境來考慮。

但這些工具基本都不能自動完成資料的抽取,使用者還需利用這些工具編寫適當的轉換程式來提高效率,更為重要的是,在遷移的過程中往往還需要業務的停機,延長業務恢復的時間視窗。

一個典型的需求場景是這樣的:

最開始設計的是冷資料歸檔,具體做法是手動將生產庫的資料批次遷移到歷史庫。但手動操作的方式費時費力,因此就有了自動遷移的需求,但由於資料是與應用災備結合在一起的,因此就需要一個能保持生產庫和歷史庫的一致性的無狀態工具來保證應用切過去之後這個歸檔功能也能繼續。

在實際工作中,並不是所有的伺服器都可以遷移到雲端,也並不是所有的遷移都能夠成功,所以,一個完整的遷移方案是必不可少的,以英方i2Move產品為例遷移過程一般包括評估和分析、方案設計、環境準備、遷移實施、測試驗證和系統割接等6個階段。

總體來說,不管是應用程式遷移、還是資料移轉都不是一個孤立的決斷。遷移最終的目的是保證資料的一致性,減少對現有系統的影響,並保證業務的快速恢復。遷移的方式可以簡單、快速,但遷移之前的抉擇與遷移之後的維護則需要放入到一個更廣泛的環境來考慮。

Next Article
喜欢就按个赞吧!!!
点击关闭提示