在實際應用中，人們已經看到很多DevOps實踐遷移到云中，其傳統應用程序從整體轉變為微服務。然而，這是人們發現的非常有趣的邊緣項目。其中包括圍繞數據攝取、物聯網開發，以及大規模大型機和企業資源計劃(ERP)系統的深度集成。
在過去的一年中，很多企業正在探索甚至開始將他們的一些遺留環境遷移到云中。例如，將部分或整個SAP生態系統遷移到谷歌云平臺，或將整個Oracle生態系統遷移到云中。最后，使用大規模IBM AS/400體系結構并將這些組件移動(或重構)到云中。
有幾個原因可以解釋為什么如此多的組織在遷移或現代化這些系統方面猶豫不決。其原因包括：
(1)恐懼、不確定和懷疑。事實上，這么做的人并不多。而且，將整個業務引擎遷移到云中可能會很可怕，因為沒有很多用例，遷移這些平臺可能非常危險。許多組織根本無力承擔這項成本高達數百萬美元的后果。
(2)復雜性。一些AS/400系統已經存在多年，甚至幾十年。大規模的ERP系統也是如此。許多組織使用其SAP解決方案的想法根深蒂固，并僅限于內部部署。
(3)成本和投資。一些企業已經在他們的ERP和大型機系統上投入了數百萬甚至數千萬美元。他們多年來投資基礎設施、合同、人員等等。企業需要顯示一些真實的投資回報率，甚至考慮將這些系統遷移到云端。
現在有一些好消息。很多組織意識到要顛覆數字驅動的市場，他們自己必須被顛覆。這意味著打破傳統的部署范例，并尋找將大型機甚至ERP系統遷移到云中的方法。或者，尋找強大的混合解決方案可以提供幫助。
云計算正在帶來變化
很多企業通過ERP和大型機架構改變他們的工作方式，并與大型企業客戶討論這些解決方案。以下分享兩個具體的例子：
例如，將超過600萬行傳統RPG/Synon代碼遷移到與云計算部署兼容的面向服務的體系結構中。這是一個大規模的IBM AS/400系統的故事，對于一個正在尋求成為數字原生的組織來說，它根本就沒有發揮作用。該項目規模龐大，但也具有很強的可行性和良好的規劃。經過一些徹底的遺留代碼分析，遷移了600多萬行代碼，重新編寫了150多個集成點。這包括為審查RPG代碼而開發的定制工具、綠色屏幕分析器，甚至利用X-2E工具對遺留代碼進行可跟蹤性審查和可視化。此外，它還包括從IBMDB2遷移到更靈活的Mariadb。
這是最重要的部分，一旦完成，遷移還包括DevOps實踐，以允許客戶繼續創新和擴展。這很容易嗎?這是否需要一些創造性思維和定制工具集?當然。但這值得嗎?最好相信值得。對于客戶來說，遷移業務的這一部分意味著將多個業務線集成到一個數字框架中。而且，對于行業和客戶來說，這確實讓他們與眾不同。
將SAP Hana和其他組件遷移到云中。將ERP系統遷移到云中可能是一個非常復雜的過程。此外，如果弄錯了，可能會對業務造成嚴重后果。請記住，對于企業來說，像SAP這樣的ERP解決方案確實是他們的整個業務引擎。一旦克服了這種恐懼，就會開始看到全局，并為未來設計一個方案。
最成功的遷移都是通過并行設計中的概念驗證來完成的。例如，假設希望將SAP生態系統的一部分或全部移入谷歌云平臺(GCP)。為此需要：
•了解S/4HANA如何適應環境及其提供的具體優勢。
•確定業務需求中的主要差距
•分析潛在的景觀
•創建目標云計算解決方案的愿景，并將SAP路線圖概述為轉型項目
在一個客戶場景中，能夠將大規模復雜的電子商務引擎與SAP和谷歌云平臺集成。利用SAP HANA、Google BigQuery、Google DoubleClick和其他組件創建圍繞混合云設施構建的整體設計。在那里，人們看到設計實際上可以利用強大的多云生態系統。因此，SAP混合營銷已遷移到AWS，并且在谷歌云和AWS云平臺之間集成了超過50個核心系統。其中包括SAP ERP(IS-R和AFS)、SAP Business Warehouse、Salesforce等。
這個項目的重點是采用一個非常謹慎的方法。提前做了一個概念驗證。對系統進行了性能和集成功能測試，能夠在將任何內容投入生產之前驗證實際結果。
這需要考慮很多方面。但是，要知道已經存在一些用例和場景，其中一些最大和最復雜的ERP甚至大型機系統正從傳統的單一平臺轉移到高級數字解決方案中。所有這些都使集成變得更容易，促進了自己的開發過程，并使企業能夠響應數字化和數據驅動的市場。
京公網安備 11010502049343號