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

可移植的工作負載能在不同運算環境和基礎架構平台上輕鬆遷移、部署和管理。
藉此，企業能夠避免被供應商鎖定，並保持雲端策略的彈性。

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

設計雲端可移植性策略

如果你正在考慮雲端應用架構，那麼可以透過以下無方面考慮著手，設計成功的可移植工作負載。

確定需求

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

這就好比採取一種簡單的方法來了解滿足最終成果所需的全部功能和特性，進而確定軟體堆疊和依賴項，以及滿足這些需求的其他元件。有了這樣客觀、簡潔的視角，就好比透過廣角鏡頭去觀察雲。這種方式才能更能凸顯能在任何雲端平台的核心雲端基礎架構上運作的各種功能。

確定鎖定點

無論應用程式仍處於建置或規劃階段，還是已經在雲端平台上開發和部署，都要對目前架構設計進行評估，以發現目前平台上使用的獨有元件和服務。

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

• 為了更快速地推出或縮短上市時間，是否選擇，或至少考慮過某種解決方案？

• 解決方案是根據諮詢結果決定的，還是基於與該平台上其他服務的支援/互通性來決定的？

• 當時選擇這個解決方案時的成本，和現在的成本相比有何變化？

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

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

利用負載平衡技術，結合容器化、運算實例映像、設定管理以及有狀態和無狀態元件的分離，可順利實現橫向擴展和分發。
在可能的情況下，狀態應該是聲明性的，由單一的「事實來源」進行維護和管理，並自動複製和同步。

模組化設計

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

一切皆程式碼

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

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

=======

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

歡迎關注Akamai，了解Akamai能在這過程中為您提供的產品、服務和技術支援。