在我們的行業中，迎面而來的最主要變化是云計算。這個變化的許多重要部分之一是云平臺的到來。正如它名稱所示，這種類型的平臺讓開發者編寫運行在云的應用程序，或者使用來自云的服務，或者二者兼之。今天，在這種類型的平臺上使用了不同的名稱，包括即時需要平臺和作為一個服務平臺（PAAS）。無論如何命名，這個支撐應用程序的方式具有很大的潛能。

?

讓我們看下原因，思考下今天應用程序平臺是如何被應用。當開發團隊創建一個已預知的應用程序（如，運行在組織內部的），這個應用程序已經擁有許多需求。當在環境中的其它計算機提供如遠程存儲的服務時，操作系統為執行這個應用程序提供基礎的與存儲交互及其它的支持。如果每個即時需要應用程序的創建器，首先必須構建所有這些的基礎，我們今天的所看到的應用程序可能會更少。

?

類似地，如果每個開發團隊希望創建一個云應用程序，首先必須構建自己的云平臺，我們也不可能會見到更多的云應用程序的出現。幸運地，供應商們承擔了這個挑戰，大量的云平臺技術在今天將要出現。這個概述的目標是分類別地，簡要地描述這些技術，目的是他們可以被被創建企業應用程序的某些人所理解。

?

?

?

上下文環境中的云平臺：云服務的三種類型

?

圖1 云服務被分組為三種顯著的類型

?

控制了云平臺，通常為著眼于云服務提供了先天條件。正如圖1所示，云中的服務可以被分成三個顯著的類型。這些類型是：

l? 軟件即服務（SaaS）：一個SaaS應用程序完全運行在云中（那就是，沒有服務器停靠在可訪問的Internet服務提供商處）。即時需要客戶端通常是一個瀏覽器，或者其它簡單的客戶端。今天SaaS應用程序的許多已知例子是Salesforce.com，但，許多其他人也是有的。

l? 附著在服務上：每個即時需要的應用程序提供自己的有益功能。應用程序有時可以通過訪問提供在云中的特定應用程序來強化這些。因為這些服務僅依靠這個特定的應用程序是有用的，他們可以被認為是它的依附。這樣的一個流行的使用者例子是Apple的iTunes：當一個附著服務允許購買新的音頻和視頻內容時，桌面應用程序對參與的音樂及其他更多的內容是有益的。微軟的Exchange托管服務提供一個企業范例，增加基于云的垃圾信息過濾器，檔案和其它服務到即時需要的Exchange服務器。

l? 云平臺：一個云平臺為應用程序提供的基于云的服務。而不是構建他們自己的自定義功能，例如，你新SaaS應用程序的創建者可以替換為你期望的云平臺。正如圖1所示，云平臺直接的用戶是開發者，不是最終用戶。

?

理解云平臺需要對這個環境中的單詞“平臺”的含義有更多理解。一個更廣泛的方法是把它作為任何一個軟件的平臺來思考，為開發者提供創建可訪問的服務。下一節看下這個概念更多點的明細。

應用程序平臺的一般模型

我們今天的應用程序平臺的經驗大部分來自即時需要的平臺。思考云平臺的有用的方法是，依賴于即時需要環境的一個應用程序開發者，如何把需要的服務轉換到云平臺上。圖2幫助理解這個，顯示了可以被應用在上述二者世界里的一般模型。

?

?

圖2：作為擁有三部分角度的一個流行的應用程序平臺

?

無論是即時需要或是在運中，一個應用程序平臺可以通過三個部分組成來考慮：

l? 基礎：在它們運行的機器上，幾乎每個應用程序都需要使用一些平臺軟件。這個通常包括多種多樣的支持功能，如標準庫和存儲，和一個基礎的操作系統。

l? 一組基礎結構服務：在現代分布式環境中，應用程序經常使用其它計算機提供的服務。一般情況下，如，提供遠程存儲，集成服務，識別服務等等。

