在soa世界的一篇文章「雲應用的遷移」中，chetan kothari和ashok kumar**了那些試圖把應用系統遷移到雲上的組織所面臨的挑戰：
\u0026#xd;\n
從邏輯角度而言，「雲計算」是否是我下乙個成功實現商業策略的步驟？如果是的話，我的雲策略應該是什麼？哪種應用適合執行在雲端？這些都是我們將要討論和試圖回答的問題，並且，我們會在需要時作出適當的建議。\u0026#xd;\n
文章的作者見到很多把應用系統遷移到雲上的挑戰，從「安全，到sla管理，到規約，到擔心廠商鎖定，到缺乏標準。」 儘管如此，他們認為條件成熟時應該利用雲的優勢，但是不要試圖把所有的東西都移植到雲端。
\u0026#xd;\n
作者鼓勵把應用系統遷移到雲端，他們認為有如下好處：
\u0026#xd;\n
把應用系統遷移到雲端可以從雲的彈性基礎服務中獲益，雲服務是一種快速、廉價、高效的策略方法。它提供了非常自然的切入點，以利用雲平台的價值，不需要任何大的間接費用。遷移很簡單，通常就像乙個簡單的託管練習，對應用系統的**影響很小或沒有影響。這會最大限度的降低遷移的風險，同時保持低成本執行。但是，必須指出，雖然雲提供了節省成本的方法，但它並沒有提供成本優勢（同時提供服務）去應對那些具備真正多租戶能力的競爭者。\u0026#xd;\n
zap think的jason blumberg贊同他們的觀點，他認為這種過渡需要雲架構：
\u0026#xd;\n
雲計算所承諾的商業利益和市場上產品的商業利益之間缺失的環節就是架構 ... 從企業的角度來說... 把雲應用到更為廣泛的企業it環境中是獲取其價值的核心。如何在現有的it環境中利用基於雲的資源去應對變化的業務需求？最佳實踐是什麼？這個問題的答案是雲架構，雲架構才是企業試圖去尋找的廠商中立雲策略中的缺失環節。\u0026#xd;\n
kothari和kumar認為讓這樣乙個架構落地是乙個「艱鉅的任務」：
\u0026#xd;\n
把系統遷移到saas架構並將其作為共享服務模式託管，這種方式可以為企業帶來真正多租戶的成本優勢。企業內有很多冗餘應用，這些冗餘的應用系統用來提供跨地域的類似服務，或是提供單一的多租戶應用的業務線，實現所有使用者的資訊共享。saas架構可以通過減少這些冗餘應用來合理化投資。但是，把現有的應用系統改造為saas架構可能是乙個艱鉅的任務 ...\u0026#xd;\n
janakiram msv在他與indicthreads.com的訪談中強調了重新架構系統以將其遷移到雲上的必要性：
\u0026#xd;\n
邁向雲的第一步就是著手重新架構你的應用系統，實現松耦合架構。web層，應用層和資料庫層之間不應該有任何交叉。雲的重要原則之一就是伸縮性，它可以按照客戶需求提供資源。你永遠不會知道應用的哪一層需要進行擴充套件。在某種情況下，你可能不得不擴充套件web層以滿足目前的交易需求。如果你發現中間層正在變成瓶頸，你就必須增加應用伺服器的數量，資料層也是同樣的狀況。鑑於這種動態的、按需分配資源的雲的特性，你應該把應用系統設計成即可以執行在單一伺服器環境，也可以執行在集群環境中。\u0026#xd;\n
blumberg和msv強調，遷移到雲上通常意味著soa和資料持久化是雲遷移的關鍵因素：
\u0026#xd;\n
遵循soa的原則你就向雲邁了一大步。另乙個關鍵是資料在雲上的持久化。有一些新的模式供你選擇，例如大字段（blob），佇列（queue）和靈活的實體（entity）...\u0026#xd;\n
雖然每個人都在談論關於雲的遷移，但有乙個問題很少被提出，那就是哪些具體型別的雲適合乙個給定的公司。此外，成功的雲計算實施需要哪種型別的應用系統進行重新架構，這一點尚不明確。
\u0026#xd;\n\u0026#xd;\n
檢視英文原文：
為雲應用重構系統
在soa世界的一篇文章 雲應用的遷移 中，chetan kothari和ashok kumar 了那些試圖把應用系統遷移到雲上的組織所面臨的挑戰 從邏輯角度而言，雲計算 是否是我下乙個成功實現商業策略的步驟？如果是的話，我的雲策略應該是什麼？哪種應用適合執行在雲端？這些都是我們將要討論和試圖回答的問...
CuteIE已重構為PIMShell，歡迎批評指正
cuteie是自己實現乙個瀏覽器，然後在裡面實現資訊管理的功能。重構後的pimshell是在ie中實現的資訊助理外掛程式，支援ie6 ie7 ie8。預覽圖 http www.pimshell.com screenshots tabid 58 default.aspx 演示 http www.pim...
什麼是系統重構
前面我們提到了，面對軟體工業時代的到來，我們的軟體企業陷入了一種更深的迷茫之中，一種 後有追兵，前有懸崖，進退兩難 的境地。後有追兵 面對維護了數十年之久的大型遺留系統，我們到底改還是不改？不改，面對越來越多的需求變更，我們維護的成本越來越高，變更變得越來越困難 面對不斷湧現的新技術，使我們的系統顯...