顛覆傳統應用程式架構的雲端運算平台
微軟雲端平台Azure粉墨登場
文／圖 彭靖灝．責任編輯／洪羿漣

微軟於2009年度PDC(Professional Developers Conference)大會上宣佈，Azure將於2010年1月1日推出正式版，並預計於2010年開始收費機制，究竟它提供了什麼樣的服務？安全性如何？對企業與開發者有什麼意義？請看本專題報導中的詳盡說明。

---

還記得在2008年的微軟開發人員大會(PDC)中，微軟首度正式公佈了微軟的雲端運算平台的計劃─Windows Azure。在這個計劃中，除了涵蓋作業系統平台之外，也一舉把已經公開的SQL Service，和規劃中以SharePoint技術為中心的站台服務都納入到整個平台當中，提供應用程式執行、資料儲存和辦公室訊息分享應用等作業服務。

當時大會也史無前例的宣佈2009年將再辦一場PDC，打破過往PDC多年才舉辦一次的慣例。官方的理由是未來一年的變化很多，技術上的創新也會很多，為了讓開發人員充份掌握微軟的藍圖，所以必須緊接著再辦一次。

而一年後再參加PDC，就發現這些安排背後其實有相當縝密的規劃。PDC 2009的主軸完全以Azure平台為中心，各個相關的服務面貌清晰，一付整裝待發的模樣。而相較於微軟其他的技術盛會(TechEd、MIX…)，似乎只有PDC才是最適合完整交待Azure的場合。其中除了交待Azure平台的計費模式和相關時程，同時一些過去以代碼相稱的平台或技術，也都有了明確的產品名稱和技術細節。


Azure技術架構與開發套件
在正式揭櫫的Azure平台中，所有雲端運算相關的技術服務，都被統一在這個平台下，所以原名SQL Service的資料庫服務，也正式更名為SQL Azure。就整個Windows Azure平台來看，基本上是由一組雲端的技術構成，每一個技術都提供特定的服務給應用程式開發人員，在雲端或本地端上執行。(圖1)

圖1 Azure平台的基本架構。

整個Azure平台的成員包括了：
●Windows Azure：在微軟的資料中心內，提供以Windows技術為基礎的應用程式執行，及資料儲存作業環境。
●SQL Azure：以SQL Server為基礎在雲端提供資料儲存服務。
●.NET Service(AppFabric)：提供分散式架構的作業服務給雲端環境和本地環境的應用程式。

基本上，Windows Azure就是一個雲端作業系統，提供執行雲端應用程式的一切服務。開發人員可以利用熟悉的技術，開發在這個平台上執行的應用程式或軟體服務，並且儲存資料在此環境中。

圖2 Windows Azure的成員。

從圖2中可以看到，整個Windows Azure是由一堆的伺服器組合而成，這些伺服器都是位在微軟的資料中心內，並且透過網際網路供外界存取。這些個別的伺服器環境，透過一個稱做「Fabric」的成員，將運算能力集合在一起，構成一個完整的整體。

而Windows Azure的運算和儲存服務，就是架構在這個fabric之上。每一台伺服器上自然是執行Windows作業系統，實際上提供使用者服務的，則是個別的虛擬機器，這些虛擬機器構成了隔離作業系統執行環境，及動態增加運算能力的基礎。

在原本的設計中，Windows Azure只允許執行以.NET Framework為基礎的應用程式，如今也有些變化。開發人員可以利用Visual Studio 2008或其他開發工具，以C#、Visual Basic、C++等程式語言開發執行在Windows Azure上的應用程式。這些應用程式可以是以ASP.NET及WCF(Windows Communication Foundation)建立的Web程式，或是一個跑在背景環境執行的軟體服務，透過Web服務的形式提供運算能力給本地的應用程式，或者是結合這兩種形式的應用系統。

不論是在Windows Azure上或是在本地環境的應用程式，都可以取用Windows Azure的儲存服務，方式是透過REST協定。這個資料儲存環境，並不是以Microsoft SQL Server為基礎，這裡的資料儲存服務，並不是一個關聯式的系統，也不是以SQL語言進行查詢動作。

它比較是一個接近程式語言中，像群集、物件概念的作業架構，讓我們可以儲存BLOB(Binary Large Bbject)；或是透過佇列的方式，在Windows Azure 程式中的元件進行溝通；或者是採用較過去簡單的查詢語言，處理類似資料表的儲存內容。

