發行項
03/23/2017

本文章是由機器翻譯。

Windows Azure

將應用程式遷移到雲的技巧

George Huey

關於技術，最讓人著迷的一個方面就是它會不斷發展變化，讓人活到老學到老！作為雲計算的學生和追隨者，Windows Azure 平臺讓我們感到無比欣喜。作為 Microsoft 的技術推廣者，我們十分榮幸能與客戶一起工作以採用新技術。我們也因此見證了應用 Windows Azure 的許多不同方式。

以前，George 出於某種個人原因而想要使用 Windows Azure。George 投身參與許多社區活動，他發現，快速啟用臨時應用程式，並在不再需要這些程式時停用它們的能力被證明極為有用。對於具有 Microsoft .NET Framework 編碼經驗的開發人員，幾乎不需要任何學習過程：只需構建、部署然後運行應用程式即可。

由於我們的許多公司客戶都對 Windows Azure 表示出興趣，我們決定在 Microsoft 技術中心開展一系列 Windows Azure 遷移實驗。我們的初衷是讓客戶將他們的應用程式帶入實驗室，並將它們實際地遷移到 Windows Azure。通過這一過程，每個客戶都能夠將其 Web 應用程式和 SQL 資料庫成功遷移到 Windows Azure 平臺。

結果不出所料：我們掌握了有關 Windows Azure 的豐富經驗，並且有信心讓我們的客戶獲得成功。但是，在説明實驗參與者遷移其各種應用程式的過程中，我們學到了不少有助於順利遷移的技巧。在本文中，我們將分享我們在真實世界的遷移中與客戶合作時發現的一些技巧和竅門。

遷移基本知識

在決定將應用程式從內部部署遷移到雲（或基於雲服務創建新應用程式）時，需要考慮應用程式體系結構的以下幾個方面：

應用程式管理
應用程式安全性
應用程式相容性
資料庫相容性

我們在遷移實驗中最常聽到的問題和關注點就以這四個方面為中心。因此，我們將圍繞這些主題進行討論。

我們常遇到一種誤解，就是在使用 Windows Azure 遷移到雲或在雲中創建應用程式時，認為開發人員無需擔心常見體系結構模式的一些值得關注的問題，如可用性、可伸縮性、可靠性和安全性。事實上，構建的應用程式無論是進行內部部署還是 Windows Azure 部署，分散式運算上下文中的體系結構模式都同樣有效。

應用程式管理

無論您的應用程式在內部部署還是在雲中運行，操作管理團隊都需要一些資料來做出有效的決策。您將需要考慮一些問題，包括服務級別協定、容量計畫、客戶計費、審核、應用程式監視、流量分析和成本管理（知道何時升高或降低）。這些問題需要在將應用程式部署到生產環境中之前得到解決，而且往往最好在創建應用程式之前解決。

這些只是需要在 Windows Azure 遷移實驗中考慮的一部分問題。通過利用 Windows Azure SDK 中提供的 Windows Azure 診斷 API (Microsoft.WindowsAzure.Diagnostics)，客戶可以公開應用程式故障轉儲、失敗的請求跟蹤、Windows 事件日誌、IIS 日誌、Windows Azure 日誌以及效能計數器。

這遠比您的預期簡單得多。您告訴診斷監視器要收集哪些類型的診斷資訊（請參見圖 1 中的示例），並將這些資訊的資料傳輸計畫設置為傳輸到中央 Windows Azure 存儲位置。

图 1 设置诊断

