原文來自Medium，作者Victoria Drake
原文鏈接：https://medium.com/better-programming/migrating-to-the-cloud-without-screwing-it-up-ee8455ca0c9e
現在，一個試圖拓展的應用程序，不使用託管雲架構就好像在臨渴挖井。這需要大量勞力、許多設備、很多時間，而且很有可能出錯，因為無論如何，個人不會有豐富的挖井經驗。
我們排除一種情況——沒有云，也就是用別人的電腦。
現在，雲服務遠遠超出我們對單機操作的期待。快速強大的計算能力，已經不需要巨大的辦公室空間容納，衍生出眾多監測、管理和分析工具，在指尖即可完成操作。
值得注意的是，雲並不是一把萬能鑰匙。對於可以上雲的應用程序，比起搭建自己的本地基礎設施，它計算能力更強、更快、也更省錢。
問題是知易行難。從一開始，遷移到雲端就是項艱鉅的任務。我們如何才能將日積月累的本地數據和系統轉移到別的計算機？畢竟雲端看不見也摸不著，怎麼才能不把事情搞砸？
儘管建立或維護本地系統工作量更小，花銷更低，最開始轉移到雲端還是有一定的工作量。重要的是，一旦應用程序完成遷移，就能充分享有云服務的優勢。為實現這一目標並順利過渡，準備工作至關重要。實際上，這就像搬家一樣。
本文將高屋建瓴地介紹本地應用程序或自託管應用程序遷移到雲端的大體步驟，旨在為特定情況規劃合理的流程，更好地瞭解雲遷移的過程。
儘管對部分應用程序來說，比如沒有可拓展結構或需要大量算力的應用程序，雲端可能不是最佳選擇，但對大部分現代模塊化應用來說，遷移到雲大有裨益。
近日在亞馬遜雲服務平臺（Amazon Web Services，以下稱AWS）解決方案架構的活動中，已經實現了平穩高效且仍舊保持可用性地遷移到雲，幾乎不折損用戶可用性。
我會具體介紹AWS提供的服務。當然，其他雲服務平臺也可提供相似的服務。我發現AWS所提供的服務基本都經過模塊化，這點非常好，這也是為什麼我偏愛AWS的原因。
為使遷移更順利，以下是我們需要考慮的事宜：遷移類型、保留和清理的內容、基礎設施類型和大小、峰值測試準備。
遷移類型
我們需要了解為什麼要將應用程序遷移到雲上，同時我們也需要大致瞭解遷移結果。遷移的方法主要有三種：重新託管（re-host）、更換平臺（re-platform）和重構（refactor）。
重新託管
重新託管是雲遷移時最常見的策略。它不會改變應用程序創建或運行的方式。例如，如果目前有Python（計算機程序設計語言）代碼，使用PostgreSQL（開源的對象-關係數據庫），並通過Apache（開源網頁服務器軟件）為應用程序提供服務。
在此情況下，重新託管就意味著將所有相同的組件以相同的方式組合在一起，只不過組裝在雲上。這就好比搬入一個房型完全一致的新房子。所有房間佈局、傢俱都和以前一樣。當我們住進去時，就會感覺很熟悉。
重新託管的好處在於它可以利用雲端優勢，降低複雜性。比如可擴展應用獲得自動管理應用程序資源的能力。
值得注意的是，重新託管雖然可以促進應用程序的自動化擴展，但其本身並不能使應用程序具有擴展性。如果應用程序的基本設施本身屬性無法拓展，就需要重構應用程序。
更換平臺
若當前應用程序中的某組件運行情況不甚良好，我們可能需要考慮更換平臺。這種情況下，我們會更改架構中的至少一個組件。比如，在Amazon雲關係數據庫（RDS，基於雲計算平臺的即開即用、穩定可靠、彈性伸縮、便捷管理的在線關係型數據庫服務）把數據庫從Oracle數據庫管理系統更換為MySQL開源數據庫。
就像從東京一間小公寓搬到紐約一間同樣大小的公寓一樣，更換平臺並不會改變應用程序的基本性質，只是改變了外觀和運行環境。以數據庫的更改為例，內部數據保持相同，但其組構方式會有些許不同。大多數情況下，我們不需要進行手動調整。像Amazon數據庫遷移服務（Database Migration Service）這樣的工具可以幫助我們無縫地將數據轉移至新數據庫。
更改平臺幫助我們能夠更好滿足未來的業務需求，比如說擴大業務規模、與其他科技組件融合、或選擇一個更現代化的技術堆棧（technology stack）。
重構
相比其他的方法，重構應用程序會比較複雜。但對於能夠使用此類方法的公司或應用程序來說，大有利處。重構對代碼進行編輯以滿足業務需求。
具體細節因情況而異，但通常會涉及對架構組件或組件之間相互關係的更改。為優化應用程序在雲環境性能，重構也可能會更改應用程序代碼。
打個比方，就好像我們從父母的郊區地下室搬到市區裡漂亮的聯排別墅。我們不可能把陳舊的沙發一起搬出來，所以我們需要購買新的傢俱，甚至還需要購買窗簾。
重構對過時的應用程序進行現代化改造，換句話說，提高應用程序效率。憑藉更高的效率，我們可以更好地利用雲服務、獲取大量資源、以及深度分析能力。
如果時間有限，或許我們可以先選擇重新託管或更換平臺，再進行重構。此舉避免因為匆忙調整，引發更多問題。
保留 VS 清理
在一個地方生活多年，許多東西往往會堆積在角落並被漸漸遺忘。搬家可以讓我們好好整理東西，看看哪些要保留，哪些可以送人或丟棄。從應用程序的角度來看，遷移到雲的過程就和搬家過程類似。
儘管現在雲存儲的價格並不貴，但有些東西不再適合存儲，或者說，至少不能和我們的主應用程序存儲在一起。若因為相關政策法規有些數據無法被丟棄，我們可以選擇不同的存儲類別來存放主程序之外的數據。
以Amazon簡單存儲服務（Simple Storage Service，S3）為例，我們可以選擇不同的存儲類別存放數據。雖然每日業務運行的數據基本都可以歸為“標準類”（使用率達到99.99%），但那些用於長期靜態存儲的數據（如文檔備份），可以歸到“冰川類”，這樣可存儲時間會更長，成本也更低。
選擇正確類型和規模大小
最令人困擾的部分通常是選擇合適的雲基礎設施類型和規模大小。對於在新環境中或正在成長的公司，我們如何預測所需的計算能力？
無需採購硬件的好處之一就是不用預測。通過雲存儲及服務器，我們可在幾分鐘，甚至幾秒鐘內完成擴展或縮減資源。若藉助託管服務，甚至可以自動完成任務。如果應用程序具備擴展性，就好比有了一間魔法屋，可以生成任何房型和所需的便捷設施。我們可以自主操作確保使用合適且性價比高的資源，這一點也可以通過相關圖表直觀呈現。
對於首次登入雲端的應用程序來說，需要先進行測試。雖然雲服務能夠快速啟動並嘗試使用不同架構，但不能保證所有設置適合我們的應用程序。例如，運行一個單獨的服務器實例可能會比選擇無服務器便宜。但是在測試前，我們是無法知道這一點的。
首先，我們需要足夠的存儲空間和計算能力支持當前運行的應用程序。例如，在存儲方面，我們需要考慮當前數據庫的大小——實際數據庫數據，而不是內部硬件的總存儲容量。在詳細的成本方面，AWS甚至提供了一個帶有用例樣本的月度計算器，幫助用戶預估成本。
預先測試
運行一個雲遷移的試用版，聽起來可能有點奇怪，但這能確保一切有條不紊按計劃進行遷移，並減少服務中斷。試想，如果可以自動運行測試，在上述搬家的例子中，我們可以節省多少時間和精力。
我們總是會忘了把一些盒子或牆上掛著的相片帶走，於是只好下次再想辦法來搬。多次測試可以確保順利完成任務，從而最大限度地降低遷移導致日常業務中斷的可能。
一般來說會創建應用程序的副本進行測試。特別是數據異常大的時候，我們的副本與原版越接近，測試就越徹底。儘管創建副本可能有些繁瑣，測試實際要遷移的組件可以確保整個遷移過程按部就班進行。畢竟，如果我們想模擬搬家，一個盒子是遠遠不夠的，因為這並不具有代表性。
測試運行可以確認可能遇到的挑戰，包括停機時間限制、加密傳輸數據、轉換新目標模式、訪問數據庫（利用防火牆或VPN）、制定程式確保成功遷移所有數據，比如使用哈希函數。
測試運行還有助於瞭解遷移需要的總時間，同時也給了我們微調的機會。可能影響遷移總體速度的因素包括：原服務器及目標服務器的規模大小、移動數據的可用寬帶、模式配置、原服務器上的交易壓力（比如數據和交易量的更改）。
一旦應用程序副本通過一個或多個選項遷移後，我們就可以測試應用程序在雲環境的性能，以確保其運行正常。
理論上說，在正式遷移原始應用程序之前，我們會採取同樣的步驟遷移副本，並且將原始應用程序或網址無縫遷移到雲中的新位置。這意味著客戶幾乎不會經歷停機時間。實際上，也只有數據真正遷移的時候會受到短暫影響。
針對一些特殊情況，比如許多組件或多個團隊同時工作的超複雜（大）應用程序，相較於直接粗暴的方法，循序漸進的方法可能更合適，並且有助於減少中斷的風險。這意味著需要一個組件一個組件地遷移，並在各階段之間進行測試，確保所有的應用程序都能按預期交互運行。
前期準備對順利遷移至關重要
希望通過本文，讀者能夠對雲遷移有更實際深入的瞭解。只有充分的準備，才可以充分利用雲服務的所有優勢，並將風險降到最低。
閱讀更多 久謙諮詢 的文章