其實這件事並不難理解，想像一下在沒有安裝SQL Server的Windows環境中要如何儲存資料？無非是透過記憶體、檔案、MSMQ等技術。對於雲端環境，可分散在不同伺服器上供存取的檔案處理方式是個大挑戰，所以排除掉檔案的型式，剩下的就是記憶體和Windows的MSMQ服務了。

就記憶體的角度，一個是當做物件儲存，一個就是利用像ADO.NET中的DataTable類別，來儲存結構化的資料。基本上Windows Azure的資料儲存服務，就是在雲端提供這樣的作業環境。如果我們真的需要關聯式的資料儲存環境，那就得要藉助SQL Azure 的服務了。

在雲端的環境執行應用程式和儲存資料能夠帶來什麼樣的效益？最顯而易見的，就是避開了購買、安裝和維護整個運算系統的負擔，而是由雲端環境供應商來處理，提供更低的進入門檻(特別是從成本的角度來看)。客戶支付的費用是以有使用的部份為基礎計算，不用考慮到閒置成本。而且若應用系統設計得當，擴展使用規模也會變得相當容易。

在Windows Azure中，這些安排都可以透過配置檔案的改變來達成。不論是透過人工的方式，或是透過工具程式調整與控制這些配置，應用系統的所有人都可以輕易操作這些作業行為，像是指定Windows Azure執行實例的個數。Windows Azure的Fabric會監視這些應用程式維持預期的狀態。


可能應用的場景
透過Windows Azure建立執行在雲端環境的應用程式，以下3種應用的場景可供參考：

●新成立的公司：它可能在Windows Azure上建立新的網站，並提供使用者操作介面，來使用這家公司在網站提供的應用或服務。該公司也可能在透過這個網站，建立在背景執行的應用服務，透過像web service之類的協定供遠端的程式取用。對於這家新創立的公司而言，它不需要花費時間和金錢在資訊系統的基礎建設上，而是把精神專注在應用程式的開發，以期儘快為客戶或投資人帶來價值。由於公司創立初期客戶數量不多，相對花費也不多。一旦使用者的數量增加，或是應用系統的負荷量增加，Windows Azure可以在規模上做出調整，支持更大的運算能量。

●獨立軟體開發商：可能以既有在Windows環境上的私有版本為基礎，建立一個軟體服務化(SaaS)的新版本，執行在雲端的環境上，提供給客戶另一種選擇。新版本就可以直接建構在Windows Azure上，因為它提供的就是一個標準的Windows環境，既有的應用程式邏輯可移植到這個雲端運算平台上繼續運作，省下過去在基礎設施上投資的時間和金錢。

●一般企業：由於Windows Azure支援.NET技術，要在市場上找到具備足夠技能的開發人員並不困難，代價也不會太高。而利用微軟的資料中心執行應用程式，也讓企業可省下管理自有伺服器的費用和責任，將原本的資本支出轉為日常營運支出。特別是在一些可能會有淡旺季區別的應用上，透過微軟來維護龐大的伺服器環境，去滿足一些尖峰時期的需求，也是相對較符合經濟效益的做法。

上述只是幾個典型的應用，當然Windows Azure所提供的潛能不止於此。新型態的應用模式，很可能隨著Windows Azure正式推出，成為開發人員的一個選項時逐漸浮出檯面。


SQL Azure的演變
透過網路上的伺服器取用服務，最吸引人的一點就是在資料處理方面。早期的應用是透過電子郵件儲存訊息，或透過線上的檔案系統儲存檔案、相片。之後網路提供應用系統蔚為風潮，系統的結構化資料也開始從私有環境的伺服器開始向網路上移動。SQL Azure的主要目標就是朝這個領域前進，提供以雲端運算為基礎的架構下儲存結構化資訊的能力。

在微軟的計劃中，SQL Azure將會涵蓋相當廣泛的資料導向服務能力。除了標準的資料儲存處理之外，還包括了報表應用、資料分析等服務。首發版本中，將會提供的成份包括SQL Azure資料庫，及代號「Huron」的資料同步能力。(圖3)

圖3：SQL Azure成員。

SQL Azure Database(之前叫做SQL Data Services)在雲端環境提供了一個資料庫管理系統。這個技術允許在私有和雲端環境的應用程式，都能在微軟資料中心內的伺服器上儲存關聯式或其他類型的資料。如同其他的雲端技術，公司或是組織僅需就使用到的資源付費，隨著組織需求的變動，此成本也可以跟著調整。使用雲端資料庫也可以將資本支出(例如採購硬碟、資料庫產品)，轉變成日常的營運支出。