public class WebRole : RoleEntryPoint {
  public override bool OnStart() {
    DiagnosticMonitorConfiguration config = 
      DiagnosticMonitor.GetDefaultInitialConfiguration();

    // To see which counters you can capture, type
    // "typeperf.exe /q" in a command window.

    // Capture CPU utilization.
    PerformanceCounterConfiguration procUtilization = 
      new PerformanceCounterConfiguration();
    procUtilization.CounterSpecifier = 
      @"Processor(*)\% Processor Time";
    procUtilization.SampleRate = 
      System.TimeSpan.FromSeconds(30.0);  
    config.PerformanceCounters.DataSources.Add(procUtilization);

    // Monitor available memory.
    PerformanceCounterConfiguration procAvailMemory = 
      new PerformanceCounterConfiguration();
    procAvailMemory.CounterSpecifier = @"\Memory\Avail MBytes";
    procAvailMemory.SampleRate = 
      System.TimeSpan.FromSeconds(30.0);  
    config.PerformanceCounters.DataSources.Add(procAvailMemory);

    // Add event collection from Windows Event Log 
    // (System and Application event logs).
    config.WindowsEventLog.DataSources.Add("System!*");
    config.WindowsEventLog.DataSources.Add("Application!*");

    // All of the information monitored so far is being stored locally. 
    // Tell diagnostic monitor what schedule period should be used when 
    // transfering the events. 
    config.Directories.ScheduledTransferPeriod = 
      TimeSpan.FromMinutes(1);
    config.Logs.ScheduledTransferPeriod = 
      TimeSpan.FromMinutes(1);

    // Start the diagnostics monitor.
    DiagnosticMonitor.Start("DiagnosticsConnectionString", config);

    // True gives full crash dumps. False gives small crash dumps.
    CrashDumps.EnableCollection(false); 

    System.Diagnostics.Trace.TraceInformation("OnStart Completed");

    RoleEnvironment.Changing += RoleEnvironmentChanging;

    return base.OnStart();
  }
...

有關 Windows Azure 診斷的更多資訊，請參見雲診斷：控制 Windows Azure 中的日誌記錄與跟蹤這篇文章（由 Mike Kelley 撰寫，發表在 MSDN 雜誌的 2010 年 6 月刊上）。

應用程式安全性

對於任何組織而言，遷移到雲時關注的首要問題就是安全性。大多數公司都已在設計和開發安全模型方面投入了大量的時間、財力和工程資源，因此讓它們能夠利用現有投資（如身份存儲、單一登入解決方案和防火牆）是十分重要的。

雖然公司可以採用許多種方式來保護基於雲的應用程式，但是一種基於聲明的方法已成為越來越流行的模式。

图 2 顯示了此過程。為使應用程式能夠處理來自安全權杖服務 (STS) 的安全權杖，必須在 STS 與應用程式之間建立信任關係。

圖 2 應用程式上下文中基於聲明的標識

將定義符合業務要求（即，哪些使用者可登錄到應用程式中）的存取控制規則（步驟 1）。這些規則與 STS 一起存儲。當使用者嘗試訪問應用程式時，他將被重定向到 STS，以便他能夠接收到有效權杖（步驟 2）。該使用者向 STS 提供一組輸入聲明（例如，Live ID 或域帳戶）以便進行身份驗證。該使用者通過身份驗證後，STS 將這些聲明映射到一組輸出聲明（步驟 3）。在步驟 4 中，輸出聲明將打包到安全聲明標記語言 (SAML) 權杖中，由 STS 簽名，並返回給使用者，以便轉發給應用程式（步驟 5 中的依賴合作夥伴）。應用程式確認該 SAML 權杖有效且來自可信 STS（步驟 6）。驗證權杖後，應用程式檢查權杖中的聲明，併發回適當的回應（步驟 7）。相當簡單！這種方法的優點是它非常適合用於 ASP.NET 提供程式模型。使您的 ASP.NET 應用程式變得能感知聲明的過程非常簡單。

為了讓開發人員的工作更輕鬆，Microsoft 引入了 Windows Identity Foundation (WIF) SDK。它能夠完成分析 SAML 2.0 權杖方面的所有繁重工作，讓開發人員能夠將精力集中于應用程式上，而不必擔心底層安全技術。

首先需要下载 WIF 和 WIF SDK。一旦將它們安裝好，您就已獲得讓應用程式感知聲明所需要的一切。

在包含您的 ASP.NET Web 應用程式的 Visual Studio 解決方案中，按右鍵並選擇“添加”|“添加新網站”。選擇“ASP.NET 安全權杖服務網站”範本。然後，您便可以為您的開發環境設置 STS。

在您創建 STS 之後，便可通過按右鍵您的應用程式並按一下“添加 STS 引用”添加對 STS 的引用。這將啟動一個嚮導，您可依照其指示逐步完成在應用程式與 STS 之間建立關係的過程。對您的網站，指向應用程式的 web.config 檔，並指定應用程式 URI（請參見圖3）。

圖 3 啟動聯合實用工具嚮導

在下一步中，選擇“使用現有 STS”，然後指定 STS 專案中 FederationMetadata.xml 檔的位置（請參見圖 4）。在此過程中其餘部分中選擇預設設置。

图 4 配置 STS

請看一下 web.config 檔。您將看見 FedUtil.exe 嚮導更改了大量的代碼。最重要的更改是對 web.config 檔的 microsoft.identityModel 節點做出的。您將在此處看到對 STS 專案的引用，以及應用程式所需要的聲明類型。為了確保您的應用程式能夠相應地接收到從 STS 返回的聲明，請將以下代碼放入 default.aspx 頁面（請注意，您將必須從 WIF SDK 添加對 Microsoft.IdentityModel 的引用）：

IClaimsIdentity ici = 
  (IClaimsIdentity)Thread.CurrentPrincipal.Identity;

foreach (Claim c in ici.Claims) {
  Response.Write(c.ClaimType + " - " + c.Value + "<br/>");
}

接下來，當您運行應用程式時，會自動將您重定向到您的 STS。預設情況下，STS 將允許您作為“Adam Carter”進行身份驗證。您只需按一下“登錄”按鈕即可（無需密碼）。

STS 對登錄進行身份驗證之後，您就會重定向回您的 Web 應用程式，並獲得身份驗證需要的 SAML 權杖。您的應用程式將接受該權杖，並允許 default.aspx 頁面運行。因為 WIF 模組將攔截您的安全憑據，您將能夠把標識主體強制轉換為 IClaimsIdentity，因而還能夠從標識物件提取出聲明類型和值（請參見圖 5）。

圖 5 標識物件的聲明類型和值

現在 Web 應用程式已能感知聲明，因此它很容易適應現有標識模型。只需更新您的設定檔，讓它指向您的生產 STS，並確保您已將應用程式配置為依賴方。此外，您還可以使用此資訊來創建自訂角色提供程式，以便將聲明類型轉換為角色。

這是一種極為強大的方法，通過這種方法，您能夠把應用程式遷移到幾乎任何環境 — 內部部署環境、雲環境甚至合作夥伴資料中心，並且仍然可通過公開的 STS 對標識存儲進行驗證。

應用程式相容性

Windows Azure 是一個應用程式平臺，因此瞭解適合 Windows Azure 平臺的應用程式類型很重要。雖然您能夠運行本機代碼，並且能以完全信任級別運行應用程式，但您必須在將應用程式部署到雲之前把它打包，這就是說，評估應用程式是否合適很重要。

例如：我們在 Windows Azure 遷移實驗室的一個客戶有一個在 IIS 上運行的現有應用程式，它由一個 SQL Server 2005 後端、一個 LINQ to SQL 資料訪問層以及一個使用 MVC Framework 1.0 和 ASP.NET 3.5 SP1 的前端組成。

該應用程式位於一個含有傳送流量的負載平衡器的 Web 場中。該應用程式本身是沒有狀態的，因此，使用者最終定向到哪個伺服器無關緊要。

一個與此應用程式有關的有趣細節是：該 MVC 應用程式管理著超過 220 個獨立的網站。該公司結合使用 MVC 路由和存儲在 SQL Server 資料庫中的資訊來確定應該對每個網站載入哪些內容。對於這些網站的集合，在負載平衡器背後，有五個 Web 伺服器每月對超過 4 百萬個頁面訪問提供服務。

該公司面臨的主要挑戰是為其環境提供新 Web 伺服器所需要的時間：長達數月！months當該公司考慮將應用程式遷移到 Windows Azure 時，其主要動機是節省大量的時間。向外擴展將成為一個配置細節，而不是持續整個季度的噩夢。

遷移到 Windows Azure 的過程實際上相當簡單。下麵就是我們使用的一般過程：

驗證應用程式是否在開發環境中正常運行。
使用“SQL Azure 遷移嚮導”將 SQL Server 後端遷移到 SQL Azure（我們將在本文稍後部分詳述）。
更新本地應用程式，使之使用 SQL Azure 資料庫。這個過程非常簡單，只需改一下連接字串即可。
將應用程式轉換為“Web 角色”專案。
驗證應用程式是否在本地開發結構中運行。
將“Web 角色”打包，並將它部署到 Windows Azure。
驗證應用程式是否可從 Windows Azure 運行。

為了縮小“Web 角色”包的大小，我們最後將所有圖像和 CSS 檔從它們的內容資料夾中取出，並把它們放入 Windows Azure Blob 存儲空間。

因為所有內容都在 Windows Azure Blob 存儲空間中，GGP 便可以利用 Windows Azure 內容傳送網路 (CDN)。這樣，資料緩存能夠更接近于最終使用者。

有關開發、測試和部署 Windows Azure 的概述，請參見 Windows Azure：在 Visual Studio 2010 中開發和部署 Windows Azure 應用程式這篇文章（發表于 MSDN 雜誌 2010 年 4 月刊）。若要更深入地瞭解存儲問題，請參見雲存儲：使用 Windows Azure 存儲增強應用程式的引擎（發表于 2010 年 1 月刊）。

資料庫相容性

在 SQL Azure 出現之初，我們就將我們的幾個 SQL Server 資料庫遷移到了其中。再加上我們運作 Windows Azure 遷移實驗室的經驗，我們學到了您在開始遷移過程之前應該考慮的很重要的幾件事。

首先，需要檢查資料庫的大小以及它是否符合 SQL Azure 使用的資料庫限量範圍，這很重要。目前，SQL Azure 提供 1GB 和 5GB 大小的 Web Edition 以及 10、20、30、40 和 50GB 大小的 Business Edition。您需要檢查您的資料庫並確保它的大小不超過 50GB。如果您的資料庫大於 50GB，則需要檢查該資料庫是否可以拆分為較小的資料庫（換句話說，將資料庫分片）或者將大資料移至 Blob。

SQL Azure 僅支援 SQL 身份驗證，因此您需要考慮是否需要更改您的應用程式所使用的身份驗證方案。另外，SQL Azure 還有一個限制連線時間的資源限制。我們稍後將在本文中討論這兩個問題。

您的 SQL Server 資料庫的版本是在將資料庫遷移到 SQL Azure 之前需要考慮的另一個問題。SQL Azure 是基於 SQL Server 2008 構建的。這就是說，如果您想將 SQL Server 2000 或 SQL Server 2005 資料庫遷移到 SQL Azure，則需要確保您的資料庫與 SQL Server 2008 相容。例如，SQL Server 的早期版本支援舊式的 TSQL 聯接，如 WHERE 子句中的 *= 和 =* 運算子。SQL Server 2008 僅支援 ANSI 式樣的聯接。例如：

SELECT ProcessClassTypeName
       , bpa.PropertyMetadata AS PropertyMetadataOverride
       , act.PropertyMetadata AS PropertyMetadataDefault
  FROM dbo.BusinessProcessActivities bpa
  LEFT JOIN dbo.Activities act ON act.Activity_ID = bpa.Activity_ID

當資料庫的相容性級別設置為 SQL Server 2005 或 SQL Server 2008 時，不支援舊式 TSQL 聯接（*= 和 =*）。這只是您在遷移到 SQL Server 2008 時會發現的相容性問題的一個示例。

詳述遷移到 SQL Server 2008 的過程超出了本文的範圍。如果您對資料庫遷移最佳實踐感興趣，請查閱升級到 SQL Server 2008 的終極指南。在 MSDN SQL Server 開發人員中心也提供了豐富的資源。

您將發現最好的途徑是從與 SQL Server 2008 相容的資料庫遷移到 SQL Azure。這就是說，如果您想將 SQL Server 2000 或 2005 資料庫遷移到 SQL Azure，則可以在遷移到 SQL Azure 之前進行到 SQL Server 2008 的內部升級。

Microsoft 提供了一個名為 SQL Server Upgrade Advisor 的出色工具，該工具分析 SQL Server 2000 和 SQL Server 2005 的實例，以識別可能會影響升級的功能和配置更改。它提供了指向一個文檔的連結，該文檔描述識別出的每個問題並說明如何解決這些問題。一旦您已驗證您的資料庫與 SQL Server 2008 相容，便可以快速將資料庫遷移到 SQL Azure。

雖然如此，您還需要知道，SQL Azure 並不支援所有的 SQL Server 2008 新功能。例如，目前在 SQL Azure 中不支援檔流。在遷移到 SQL Azure 時，有幾種方式可以檢查相容性問題。

粗暴的方法就是瘋狂測試：對 SQL Azure 運行您的 TSQL 腳本並查找錯誤。更正出現的所有錯誤，再次運行。重複此過程，直至成功。這樣做可能並不能最好地利用您的時間，但這由您決定。

您可以使用 SQL Server Management Studio 腳本生成器嚮導來生成 TSQL 腳本。請注意，當您根據嚮導指示逐步執行操作時，請確保選擇高級腳本編寫選項，並對“資料庫引擎類型的腳本”屬性選擇 SQL Azure 資料庫。如果您錯過這個步驟，則 SQL Server 將生成與 SQL Azure 不相容的 TSQL。

另一個選擇是從 sqlazuremw.codeplex.com 下載 SQL Azure 遷移嚮導 (SQLAzureMW)。SQLAzureMW 將盡力識別相容性問題，盡可能解決這些問題，並將它所瞭解的所有問題都通知給您。

要更好地理解 SQL Azure 的一般指導原則和限制，請參見 msdn.microsoft.com/library/ee336245。

一旦您在 SQL Azure 中擁有了資料庫架構（表、視圖、存儲過程等），您將需要上載您的資料。下麵是最常見的方法：

SQL Server Integration Services
大容量複製程式 (BCP)
用於資料移轉的 SqlBulkCopy
SQL Azure 遷移嚮導（在後臺使用 BCP）

使用 SQLAzureMW

George 創建了 SQLAzureMW 來説明我們的客戶完成 SQL 資料庫遷移過程。图 6 顯示了運行中的 SQLAzureMW。

圖 6 使用 SQLAzureMW

SQLAzureMW 分析 SQL Server 資料庫是否存在與 SQL Azure 的相容性問題。它還允許您將資料庫物件和資料從來源資料庫遷移到 SQL Azure。

通過使用 SQLAzureMW，資料庫開發人員可以瞭解在將其資料庫遷移到 SQL Azure 時將需要執行多少工作。如果 SQLAzureMW 標記出與 SQL Server 2000 或 2005 資料庫的許多相容性問題，我們建議首先將您的資料庫升級到 SQL Server 2008，然後再遷移到 SQL Azure。已有很多文獻說明遷移到 SQL Server 2008 的過程，您可以利用大量的指導和專業意見。有關遷移到 SQL Server 2008 的更多資訊，請參見 SQL Server 2008 升級技術參考指南 (microsoft.com/downloads/details.aspx?FamilyID=66d3e6f5-6902-4fdd-af75-9975aea5bea7)。在 MSDN SQL Server 開發人員中心 (msdn.microsoft.com/sqlserver) 也提供了豐富的資源。

請注意，如果您沒有 SQL Server 2008 R2，則您可以繼續升級過程，而並不會因此受到影響。只需下載 SQL Server 2008 R2 Express Edition，並執行並行升級過程即可。

還有其他一些較好的資源可以説明資料庫開發人員瞭解 SQL Server 與 SQL Azure 之間的區別，比如哪些部分相容和哪些部分不相容，以及一般指導原則和限制等，這些資源包括 msdn.microsoft.com/library/ee336281 處提供的 Transact-SQL 參考（SQL Azure 資料庫）以及 msdn.microsoft.com/library/ee336245 處介紹的一般指導原則和限制。

無論您是決定首先升級到 SQL Server 2008 還是直接從 SQL Server 2000 或 2005 進行遷移，您都需要使用合適的方式來分析資料庫的相容性問題並生成與 SQL Azure 相容的 SQL。這就是 SQLAzureMW 的真正用武之地。SQLAzureMW 不僅能分析資料庫，在您想檢查動態 SQL 的相容性問題時，它還會分析 SQL Profiler 跟蹤檔。

在遷移實驗中，只需要極少修改，或根本無需修改，我們就能夠將所有 SQL 資料庫（SQL Server 2000 和 SQL Server 2005）遷移到 SQL Azure。剩餘的兩個需要解決的問題是身份驗證和 SQL Azure 資源限制。

身份驗證問題是由於 SQL Azure 僅支援 SQL 身份驗證而不支援 Windows 身份驗證所致。以我們的一個客戶為例，這個客戶必須修改連接字串以反映使用者名和密碼而不是可信連接。例如，我們一開始看到了如下內容：

<add key="ConStr" 
  value="server=DbSvr;database=CRMDB;Trusted_Connection=yes" />
We simply changed the connection string to something like this:
<add key="ConStr" 
  value="Server=avl6qnn22s.database.windows.net;Database=CRMDB;User ID=WebSvrAdmin@avl6qnn22s;Password=password;Trusted_Connection=False;" />
To get more information on connecting to SQL Azure using ADO.NET, see msdn.microsoft.com/library/ee336243.

資源限制

對於一些應用程式而言，解決 SQL Azure 資源限制需要執行的工作略多一些。有些應用程式採取僅當需要時且盡可能拖延到最後時刻才連接到 SQL 資料庫這樣的最佳實踐，這些應用程式可以快速高效地執行所有事務並儘快釋放連接，因此 SQL Azure 限制就不成為問題。相反，有些應用程式在啟動時就建立與 SQL 資料庫的連接，並在程式的整個生存期內或長時間持有連接，這些應用程式必須進行修改以實現重試邏輯，或進行重構以採取最佳實踐並且不佔用資源。

我們經常遇到一種誤解，就是認為 SQL Azure 僅當連接空閒五分鐘後才會斷開連接。SQL Azure 在確定何時斷開應用程式連接時要考慮幾個因素，包括過度的資源佔用、長時間運行的查詢、長時間運行的單一事務以及空閒連接。

SQL Azure 團隊將繼續調整資源限制參數，但實際效果是應用程式必須在其自身中構建重試邏輯，因為 SQL Azure 將強制超過其資源利用參數的任何應用程式斷開連接。

一般來說，如果 SQL Azure 對連接做出限制，它會提供特定的錯誤消息。有關錯誤的完整清單，請參見 msdn.microsoft.com/library/ff394106。

如果您有大量小事務，則應使用以下模式：

使用連接池。連接池管理器將為您把連接保持為打開狀態，並且打開和關閉連接對應用程式性能的影響將很小或根本無影響。
盡可能縮短連接持續時間。打開連接，執行您的事務，關閉連接。
對整個資料庫活動使用 try-catch 模式。
如果合適，捕獲異常並重試事務。
記錄您的故障和異常，以説明解決問題。確保獲取 UTC 時間戳記（或提供時間和時區）、連接上下文 ID 和異常編號。

SQLAzureMW 就是必須處理 SQL Azure 中的資源限制的一個典型應用程式。如前所述，SQLAzureMW 可以將內部部署 SQL 資料庫遷移到 SQL Azure。如果您要遷移包含超過 1,000 個表、1,500 個存儲過程和成百萬行資料的資料庫，則根據實際需要上載的資料量，花費的時間很可能要超過五個小時。

在這種情況下，SQLAzureMW 可以對 SQL Azure 以及要通過 BCP 遷移的資料執行超過 2,500 條的 TSQL 語句。在一條語句（或一個事務）中執行超過 2,500 條 TSQL 語句很可能會超出 SQL Azure 資源限制參數，從而導致連接終止。

SQLAzureMW 就是針對此問題的解決方案，它將事務分成較小的塊，並一直運行，直至 SQL Azure 終止連接。SQLAzureMW 在遇到連接錯誤時，將與 SQL Azure 重新建立新連接，並接著最後一條成功的命令繼續執行處理。同樣，當使用 BCP 將資料上載到 SQL Azure 時，SQLAzureMW 將資料分塊成較小的部分，並使用重試邏輯算出連接被關閉之前最後一條成功上載的記錄。然後，它讓 BCP 重新開機包含下一組記錄的資料的上載。

自從 SQL Azure 首次發佈以來，SQL Azure 產品團隊已對 SQL Azure 作出了巨大的改進。例如，我們在遷移實驗室中遇到的大量限制問題都已得到解決，但我們仍然建議您的應用程式使用重試邏輯妥善處理終止的連接。

後續步驟

如您所見，雖然在計畫平穩的 Windows Azure 遷移時您需要考慮很多問題，但我們在實踐中發現，將應用程式從內部部署遷移到 Windows Azure 所需執行的工作量通常極少。當然，對於每個應用程式，情況都有所不同。

您需要執行自己的分析來確定遷移到 Windows Azure 是否有意義以及您需要解決什麼問題。在 Windows Azure 遷移實驗室中，我們的客戶發現，只需對應用程式做微小修改或根本無需修改，他們就能夠遷移其應用程式，並且，他們只需很短的學習過程和很少的投資，便可利用 Windows Azure 平臺。此處的資訊以及像 SQLAzureMW 這樣的工具應該能説明您獲得同樣成功的結果。

George Huey 是 Microsoft 開發人員平臺推廣小組的首席架構師。Huey 與一些公司合作，説明它們瞭解新興的技術以及如何應用這些技術來解決其業務問題。他還是“SQL Azure 遷移嚮導”(SQLAzureMW) 的編寫人。

Wade Wegner 就職于 Microsoft，是 Windows Azure 平臺的技術推廣專家。您可以通過他在 blog.wadewegner.com 的博客和在 twitter.com/wadewegner 的Twitter 與他取得聯繫。

衷心感謝以下技術專家對本文的審閱：Jim Nakashimi

共用方式為