l? 一批應用服務：正如越來越多的應用程序發展成面向服務的，他們提供的功能逐漸成為新應用程序的可訪問對象。即使這些應用程序最初是提供給最終用戶的，也會使它們成為應用程序平臺的一部分。（似乎其它應用程序成為平臺的一部分是單方面的想法，但在面向服務的世界里，它們當然會發生。）

?

沒有在圖2中顯示，開發工具也是這個故事中的另外一個重要的部分。現代的工具可以幫助開發者使用應用程序平臺的三個部分構建應用程序。

?

為了使這個抽象模型更具體，思考下它是如何適合今天流行的許多即時需要平臺的。即時需要的基礎如下面的特征：

l? 操作系統：具有支配性選擇的是Windows，Linux和其它版本的Unix。

l? 本地化支持：不同技術的使用依賴于應用程序的類型。.NET Framework和JAVA EE的應用程序服務為WEB應用程序等提供了支持。比如，當其它技術的目標是特定類型的應用程序時。例如，Microsoft的Dynamics CRM產品包括了創建特定類型的業務應用程序的平臺所設計。類似地，不同的存儲應用于不同的目標。原始字節存儲，是被Windows，Linux和其它操作系統上的文件所提供，更多的結構化存儲是由廣泛的數據庫所提供，包括Oracle DBMS, MySQL, Microsoft SQL Server, and IBM DB2.

?

對于即時需要的基礎結構服務，典型的例子如下所包括的：

l? 存儲：像基礎的存儲，基礎結構存儲來自多種多樣的風格。遠程文件系統可能提供簡單的字節導向的存儲服務，而Microsoft SharePoint文檔提供了更多的結構化遠程存儲。應用程序也可能遠程地訪問數據庫系統，也允許訪問其它類型的結構化存儲。

l? 集成：組織里具有網絡連接的應用程序通常依賴于一些集成產品提供的遠程服務。消息隊列是這樣的一個簡單范例，更復雜的場景使用的產品，如IBM WebSphere Process Server, Microsoft BizTalk Server和其它。

l? 識別：對于大部分分布式的應用程序提供識別信息是基本的需求。一般的即時技術都致力于這方面，包括Microsoft Active Directory 和其它的LDAP服務器。

?

即時需要應用程序服務，圖2中顯示的第三種類型，非常普遍地橫跨不同的組織。這個原因是簡單的：不同的組織使用不同的應用程序，依次暴露不同的服務。在即時需要平臺里認識這些應用程序的一個方法是，分割它們為兩個主要類別：

l? 打包應用程序：這個包括業務軟件，如SAP，Oracel Application和Microsoft Dynamics，還有無數的其它現貨供應的產品。不是所有的打包應用程序暴露服務給其它應用程序的同時，它們所在的會越來越這樣。

l? 自定義應用程序：許多組織有大量的投資在自定義軟件中。當這些應用程序日益地通過服務暴露它們的功能時，它們逐漸地成為即時需要應用程序平臺的組成部分。

?

當這樣描述時，即時需要應用程序平臺似乎是相當復雜的。雖然事實是，這些平臺已經隨著時間而發展。在計算的早期那些時候，應用程序平臺只不過有一個即時需要功能組成。（例如，想想IBM大型機上的MVS和IMS.）在19世紀80年代和90年代，在分布式計算飛速發展時，即時需要基礎結構服務被加載進去，有遠程存儲、集成和識別，逐漸變得更普遍。今天，隨著面向服務應用程序的出現，即時需要應用程序服務已經變成平臺的一部分。這個發展的下一步是很清晰的：提供這個三個部分所有的云版本。

?

從即時需要平臺到云平臺

順著正在描述的即時需要平臺，這個普通的模式正好也可以用來思考云平臺。既然即時需要和云平臺放在一塊使用，那么，重要的是要理解二者是如何相互工作的。圖3舉例說明了這個新的境況。

?

?

圖3：即時需要平臺和云平臺被認為是相似的方法，它們也可以被放在一起使用

?