不同於Windows Azure儲存服務是以記憶體和檔案系統等服務為基礎，SQL Azure資料庫則是架構在SQL Server之上。原本在2008年推出的預覽版中，SQL Azure資料庫的運用和處理，就已經不同於傳統的關聯式架構。

而經過一年的淬鍊，微軟聽取了許多客戶的意見後，SQL Azure資料庫也做了改變，改為提供關聯式架構，並且可直接利用SQL Management Studio進行管理的工作，所有熟悉的索引、檢視、預存程序、觸發程序都會提供，讓開發人員能沿用既有的資料庫處理技能(像是ADO.NET或其他Windows的資料存取介面)。因此現今依賴SQL Server執行的應用程式，在資料庫存取這一層，就可以較為平順地轉移到SQL Azure資料庫。客戶也可以利用私有環境中的SQL Server Reporting Services，來取用位在雲端的資料庫內容。

一旦應用程式能夠像本地端系統般取用SQL Azure資料庫元件，管理上的負擔就能夠大幅降低。對於SQL Azure資料庫的客戶而言，可以不需要把心力花費在磁碟空間或記錄檔的監控，而可以專注在處理資料本身；管理營運上的細節就交由微軟來操心。如同在Windows Azure平台上一樣，使用SQL Azure資料庫的方式相當直接，透過一個在Web上的入口網站進行管理的作業就行了。


資料同步技術
SQL Azure的第二個成員是代號「Huron」的資料同步技術。該技術是以Microsoft Sync Framework及SQL Azure資料庫為基礎，將關聯式資料同步到其他私有環境中的資料庫系統。資料的所有人可以決定那些資料要進行同步，如何處理衝突等。
對應用程式而言，使用SQL Azure的方式可能有以下的應用環境：
●當Windows Azure所提供的儲存空間、關聯式資料表不適合應用程式時，可以選擇儲存它的資料在SQL Azure資料庫中。由於多數既有的應用程式採用關聯式儲存系統，而且多數開發人員都已熟悉如何運用，所以可能會有不少Windows Azure應用程式會傾向使用SQL Azure。
●無論企業環境大小，應用程式可以使用SQL Azure資料庫，與其把資料儲存在某台SQL Server或Access資料庫，考慮雲端運算環境的可靠度和可用性。
●製造商想要將商品的資訊同時提供給經銷商和客戶，就可以考慮把資料存放在SQL Azure，供執行在經銷商處的應用程式，以及製造商本身提供給客戶取用的Web應用程式使用。

對於資料庫散佈在不同地區的公司而言，可以利用「Huron」同步服務，來確保各地的複本是處於同步的狀態，由於執行效能的考量，各地區或許都需要一些各自的複本來保證作業的可用性，自動同步即可讓這樣的資料分佈狀況持續運作，並確實達成執行效能需求或其他目的。


AppFabric
在雲端環境執行應用程式及儲存資料，對於雲端運算而言都是相當重要的層面。不過這不代表整件事情的全部，另一個部份是提供以雲端為基礎的基礎設施服務，供私有環境或雲端環境的應用程式取用。在Azure平台中，提供這部份作業的就是AppFabric。

AppFabric最早的名稱是BizTalk Services，之後又改名為.NET Services。然而隨著同樣的作業服務，不論是在雲端或私有的作業環境，它都扮演相當重要的角色。所以微軟將整個功能統一在一致的架構下，並改名為AppFabric，同時在雲端和傳統Windows平台上，都提供對應的產品。

在雲端的環境，提供的AppFabric Servcice；在Windows的環境，則是AppFabric Server。在這個段落，我們先做簡略的介紹，後面我們會再做更深入的討論，因為它在整個Azure平台中扮演相當樞紐的角色。AppFabric Service主要是處理一些在基礎建設方面的挑戰以利分散式應用程式的建立。(圖4)

圖4：AppFabric Service成員。

對於雲端運算的環境而言，身份辨識是很重要的一環。而通用的做法，是提供應用程式一個辨識用的token，在此token中包含有一些聲明(claims)。應用程式可以基於這些聲明決定使用者能進行的工作。而為了讓辨識身份能跨越不同的應用程式，這時就需要辨識身份聯盟(identity federation)的機制，使得在某個辨識身份適用範圍中，建立的聲明能夠傳遞到另一個適用範圍提供辨識。

在這個機制中可能需要進行聲明轉換的動作，在傳遞聲明時進行一些修改，以符合其他適用範圍的需要。圖中的存取控制服務(Access Control)就是在雲端的環境提供這樣一個能力。而這個存取控制服務的作業方式，可以用圖5來表示。

