云可移植性是構建可擴展、有彈性、云原生應用程序的一種策略。談到云原生，通常也會暗含地考慮到云的可移植性。云原生是一種應用程序開發和部署架構方法，可最大限度利用云計算資源的彈性和敏捷性。然而，當團隊開始使用單一云平臺，并圍繞這個平臺的供應商所提供的專用工具和托管服務進行構建時，很快就會面臨供應商鎖定的局面。

延伸閱讀，了解 Akamai cloud-computing

可移植的工作負載能在不同計算環境和基礎設施平臺上輕松遷移、部署和管理。借此，企業能夠避免被供應商鎖定，并保持云戰略的靈活性。

如果從一開始就選擇“云中立”的方法，并使用能與任何云平臺相兼容的工具，我們就可以根據需求的變化靈活做出改變。可移植性戰略還能讓我們更深入地了解資源的使用方式和原因，并根據應用和業務需求選擇不同的云平臺，甚至在不同平臺間轉移。

設計云可移植性策略

如果你正在考慮云應用架構，那么可以通過以下五方面考慮著手，設計成功的可移植工作負載。

確定需求

實現可移植工作負載的第一步是客觀地確定工作負載需求。我們可能經常會看到這樣的情況：在進行最開始的這一步工作之前，主觀臆斷就已經污染了整個過程，因為人們的目光會被云提供商的誘人服務所吸引。因此，這里的重點是：在考慮云平臺之前，就先確定需求范圍。

這就好比采取一種簡單的方法來了解滿足最終成果所需的全部功能和特性，進而確定軟件棧和依賴項，以及滿足這些需求的其他組件。有了這樣一個客觀、簡潔的視角，就好比通過廣角鏡頭去觀察云。這種方式才能更好地凸顯能在任何云平臺的核心云基礎設施上運行的各種功能。

確定鎖定點

無論應用程序仍處于構建或規劃階段，還是已經在云平臺上開發和部署，都要對當前架構設計進行評估，以發現當前平臺上使用的獨有組件和服務。

如果已經確定了可能被供應商鎖定的點，請花時間評估具體原因。首先請回答以下問題：

• 為了更快速地推出或縮短上市時間，是否選擇，或至少考慮過某種解決方案？
• 解決方案是根據咨詢結果確定的，還是基于與該平臺上其他服務的支持/互操作性來決定的？
• 當時選擇這個解決方案時的成本，和現在的成本相比有何變化？

回答完這些問題后，我們就可以開始規劃理想的開源解決方案或其他可提供相同或類似功能的替代解決方案，評估實施所需的工作，并制定執行計劃。如果在所有評估后，仍然決定堅持使用特定平臺的服務，請確保自己還有退出策略。云計算供應商鎖定有兩種形式：架構鎖定和運營鎖定。圍繞專有云服務深思熟慮制定的退出策略可以減輕這兩種擔憂。

可擴展、可持續運行的構建

利用負載均衡技術，結合容器化、計算實例映像、配置管理以及有狀態和無狀態組件的分離，可順利實現橫向擴展和分發。在可能的情況下，狀態應該是聲明性的，由單一的“事實來源”進行維護和管理，并自動復制和同步。

模塊化設計

單體架構可能會變得繁瑣、難以管理，從而降低以可移植方式進行更改所需的靈活性。因此，工作負載應采用模塊化設計，明確定義不同組件，并作為一個松散耦合的系統協同工作。云原生設計提供了一種更新或替換單個組件而不影響整個工作負載的高效流程，最終提高了可維護性、適應性和可移植性！

一切皆代碼

如果要開發云原生應用程序，那么我們應該熟悉聲明式部署方法：將工作負載的每一部分（應用程序、基礎架構和配置管理）都編成代碼。采用這種方法，我們可以自動部署新環境（如開發、暫存、測試環境）或復制現有環境。這將簡化藍/綠部署流程，并在發生災難時快速恢復。

GitOps方法為我們提供了實現可移植性的單一途徑，能通過自動化管道的可靠性優勢來規范部署，提高合規性/審計的可視性，并將策略的實施以代碼方式來執行。

通過上述五方面的思考，我們就可以結合自身需求，制定出適合的云可移植性戰略，從而在云原生應用中獲得真正的靈活性，真正讓工作負載能在任何云平臺上流暢運行和遷移，從方方面面享受到云原生所應提供的價值。

如您所在的企業也在考慮采購云服務或進行云遷移，

點擊鏈接了解Akamai Linode的解決方案