正如圖所示，云應用程序被構建在云功能上，正如一個即時需要應用程序被構建在即時需要功能上一樣。兩種類型的應用程序都可以訪問由即時需要和云提供的應用程序服務和基礎結構，正如即時需要平臺支持今天的應用程序一樣，云平臺為我們明天想構建的應用程序提供服務。

?

考察云平臺

理解云平臺意味著著眼于它們的每個部分：云基礎、云基礎結構服務和云應用程序服務。本節娓娓道來這三個領域，使用今天比較明顯的云平臺技術作為例子。

?

我們開始之前，有一個重要的說明：通過相同的鏡頭，都有益于云平臺和即時需要的，不進行區分。當平臺功能轉移到云時，它們有時的變化是很深遠的。例如，即時需要平臺被設計來支持（至多）企業等級的應用程序。于此對比，放在云上的應用程序，潛在的運作可以是Internet級別的。當相同類型的平臺功能在兩個情況下都需要時，施加在云平臺上這些功能提供達到這個高的可度量性的可能性，會用完全不同的方法。下來所述，期望搞清楚與即時需要世界里的不同。

?

云基礎

像即時需要的姊妹，云基礎提供應用程序需要的基礎本地功能。這些可能包括下面的操作系統和本地化支持。然而，提供這些服務的云平臺與我們已經使用的有何不同，正如本節展現的。

?

操作系統

從平臺的角度看，操作系統提供了一批應用程序使用的基礎接口。到目前為止，云里的操作系統，是眾所周知的Amazon 的Elastic Compute Cloud（EC2）。EC2提供運行在虛擬機器（VM）里的客戶明確的Linux實例。從技術角度看，更準確地說，EC2作為一個VM平臺，而不是操作系統。盡管如此，一個開發者領會了操作系統接口，而且作為輕量級看待，這里會更有意義。

?

每個開發團隊自由地使用這個VM支持的任何一種本地化支持---Amazon不關心的。例如，當另一組使用Rail上面的Ruby時，一個應用程序的創建者可以選擇Java EE應用程序服務和MySQL。EC2客戶甚至自由地創建許多Linux實例，然后，大量的分布式負載平行地穿插在它們之間，像科學程序那樣。當EC2提供的服務是相當的基礎時，也是非常概括，所以，可以被用在許多不同的方法中。

?

本地支持

在即時需要平臺里（EC2里），一個開發者可以混合著搭配她認為合適的一部分功能。例如，選擇使用Windows上的.NET框架，不強求使用特定的數據庫。相似地，同構建在Java EE服務器上應用程序，使用.NET框架的即時需要應用程序訪問下面的Windows操作系統是輕松的。

?

在今天的領導型的云基礎里的本地支持不用這種方法工作。而是，一個云本地化支持技術通常包括它自己的存儲，它隱藏了下面操作系統可能做的事情。一個開發者選擇一個特定的本地化支持選擇，必須接受它施予影響的限制。

?

當然，這些限制有更好的理由。除了使構建在云基礎之上處理Internet規模加載的應用程序需要用一些方法來限制之外，使云計算更有吸引力的事情之一是，它的可度量性更具有潛力。通過使本地支持功能更專業化，在今天的云基礎里的每一批本地化支持功能更關注支持一個特定類型的應用程序。

?

例如，Google的AppEngine為運行的Python Web應用程序提供本地化支持。隨同標準的Python運行時一起，AppEngine也包括了一個帶有自己的查詢語言的分等級數據存儲。提供本地化支持的云平臺的另外一個例子是由Salesforce.com提供的Force.com。那么，相對于把普通的Web應用程序作為目標而言，Force.com瞄準的是創建面向數據的業務應用程序。朝著這個目的，提供了它自己的數據存儲支持。而不是采用已存在的編程語言，這個平臺的創建者發明了他們自己的語言，叫做Apex。

?

微軟也為應用程序提供了云的本地化支持，是由它的CRM Live提供的一部分。基于前面提到的Dynamics CRM，這個技術的目標是面向數據的業務應用程序，更像Force.com。而且像Force.com和AppEngine二者，包括運行時應用程序支持和數據存儲。微軟也發表了它在這個領域的未來計劃，將會擁支持標準的.NET開發語言和工具。目的是，微軟說，允許應用程序和開發者技能在公司的即時需要基礎和它的云基礎之間方便轉換。