圖5：AppFabric存取服務作業。

而要將應用程式的服務發佈到網際網路的環境，其難度可能超過一般人的想像。圖5中的Service Bus就是為了簡化這個作業，讓應用程式可以更輕鬆的發佈Web services端點供其他的應用程式取用，而這些應用程式可以執行在私有環境或是雲端的環境。

每一個對外公開的端點都會被指定一個URI，前端應用程式可以透過它找到服務並進行存取。Service Bus同時也會處理網路地址轉換，以及在不需要為應用程式提供新的通訊埠的情況下通過防火牆等重要工作。從圖6我們可以看到，Service Bus會協助處理訊息的傳遞和服務端點的轉換。

圖6：AppFabric Service Bus。

我們要如何應用.NET Services，有一些使用場景可參考：
●提供應用程式給不同公司的客戶，使用的ISV可能利用存取控制服務，來簡化應用程式的開發及運作工作。舉個例子，每一家客戶可能在內部是使用不同的身份辨識技術，而它可以轉譯使用在不同客戶環境的聲明成為一組一致的內容，讓ISV的應用程式能夠處理。這樣一來就把身份辨識的工作轉移到雲端存取控制服務提供的辨識身份聯盟，而不需要ISV自己去建立一套聯盟的機制。
●假設一個企業想要讓它的交易夥伴使用的軟體能存取應用程式，可以把這個程式的功能透過SOAP或REST型式的Web services發佈，然後將這個端點註冊到Service Bus中。它的交易夥伴可以利用Service Bus找到這些功能的端點，並存取服務。由於這項作業不需要在組織內的防火牆中開啟新的通訊埠，就減少了曝露應用程式產生的風險。該公司也可能同時使用存取控制服務，配合Service Bus來處理這些服務時，由交易夥伴應用程式提出的身份辨識資訊。


Azure平台開發套件
對開發人員而言，要開發在Azure平台上執行，必須安裝相關的開發套件。而基本開發環境則要符合以下的需求：
●支援作業系統：Windows 7、Windows Server 2008、Windows Vista SP1。
●IIS 7.0(要安裝ASP.NET、WCF HTTP Activation，可選擇性加入CGI的支援)。
●Microsoft Visual Studio 2008 SP1、Visual Studio 2010 Beta 2或Visual Web Developer 2008 Express Edition with SP1。
●SQL Server 2005 Express Edition(或之後版本)。
●KB967631，Hotfix:Native Debugging Improvements(針對Visual Studio 2008，Visual Studio 2010不需要)，http://code.msdn.microsoft.com/KB967631。
●KB963676，Hotfix:Improve Visual Studio Stability(Windows 7不需要)。https://connect.microsoft.com/VisualStudio/Downloads/DownloadDetails.aspx?DownloadID=16827&wa=wsignin1.0。
●KB967631，Hotfix: Support for FastCGI on the Development Fabric (Windows 7或Windows Server 2008 SP2 之後版本不需要)，http://support.microsoft.com/kb/967131。

要熟悉Windows Azure的開發技術，可以參考微軟提供的自學工具，下載的網址為：http://www.microsoft.com/downloads/details.aspx?FamilyID=413E88F8-5966-4A83-B309-53B7B77EDF78&displaylang=en。而開發工具套件可以安裝在Visual Studio 2008或Visual Studio 2010 Beta 2的環境中，下載的網址為(2009年11月發佈的版本)：http://www.microsoft.com/downloads/details.aspx?FamilyID=6967ff37-813e-47c7-b987-889124b43abd&displaylang=en。

除了安裝Azure的開發工具之外，我們同時也要申請一個開發的token，做為在Windows Azure上建立應用程式，使用雲端資源的辨識身份。相關的登記訊息可以在Windows Azure開發人員的頁面上找到：http://www.microsoft.com/windowsazure/getstarted/。如果要使用SQL Azure的服務，和Windows Azure要另外申請使用token，相關資訊同樣參考Windows Azure的開發人員網頁。

同樣的，要使用到AppFabric的服務，可以下載安裝Windows Azure platform AppFabric SDK：http://www.microsoft.com/downloads/details.aspx?FamilyID=39856a03-1490-4283-908f-c8bf0bfad8a5&displaylang=en。然後到AppFabric開發者中心申請使用token：https://netservices.azure.com/SignUp.aspx。 上述這些服務帳戶的申請都需要結合Windows Live ID，一旦建立了連結，就可以透過同一個Live ID存取所有你申請的服務了。


