在向云端遷移時，如果使用的是以架構為中心的方法，那么并不會提供用戶想象中的優點。

盡可放心使用那些無需自己管理架構的甲方云服務。

在規劃故障時，確保考慮了應用故障、服務故障、架構故障和設施故障。

認真考慮所需的服務規模，充分利用云所提供的彈性，一些時候，還需要考慮能節約費用的長效合同。

最近我參與了一個企業IT資產組合向云端的遷移，其中包括了基礎架構和應用。我注意到我們過分注重于基礎架構方面，而忽視了云端對應用本身的影響。在我看來，應用架構在云時代扮演著更重要的角色。根據自己在云端實施方面的經驗，我提出了一些專注于應用程序架構的原則。遵循這些原則，將有助于用戶真正地獲得云計算的優勢。如果你僅依賴于以基礎架構為中心的方法，那么遷移到云端將只會是又一次轉變，而非轉型。

松耦合。云使得我們可以按需擴展和縮小容量。但這只有當我們的系統（或子系統）是無狀態時才可以實現。系統（或子系統）應是松耦合的，這樣各個部分可以根據各自的負載需求分別進行縮放。

如果應用程序和Web服務器是松耦合的，那么兩者均可獨立地縮放。要實現這一點，需使用云原生的負載均衡器或隊列機制。這允許系統縮放到任意規模，去除了依賴約束。此外，在混合云場景中，隊列機制是連接系統的最好選擇之一。

單一職責的服務器。這個概念是我從面向對象編程中借鑒而來的。一般來說，我們傾向于將一臺服務器用于多個目的。然而，云使得我們可以創建不同規模的服務器，從非常小到非常大。反過來，這使得我們可在指定的服務器上僅部署一個代碼庫或可執行單元。通過這樣的做法，一個應用程序組件的更改就不會影響到其它任何組件。要實現上述模式，請遵循藍綠部署（Blue-Green Deployment）方法，確保對一個組件的部署不會造成其它組件的停機。

自動部署。云使我們具備了按需提供資源的能力。但是除非我們可以做到無需任何手動干預就在動態配置的基礎架構上運行應用程序，我們才能充分利用這種能力。這意味著我們不能交互式登錄到服務器去部署應用，應該使用編程的方式去應用配置和設置。換句話說，應禁用主機登錄，通過云提供商提供的腳本或API完成所有的配置和設置。

使用本地云服務。許多云實施依然專注于將云主要用作“基礎架構即服務”（IaaS）的托管模式。在自治（Self-managed）模式中，定義用于橫向和縱向擴展的觸發器是我們自身的職責。對于許多原生云服務，云提供商負責底層硬件設施的橫向和縱向擴展。云服務提供商負責硬件的配置、構建和設置、復制，以及一些情況下的軟件打補丁和集群擴展。云的真正優勢所在，只能通過使用原生云服務實現。

例如，使用AWS Lambda、Azure Functions、SQS或類似的原生云（Cloud Native）服務，就可以擺脫對基礎架構的定義。將這個工作交給云提供商！使用托管數據庫服務，例如AWS RDS，DynamoDB或Azure DocumentDB，避免使用自治的數據庫。這種做法存在一個缺點，它會將應用程序綁定到相應的云平臺。事實上，如果使用了云互操作（Cloud Interoperability）模型，就無法充分地利用云。這類似于不同的操作系統以自身的方式提供了類似的功能（例如，文件系統訪問，網絡，編解碼器等），每個云提供商都對通用的功能給出了自身獨有的建議方法。

將本地存儲看做是臨時存儲。作為擴展或部署實驗的組成部分，托管在云虛擬機上的應用可隨時丟棄。重要的是，應用不會在虛擬機本地存儲任何值。虛擬機的本地存儲應被視為臨時存儲。它會與虛擬機一并丟棄。在傳統方法中，應用將配置、日志文件、圖像等存儲在本地存儲中。然而，需要改變這種做法，任何持久信息都應轉移到一個持久的服務上，實現數據塊或對象的存儲。云應用程序應支持藍綠部署，這只有在當前執行的代碼沒有綁定到本地存儲時才可能實現。

設計應始終針對故障。在云中，我們不知道應用運行所在的位置。硬件會易于出現故障，軟件更新和補丁也會易于出錯。最好是在架構和設計時，就考慮到對應用故障的處理，而不是去考慮并力圖實現穩健性。穩健性是永遠也不可能實現的。消除單點故障（SPOF，Single Point Of Failure），逐層構建彈性。這樣，即使底層硬件發生故障，應用也可正常運行。