?

云基礎結構服務

無論是運行在即時需要上或者云里，一些應用程序不需要功能之外的任何事情。但，許多應用程序可以從分布式存儲，公共識別和其它基礎結構服務上收益。今天，我們習慣了占有被即時需要提供的服務，但，云服務也提供相似的服務。

?

正如圖3所顯示，云基礎結構服務也可以被運行在即時需要基礎上和云基礎上的任何一個所訪問。最初，大部分云基礎結構服務的普通用戶將是即時需要的，因為至今沒有多少應用程序構建在云基礎上。隨著時間的推移，期望這個會發生改變，會越來越多的基于云的應用程序也會使用云基礎結構服務。

?

存儲

應用程序一般下會使用一些本地存儲的類型，是因為存儲是即時需要和云基礎的一部分。這樣的服務在即時需要的世界所顯示的那樣，云存儲也是有好處的。從而，在云里提供存儲服務，吸引大部分的應用程序，這樣的期望也是合理的。

?

正如即時需要平臺，云里的遠程存儲會流行起不同的類型。例如，Amazon的簡單存儲服務（S3）提供了基礎的非結構化的遠程存儲。它暴露給開發者的模式是直接的：對象，正好可以和字節綁定，可以存儲為塊。應用程序可以創建、讀取和刪除對象和塊。對象不能被刷新，但是—它們可以被整體代替。這是平臺服務如何必須改變成支持Internet刻度的用法的另外一個例子，Amazon很直接關注的一些事情。這是簡單而且被限制存儲服務使可度量性更容易，而不是充滿提供的所有特征。這個交換是明確的：應用程序開發者獲取廉價的云里存儲，而他們不需要做更多的工作，使它使用更有效果。

?

云存儲的其他方法是支持更多的結構化數據。在微軟的SQL Server數據服務（SSDS）里，例如，一個容器包括一個或更多的實體，它們的每一個保持一些數量的屬性，如在圖4中所示，一個應用程序用操作符（如，==，!=，<,>,AND, OR, 和NOT）可能發布了不包含在容器的數據的查詢。

?

圖 4 在 SQL Server 數據服務中，一個容器包含帶有屬性的實體

?

要重點注意，這不是一個關系數據庫，查詢語言也不是SQL。再一次，我們明白了，當它們移到云上時，應用程序平臺技術是如何變化的。這簡單的方法比關系數據庫很容易使用起來 --- 不需要在前端定義一個結構 --- 也容易進行度量。

?

Amazon的 SimpleDB提供了云結構化存儲價值的更多例證。SimpleDB組織信息的方法相似于SSDS --- 域（domain）、項（item）和值（value）--- 也提供了一個非SQL查詢語言。類似于SSDS，沒有前端結構定義需求，所以，這個方法提供了靈活而可度量的解決方法。

?

集成

遺留下來的任何一個應用程序，不能責怪它同伴中的任何一個？可連接的應用程序逐漸成為計算的主要成分，而且供應商也提供了過多的即時需要基礎結構來處理它。這些范圍包括從簡單的技術，像消息隊列，到十分復雜的集成服務。

?

當集成服務轉移到云上時，技術的范圍也在逐漸顯現。例如，Amazon的簡單隊列服務（SQS，Simple Queue Service）提供正如它名稱所表示那樣：在云里，通過隊列，使應用程序交換消息的一個直接的方法。如今，SQS再次證明了，在相似的即時需要被轉換為云服務時，發生了什么。因為SQS通過多種隊列復制消息，從一個隊列中讀取的應用程序不保證很清楚指定讀取請求的所有隊列找的消息的含義。SQS也不承諾是按順序、極正確地傳送。這些簡化讓Amazon使SQS更容易度量，但它們也意味著，開發者必須接受SQS異于即時需要隊列技術的差異化。

?