AppFabric Service Bus架構
對於大型的分散式應用程式而言，相當常見且重要的需求之一，是應用程式之間的連結能力。事實上，應用程式的整合常常是資訊技術領域成本最高的一塊。對於許多公司而言，很可能是透過建立一個企業匯流排(ESB)解決方案來解決這方面的問題。

在AppFabric中的Service Bus，主要就是想讓這一個企業匯流排的作業模式能在網際網路的環境中實現，成為Windows Azure平台的一員。Service Bus提供了許多在現今ESB解決方案中可以看到的特性，包括身份辨識和存取控制、命名、服務註冊，以及訊息傳遞通道。

它和傳統ESB解決方案的主要區別，在於適用範圍。在Service Bus中，所有設計的元件都必須在雲端的環境中執行，所以適用範圍是網路環境，牽涉到的也是需要能彈性調整規模和建立聯盟的能力。

透過這個服務匯流排，我們有機會整合企業內私有環境的ESB產品，以及在雲端執行的服務，甚至是其他第三方提供的服務、不同的前端作業環境及應用程式，提供一個整體的能力。(圖7)

圖7：AppFabric Service Bus架構圖。

為了實現這個目的，AppFabric必須考量到各種開放的網路協定和豐富的訊息處理能力，並且在網路上提供雙向通訊的能力。而由於像防火牆或是特殊網路設計的存在，讓這個雙向溝通的要求顯示分外複雜，AppFabric Service Bus的目標之一，就是降低企業在這方面的障礙，透過一個在網路上的中介服務，降低整合的障礙。

基本上，AppFabric Service Bus提供了以下幾個能力來提高企業服務整合的能力：
●Relay Service：透過集中轉派的機制，讓低階的訊息封包可轉送到正確的對象，以便讓一些利用低階協定作業的應用程式，能順利進行雙向溝通。(圖8)
●直接連接：轉派的方式外，Service Bus也提供了建立前端應用和服務之間直接溝通，以增進通訊效能的功能。在地址的決定上，前端程式和服務仍然是透過轉派的機制處理，之後的通訊則是直接對話，來提供較佳的效能。(圖9)
●轉派地址：在Service Bus中提供了一套處理地址的機制，透過一定的名稱使用規則，讓系統能夠順利的轉換到網路上的資源。
●服務註冊：Service Bus提供了一個服務註冊資料庫來紀錄發佈的服務端點，並提供查詢探索的能力。Service Bus會自動發佈你對外公開的端點到你的服務註冊資料庫中，其他人可以透過探索的功能找到你的端點，並進一步進行取用(如果允許的話)。


圖8：Relay Service作業。



圖9：建立直接通訊管道。

如果你對BizTalk Server有概念，就可以理解為何這個服務最初要稱做BizTalk Service了。考量到在雲端運算中應用整合場景的豐富和多樣，AppFabric的重要性不言可喻。


計費方式
計劃中，微軟會於2010年2月正式發佈Azure平台，屆時就會以收費的方式提供服務，而開發人員依舊可以依循類似MSDN訂閱的方式取得開發資源，以較低成本進行應用程式開發的工作。由於各地區資料中心建立的進度不同，微軟會先分兩個階段，在不同地區正式提供服務。但台灣不在這兩個階段以內，所以最早提供正式服務的時間可能要到2010年6月以後了。

在正式發佈之前，都是處於CTP階段，針對這個階段提供的服務內容包括：
●總體使用量：每個月2,000 VM(虛擬機)作業小時。
●儲存空間：50 GB。
●儲存資料傳輸量：一天20 GB。

一旦Windows Azure正式發佈，它的參考價格如下：
●運算能力計費：一小時0.12美元。
●儲存空間：每月每1 GB 0.15美元。
●儲存交易：每10 K 0.01美元。
●資料傳輸量：每GB傳入0.10美元、傳出0.15美元(亞洲地區每GB傳入0.30美元、傳出0.45美元)。

至於SQL Azure的計價方式如下：
●Web Edition：最多1 GB關聯式資料庫，每月9.99美元。
●Business Edition：最多10 GB關聯式資料庫，每月99.99美元。
●資料傳輸：每GB傳入0.10美元、傳出0.15美元(亞洲地區每GB傳入0.30美元、傳出0.45美元)。

AppFabric的計價方式如下：
●訊息量：每100K訊息服務0.15美元。其中包括Service Bus訊息、存取控制交易、服務管理營運。
●資料傳輸量：每GB傳入0.10 美元、傳出0.15美元(亞洲地區每GB傳入0.30美元、傳出0.45美元)。

