內部部署到云遷移：成為云原生的4個關鍵挑戰
在將應用程序和數據從內部部署遷移到云平臺時，組織需要了解其面臨的主要挑戰。這表明組織需要了解在云平臺中部署工作負載的重要性，并將應用程序從內部部署遷移到云平臺。云平臺的動態性質使擴展基礎設施以適應不斷變化的需求成為一個相對輕松的過程。
成功的云遷移面臨許多挑戰，其中包括控制成本、選擇正確的體系結構以及擴展學習曲線。因此，至關重要的是要確保從規劃和評估到遷移的每個步驟都由經過云計算專家的認證或服務提供商執行。
以下是組織致力于成為云原生公司時面臨的主要挑戰：
挑戰1–重新設計云計算數據模型
不同類型的數據存儲區支持不同類型的架構。AWS Redshift支持PostgreSQL，而Big Query使用STRING、RECORD(半結構化對象)和REPEATED(數組)類型。微軟Azure提供了SQL、MySQL、PostgreSQL和MariaDB。
還有一些完全不支持各種架構的特定數據類型(BLOB和地理坐標等)。與在分布式服務器上運行JOINS相比，增加用于保持數據更新所需的存儲空間成本并不高昂，并且可以提供更好的性能。要解決這些差異，只調整一次數據模型是不夠的。當兩個數據模型隨時間變化時，保持連續同步至關重要。
挑戰2–安全性
當組織的云遷移獲得了廣泛的認可和動力時，安全性就變得至關重要。在這個階段，權限可能變得難以處理，但這也是分配所有需要訪問云計算資源，并相應規劃安全策略的組和角色的機會。如果正確配置和檢查，這將是漫長的云遷移旅程的又一重大勝利。
Azure了解客戶需要信任他們的數據安全性。因此，云計算服務提供商必須滿足醫療、金融和政府機構制定的行業最高安全標準。當在已經通過認證的IT基礎設施上運行時，這使得獲得SOC2、ISO2700、HIPAA和PCI等標準認證變得更加容易。
身份驗證、授權、日志記錄和審核都集成在所有云平臺上。安全措施(如網絡和應用程序防火墻、DDoS保護和身份管理)經過標準化、測試并可用于安裝和配置。
挑戰3：將自定義數據應用程序連接到數據存儲
另一個障礙是優化自定義數據應用程序用于連接到數據存儲的接口。換句話說，盡管ODBC/JDBC驅動程序得到了積極的支持和維護，但它們之間的行為卻很難相互配合。
更改應用程序的數據庫驅動程序可能需要幾個查詢參數。在首次使用時，一些更改將很明顯，因為SQL語句可能會導致可見錯誤。其他變化不太明顯，因為不同的ODBC驅動程序可以執行較小的數據轉換。
此類轉換的示例可以是浮點數的準確性、時間戳的時區格式以及如何處理NULL值。這些更改只會以數據缺口的形式出現，并且需要進行更嚴格的測試才能檢測到。
挑戰4–編寫和使用存儲過程
云遷移期間最容易被忽視的挑戰之一是編寫和使用存儲過程的能力。主要的云計算數據存儲區Snowflake、Redshift和BigQuery支持用戶定義的功能(用Python、SQL或JavaScript定義)，但對于許多功能來說還不夠。
存儲在數據存儲區中的過程層類似于縮略圖數據應用程序的存儲庫，可以節省大量工作，并保留組織特定的知識。常見的替代方法是使用單獨的平臺來計劃參數化的查詢或編排任務。
Azure Cosmos DB提供的功能使組織可以編寫存儲過程、觸發器和用戶定義的函數。在Azure Cosmos DB中使用SQL API，組織可以使用JavaScript語言定義存儲過程、觸發器和UDF，并在數據庫引擎中執行它。
組織在將其應用程序和數據遷移到云平臺時都必須解決許多挑戰。通過熟練的云計算工程師采用高級工具進行部署，組織可以避免重大的云遷移挑戰。他們甚至可以考慮利用托管的云計算服務來將其應用程序和數據高效及時地移至云平臺中。