BizTalk Service提供了另外一個基于云集成的例子。優于使用消息隊列，BizTalk Service實現了一個云內的傳播器服務，讓應用程序通過防火墻通信。基于云的集成，如在不同組織里連接應用程序，通常需要穿透防火墻，所以，解決這個問題是重要的。BizTalk Service也提供了簡單的工作流的支持，這個支持需伴隨著一個方法來注冊到它暴露的服務的應用程序，那么，讓這些服務被任何其它權限允許的應用程序可以調用。

?

進而，期望看到更多的由云提供的集成服務。假設集成的重要性等同于即時需要服務，集成功能逐漸成為云基礎結構的一部分，就不令人驚訝。

?

識別

無論一個應用程序是運行在即時需要或者云里，通常都需要知道一些有關它使用的事情。朝向這個結果，應用程序一般化需要，每個用戶提供一個數字識別，一串描述用戶的字節。基于這些字節包含的內容，它們是如何識別的，應用程序可以確定一些事情，如這個用戶是誰，它們允許做什么。

?

今天的許多即時需要應用程序依賴即時結構服務，如，活動目錄，可以提供這些識別信息。然而，當一個用戶訪問一個云應用程序時，或者一個即時需要應用程序訪問一個云服務時，即時需要識別通常不需要使用。構建在云基礎上的應用程序有如何呢？它從哪里獲取識別信息？

?

云里的識別服務致力于解決這些問題。因為它提供了數字識別，可以用于人、即時需要應用程序和云應用程序，一個云識別服務可以被應用在不同的場景里。事實上，這種類型的識別服務的一個重要跡象是，在今天，大量的云識別是可用的。比如，當使用Google AppEngine請求一個Google賬戶時，訪問Amazon云服務（如，EC2或者S3）需要提交一個Amazon定義的識別。微軟提供了Windows Live ID，可以用于微軟應用程序及其它，同時，BizTalk Service也提供了他自己的識別服務，可以與其他人聯合。開發者不需要完全的自主 --- 云平臺也經常特定的識別提供者 – 但作為一個云服務的識別需要是清晰的。

?

云應用程序服務

在一個應用程序服務和一個基礎結構服務之間有什么不同？回答這個問題，首先思考下應用程序和基礎結構之間的很明顯的差別：設計的應用程序是被人使用的，同時，設計基礎結構是被應用程序使用的。基礎結構通常提供一般的、有關底層面服務的說法也是公平的，同時，應用程序提供更多明確地，高層面的服務。基礎結構服務解決了更廣泛的面向許多不同類型應用程序的問題，同時，一個應用程序服務解決更多針對問題的目標。正像識別不同類型的基礎結構服務是可能的，正如本節例子所說明的，也可能辨別出不同的應用程序服務分類。

?

SaaS 應用程序服務

今天的大部分企業的用戶依賴于采購和成長性家庭（purchased and home-grown）應用程序。當這些應用程序暴露它們的服務給遠程軟件，它們會逐漸成為即時需要的一部分。相似地，今天的SaaS應用程序經常性暴露服務，這些服務可以被即時需要應用程序，或者其它云應用程序訪問。例如，Salesforce.com的CRM應用程序，形成了多種可用的服務，這些服務可被用在使即時需要應用程序集成它的功能。正在組織開始創建他們自己的運行在云基礎上面的SaaS應用程序時，這些應用程序也會暴露服務。正如今天的打包和自定義即時需要應用程序那樣作為即時需要平臺的一部分，被打包和自定義的SaaS應用程序暴露的服務，逐漸成為云平臺的一部分。

?

搜索

被SaaS應用程序暴露的服務是有益的，但并不是全部的歷程。其他類型的云應用程序服務也是重要的。例如，思考下如Google和Live搜索。隨著它們給人們很明顯的價值，它們為什么不也提供云應用程序服務？

?

