在我们的行业中，迎面而来的最主要变化是云计算。这个变化的许多重要部分之一是云平台的到来。正如它名称所示，这种类型的平台让开发者编写运行在云的应用程序，或者使用来自云的服务，或者二者兼之。今天，在这种类型的平台上使用了不同的名称，包括即时需要平台和作为一个服务平台（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的负责人。通过他的讲演、写作和咨询，他帮助了全世界的软件专业人员，理解、应用和对于新技术做出更好的决策。