至於各個計價單位(交易、傳輸量等)的詳細定義，可以參考：http://www.microsoft.com/windowsazure/pricing/。


Dallas計畫
在整個Azure平台的基礎上，可以想見的是各式各樣的資料將會充斥在雲端的環境網中(事實上今天的網際網路就已經是資訊泛濫的情況了)。如何順利的找到我們需要的資訊服務供應商，並管理我們的購買行為和所訂閱的資料，微軟推出了一個Dallas計劃。透過這個服務，開發人員和資訊工作者可以更輕易的探索、購買並管理發佈在Windows Azure平台上的資料或資訊。

我們可以將Dallas視為一個資訊市集，從主要的商業資料供應商，或是經授權公眾服務來源取得資料、圖片，轉換放到單一的管理環境和付款架構下。此外，Dallas所提供的API也能讓開發人員和資訊工作者在任何平台、應用程式，或作業流程中取用這些內容。

利用Dallas服務，可以完成：
●找尋可用的資料以改善既有應用程式或報表的內容及服務。
●建立及找尋合適的內容，構成新的服務應用。
●將散佈不同處所的資料加以整合，以創新的方式檢視商務績效和作業程序。
●快速的檢閱不同內容供應商的部落格、RSS或是web service進行整合作業。
●能在Office和SQL Server中輕鬆的運用第三方的資料進行分析。

整個Dallas計劃則是提供了：
●以REST為基礎的服務提供內容目錄。
●API提供動態分頁的功能以方便存取。
●提供標準的ATOM 1.0服務。
●單一的付款、維運機制和使用者報表。
●提供C#代理程式類別簡化開發作業。
●可以表格式的型式預覽資料。
●透過市集服務提供跨網域的探索功能，同時涵蓋消費和商用領域。
●可管理服務訂閱內容和使用量限制。
●可管理帳戶金鑰以存取服務。
●提供存取細目報表。

要參與體驗Dallas，並準備開發，可以到專屬開發人員網頁：http://www.microsoft.com/windowsazure/developers/dallas/。此外，這個計劃會和PinPoint市集結合，如果是要取得服務，則是到PinPoint中搜尋需要的應用或資料供應商。


雲端商店：PinPoint.com
既然在Azure上建立了各式應用程式，如何找到我們需要的服務或是應用，就成為另一個挑戰了。因應這個問題，微軟同時也提供了一個雲端商店，供使用者透過類別、地區，順利的找到執行在Azure平台上的應用。

商務客戶可以透過PinPoint找到相關的專家、應用程式或是專業服務，以利其商務的推動。透過這個市集，也能協助開發人員，或是技術服務供應商，快速且輕易的推出它的應用程式，或是專業服務到市場上，並且吸引潛在的客戶。

截至目前為止，在PinPoint上已經提供了超過7,000個應用程式，超過30,000個微軟領域的技術專家參與。它的網址是：http://pinpoint.microsoft.com/en-US/SelectCulture.aspx。(圖10)

圖10 PinPoint.com雲端商店


總結
截至目前為止，Azure應該算是在雲端運算領域唯一一個一般性的雲端應用程式建立平台，可讓開發人員在此開發出各式的應用程式，可沿用熟悉的.NET和SQL Server技能，快速的建立一個執行在雲端環境的應用。而使用者計費是整個雲端運算最大的價值所在，不論是企業或是開發商，都省卻了基礎建設建置的過程和成本，並且僅就使用的部份付費，降低此應用的進入門檻。

當然，要讓雲端運算普及，安全和私有程度的考量會是一個很重要的決定點。所幸在Azure平台上，同時考量到這方面的要求，可以同時結合私有和雲端環境，建立自己的應用服務，這一點應該是最值得激賞之處，也為應用的範疇開啟了更多的可能性。

在微軟的藍圖中，會逐步的讓傳統執行在私有環境的Windows Server/SQL Server，以及在雲端環境的Windows Azure/SQL Azure，均能享有類似的服務架構，並提供一致的管理工具，來降低企業管理上的學習成本，並簡化管理工作。例如對企業內部而言，可以透過System Center進行管理工作，而未來也能將管理的領域擴及到企業部署在Azure平台上的服務或應用。屆時私有和雲端的界線將會更為模糊，而企業能有更大的彈性，從經濟效益的角度決定合適的架構。也因為架構的相似程度高，在轉換上不會面臨大太的問題。