當然，問題是，他們是有這種能力的。例如，微軟的Live搜索，暴露的服務，允許即時需要和云應用程序提交搜索和獲取搜索結果返回。假設一個公司提供一個合法信息的數據庫，想讓客戶搜索它們自己的數據和單一請求的Web。他們可以通過創建一個即時需要應用程序來達到這樣的目標，他通過Live搜索它們私有的數據和整體Web。公平地說，不是許多應用程序都適合這種類型的服務，但是有一個原因是更準確地認為搜索應該作為一個應用程序服務，而不是一個基礎結構服務。

?

繪制地圖

今天的許多Web應用程序都會展現地圖。旅館Web站點繪制了它們的位置，零售商提供存儲位置，等等。創建這些應用程序的人或許沒有時間、興趣，或者預算來創建它們自己的地圖數據庫。迄今為止，應用程序需要的這個功能足夠證明可以創建一個提供這個的云應用程序服務。

?

通過如Google地圖和微軟的虛擬地球的地圖服務所能做的是很精細的。提供基于云服務，應用程序開發者可以用來嵌入地圖在Web頁面里和其它地方。就如搜索，這些地圖服務也可以附屬在已存在的Web站點上，直接瞄準用戶，這就是云應用程序服務。

?

其它應用程序服務

許多其它的應用程序服務在今天也是有效的。事實上，幾乎任何一個Web站點都可能作為針對開發者使用的云服務來暴露它們功能。例如，照片-共享站點,如，Google的Picasa和微軟的Windows Live Photo Gallery所做的）;正如在線通訊所做的，如Google Contact和微軟的Windows Live Contact。 對于暴露服務的一個最大的動機是，使它更容易創建mash-up，開發多種多樣的Web應用程序的功能。

?

供應商有時把云應用程序服務分組置于在公共的庇護雨傘下。例如，訪問Google Contact、Picasa和其它Google Data API所有部分的服務。類似地，微軟把它的數個服務分組在一起，放在Live平臺品牌下，包括Live搜索，虛擬地球、Windows Live Contact、Windows Live ID、一個報警服務、一個叫做基于應用程序存儲的特定存儲服務，等其它數個服務。

?

云基礎結構服務和云應用程序服務在一條線上，有時可能是模糊的。例如，一般的云存儲服務，如S3和SSDS是很明確的基礎結構，像云識別服務一樣。地圖服務，如Google地球，正好是很清晰的是以應用程序為中心的 --- 僅符合某些類型的應用程序需要 --- 如像Live搜索的服務。但報警服務可以被認為是基礎結構，自從它們更具有一般意義的價值，Windows Live ID是一個明確的基礎結構，雖然，微軟把服務作為它Live 平臺的一部分。

?

云平臺是一個新領域相關的，所以，并不驚訝定義一個公司的類別是一個挑戰。然而，你要有選擇地觀察它們，很清楚，云應用程序服務扮演了更重要的角色。對于今天的設計和構建軟件的每一個，明白什么在云里是有效的，應該是一個核心的能力。

?

總結

一個新類型的應用程序不會經常發生出現。但是，當一個成功的平臺創新顯示出來時，會有巨大的影響力。想想，個人計算機和服務的道路，影響了全球的大型機和小型機，例如，或者N-層應用程序平臺的出現改變了人們寫軟件的方法。當舊世界不前進時，一個新的方法很快就成為你應用程序的關注中心。

?

云平臺迄今為止，沒有提供全面的即時需要環境的寬帶。例如，作為平臺一部分的商業智能不是公共的，也不支持業務過程管理技術，如充滿特征的工作流和規則引擎。然而，這是所有的某些改變，這個技術破浪地向前滾動。

?

迄今為止，云平臺不是人民關注的中心。雖然成成功的可能性是良好的，從現在的五年這個也不一定成為現實。基于云計算的吸引力，包括可度量性和低成本，是分成真實的。如果你工作在應用程序的開發里，無論是軟件供應商，或者最終用戶，都期望在你的未來云扮演一個日益增長的角色。下一代應用程序平臺是這里。

?

關于作者

David Chappell是在舊金山，加州的Chappell & Associate的負責人。通過他的講演、寫作和咨詢，他幫助了全世界的軟件專業人員，理解、應用和對于新技術做出更好的決策。

?

?

?

?