本文是Ampere Computing“加速雲計算”系列文章的第三部分。您可以在這裡閱讀第一部分和第二部分。
正如我們在本系列的第二部分中所展示的，將應用程序重新部署到雲原生計算平台通常是一個相對簡單的過程。例如，Momento將其重新部署體驗描述為“比我們預期的工作量少得多。Pelikan在T2A（谷歌基於Ampere的雲原生平台）上立即運行，我們使用現有的調整流程對其進行了優化。 ”
當然，應用程序可能很複雜，包含許多組件和依賴項。複雜性越高，可能出現的問題就越多。從這個角度來看，Momento將Pelikan Cache重新部署到Ampere雲原生處理器的經驗提供了許多見解。該公司已經建立了一個複雜的架構，他們希望盡可能地自動化一切。重新部署過程為他們提供了實現這一目標的機會。
首先要考慮的是確定您的應用程序如何從在雲原生計算平台上的重新部署中受益。大多數雲應用程序都非常適合雲原生處理。為了了解哪些應用程序可以從雲原生方法中獲益最多，我們仔細研究了Ampere雲原生處理器架構。
為了實現更高的處理效率和更低的功耗，Ampere採用了不同的方法來設計我們的核心——我們專注於雲原生應用程序在性能、功耗和功能方面的實際計算需求，並避免集成為了非雲用例而添加的傳統處理器功能。例如，當應用程序必須處理大量3D圖形或特定類型的高性能計算處理時，可擴展矢量擴展非常有用，但會帶來功耗和核心密度方面的權衡。對於需要SVE的應用程序（例如雲中的Android遊戲），雲服務提供商可以選擇將Ampere處理器與GPU配對以加速3D性能。
對於雲原生工作負載，Ampere核心的功耗降低和核心密度增加意味著應用程序以更高的性能運行，同時功耗更低，散熱更少。簡而言之，對於大多數應用程序而言，雲原生計算平台可能會提供卓越的性能、更高的能效和更高的計算密度，同時降低運營成本。
Ampere擅長的是具有許多獨立組件的基於微服務的應用程序。此類應用程序可以從更多內核的可用性中受益匪淺，Ampere在一個單芯片上提供128個內核的高核心密度，在一個帶有兩個插槽的1U機箱中最多可提供256個內核。
事實上，當您水平擴展（即跨許多實例進行負載平衡）時，您就可以真正看到Ampere的優勢。因為Ampere與負載線性擴展，所以您添加的每個內核都會帶來直接的好處。將其與x86架構進行比較，在x86架構中，每個新增內核的好處會迅速減少（參見圖1）。
圖1：由於Ampere與負載線性擴展，因此添加的每個內核都會帶來直接的好處。將其與x86架構進行比較，在x86架構中，每個新增內核的好處會迅速減少。
重新部署應用程序面臨的挑戰之一是識別專有依賴項。在軟件供應鏈中任何使用二進製文件或專用基於x86的軟件包的地方都需要引起注意。可以通過搜索文件名中包含“x86”的代碼來找到許多這些依賴項。替換過程通常很容易完成：用適當的基於Arm ISA的版本替換x86軟件包，或者如果您有權訪問源代碼，則為Ampere雲原生平台重新編譯可用的軟件包。
一些依賴項會帶來性能問題，但不會帶來功能問題。考慮一個使用針對x86平台優化的代碼的機器學習框架。該框架仍然可以在雲原生平台上運行，只是效率不如在基於x86的平台上運行。解決方法很簡單：識別針對Arm ISA優化的框架的等效版本，例如Ampere AI中包含的那些版本。最後，還有一些生態系統依賴項。您的應用程序依賴的一些商業軟件，例如Oracle數據庫，可能無法作為基於Arm ISA的版本提供。如果是這種情況，在提供此類版本之前，這可能還不是適合重新部署的應用程序。針對此類依賴項的解決方法，例如將它們替換為雲原生友好的替代方案，可能是可能的，但這可能需要對您的應用程序進行重大更改。
一些依賴項位於應用程序代碼之外，例如腳本（即Ansible中的playbook、Chef中的Recipes等等）。如果您的腳本假設特定的軟件包名稱或架構，則在部署到雲原生計算機平台時可能需要更改它們。大多數這樣的更改都很簡單，對腳本進行詳細審查將揭示大多數此類問題。注意調整開發團隊多年來可能做出的命名假設。
現實情況是，這些問題通常很容易處理。您只需要徹底識別並處理它們即可。但是，在評估解決此類依賴項的成本之前，有必要考慮技術債務的概念。
在福布斯文章《技術債務：數字化轉型難以衡量的障礙》中，技術債務被定義為，“系統相對快速的修復的積累，或沉重但方向錯誤的投資，從長遠來看可能是資金的流失。”快速的修復可以使系統繼續運行，但最終積累的技術債務會高到無法忽視的地步。隨著時間的推移，技術債務會增加軟件系統中變更的成本，就像咖啡機中的水垢積聚最終會降低其性能一樣。
例如，當Momento將Pelikan Cache重新部署到Ampere雲原生處理器時，他們已經安裝了依賴於15年前的開源代碼的日誌記錄和監控代碼。代碼有效，因此從未更新。但是，隨著工具隨時間的推移而發生變化，需要重新編譯代碼。需要進行一定的工作來保持向後兼容性，從而創建對舊代碼的依賴性。多年來，所有這些依賴項都會累積起來。在某個時候，當維護這些依賴項變得過於復雜和代價高昂時，您將不得不過渡到新的代碼。技術債務可以說會被收回。
在將應用程序重新部署到雲原生計算平台時，了解您當前的技術債務以及它如何驅動您的決策非常重要。多年來維護和適應遺留代碼會累積技術債務，這使得重新部署更加複雜。但是，這本身並不是重新部署的成本。即使您決定不重新部署到另一個平台，總有一天您將不得不彌補所有這些快速的修復和其他推遲更新代碼的決定。您只是還沒有這樣做。
技術債務有多真實？根據麥肯錫的一項研究（參見福布斯文章），該研究中30%的首席信息官估計，他們用於新產品的技術預算中超過20%實際上被用於解決與技術債務相關的問題。
重新部署是一個很好的機會，可以解決應用程序多年來積累的一些技術債務。想像一下，收回貴公司用於解決技術債務的“20%”中的一部分。雖然這可能會增加重新部署過程的時間，但處理技術債務具有從長遠來看簡化管理和維護代碼的複雜性的好處。例如，您可以通過將代碼遷移到當前的開發環境來“重置”許多依賴項，而不是繼續依賴它們。這是一項投資，可以通過簡化您的開發週期來立即帶來回報。
Plesk的產品經理Anton Akhtyamov描述了他重新部署的經驗。 “移植後，我們遇到了一些限制。Plesk是一個大型平台，可以安裝許多附加模塊/擴展。有些不受Arm支持，例如Dr. Web和卡巴斯基殺毒軟件。某些擴展也不可用。但是，我們的大多數擴展已經使用供應商為Arm重建的軟件包得到支持。我們也有自己的後端代碼（主要是C ），但由於我們之前已經對其進行了調整以支持x86-64，因此我們只是在沒有任何關鍵問題的情況下重建了我們的軟件包。”
有關將應用程序重新部署到雲原生平台的更多實際示例，請參閱將Takua移植到Arm和Ampere Altra上的OpenMandriva。
在本系列的第四部分中，我們將深入探討將應用程序重新部署到雲原生計算平台時可以期待的結果。
以上是加速雲：過渡到雲的詳細內容。更多資訊請關注PHP中文網其他相關文章！
