多云PaaS架构与能力分析

最新推荐文章于 2025-10-23 12:08:20 发布

原创最新推荐文章于 2025-10-23 12:08:20 发布 · 314 阅读

5 ·

CC 4.0 BY-SA版权

文章标签：

#多云PaaS # ASCETiC # SeaClouds # TOSCA # SLA管理

云未来：从分布式到全面计算，CF2016，2016年10月18‐20日，马德里，西班牙

多云平台即服务模型、功能与方法

摘要

平台即服务（PaaS）是近年来在采用率和市场份额方面增长最快的云领域。与此同时，云模式正通过跨多种云服务的扩展而向混合云演进。迄今为止，大多数多云方法主要探索基础设施即服务层，而忽视了云栈的其他部分。这限制了企业充分利用由PaaS多云所提供的灵活性带来的敏捷、自动化和可适应的基础设施优势。本文介绍并比较了两个针对PaaS多云架构的研究项目ASCETiC和SeaClouds的成果。

1. 引言

云计算最初以基础设施即服务（IaaS）的形式出现，得益于亚马逊网络服务的重要地位而兴起 ¹ 。与此同时，Salesforce.com正在提供基于应用服务提供（ASP）、网格和可追溯到70年代的效用计算概念的软件即服务（SaaS）——一种服务模式，其中还包括一个定制化层，即force.com。很快，随着force.com的存在以及谷歌的应用引擎进入该市场，中间件层在基础设施即服务（IaaS）和软件即服务（SaaS）之间显现出来：平台即服务（PaaS）。平台即服务（PaaS）能够简化对云基础设施的使用，并支持云应用程序。根据高德纳最近发布的数据，如今平台即服务（PaaS）是云领域中增长最为显著的部分 ² 。

与此同时，整个云市场正从针对特定用例的实验性计算替代方案，转变为商业企业和公共机构普遍采用的通用且常规的IT战略。尽管私有云现已步入主流化轨道，但市场正在进一步发展，将重心转向下一步——混合多云计算模型，力求在功能、灵活性和投资保护之间找到恰当平衡。混合多云模型使组织能够在其私有云环境及任何兼容的公有云之间提供、使用和管理IT资源。

为了使这些混合多云方法进一步发展并满足预期，云必须成为企业更广泛的数字基础设施中服务交付的多面性策略的一部分，朝着真正的混合策略迈进，并涵盖所有云层。未来的数字基础设施必须提供多种服务交付场所，使用户能够根据应用程序的特定特性、服务等级协议（SLA）和策略，将应用程序调度并自动交付到最合适的云（私有/公共）。在此背景下，迄今为止大多数多云方法仍局限于基础设施即服务层，忽视了云栈的其他部分，也未考虑平台即服务带来的自动化与编排能力。这限制了企业对其IT进行转型，无法充分受益于由平台即服务多云所提供的灵活、自动化且可适应的IT基础设施。

本文介绍了两个研究项目在平台即服务多云架构方面的成果：ASCETiC ²¹ 和SeaClouds ²⁵ 。我们详细阐述了多云PaaS的构建模块和期望能力，并将这两个项目的架构与已确定的所需特性进行了比较。

2. 平台即服务概念与现状

NIST ³ 将平台即服务定义为：“向消费者提供的能力是，使用提供商支持的编程语言、库、服务和工具，将消费者创建或获取的应用程序部署到云基础设施上。消费者不管理或控制底层云基础设施，包括网络、服务器、操作系统或存储，但可以控制已部署的应用程序以及可能的应用程序托管环境的配置设置”。

PaaS服务的用户主要有两类：开展内部软件开发活动的企业；以及希望在托管的PaaS之上销售软件即服务的独立软件供应商（ISV）。

自首次出现以来，PaaS层经历了重大转变，从最初主要由微软（Azure）和谷歌（App Engine）两大巨头主导，发展到如今PaaS服务中涵盖各种能力与编程语言。这些新进入者的产品覆盖了从专业细分领域到支持多种编程语言的解决方案。它们往往甚至不提供自己的执行环境，而是依赖IaaS提供商来实现，因此成为IaaS服务消费的代理。

如今，在PaaS领域出现了一个有趣的情况：IaaS供应商正向上扩展，通过在其基础设施之上提供编程框架来增加附加值，以避免沦为商品化的风险。与此同时，SaaS供应商则提供平台工具，以便用户定制其按需服务组合，旨在增强客户忠诚度，并围绕其产品建立更广泛的市场。这些共同构成了被标记为PaaS服务的真正多样化的能力。PaaS云提供一个容器平台，用户可在其中部署和运行其组件。不同PaaS在支持的编程工具（语言、框架、运行时环境和数据库）、底层基础设施类型以及各自提供的能力方面均存在差异。

然而，大多数已知的平台都是Azure ⁴ 和谷歌应用引擎 ⁵ 。这两个平台为执行环境添加了一套工具，以促进在平台之上进行开发。谷歌应用引擎使开发者能够在本地（开发人员计算机上）构建应用程序，并将其部署到云中，与支持谷歌应用程序的环境相同。它提供了快速的开发和部署以及简单的管理。App Engine平台提供了一个执行环境，其中应用程序在虚拟化的能够根据需求自动扩展的技术基础上运行。谷歌应用引擎常因未向用户提供控制基础设施及其使用方式的透明性而受到批评。开发人员无法直接控制资源分配，因为底层系统和硬件资源被应用引擎层所屏蔽。Azure平台是专注于.NET框架的应用程序的平台即服务（PaaS），它是微软云计算战略的一部分，与其软件即服务产品共同构成整体方案。该平台由托管在微软数据中心的各种按需服务组成，并通过三个产品品牌实现商品化：Windows Azure，提供可扩展计算和存储功能的操作系统；SQL Azure，基于云的、可横向扩展的SQL Server版本；以及Windows Azure AppFabric，一组支持在云中和本地运行应用程序的服务。此外，现有PaaS平台（如Cloud Foundry）可将应用程序部署自动化到一组模板虚拟机上，无论是在私有云环境还是基于平台的公有云服务（如Pivotal和Atos Canopy的云）中，均提供完整且隔离的平台堆栈。

此外，还可以注意到，当今的PaaS服务至少符合以下分类之一 ^14,15 ：

分类	描述	示例
带扩展的软件即服务	自定义并扩展软件即服务应用程序的能力	Salesforce的Force.com
专用型PaaS	简化特定类别开发的框架应用程序	Azure
与应用范式绑定的平台即服务	提供通用能力，但仅支持一种编程模型或开发/部署环境	CloudBees、OpenShift、谷歌AppEngine
与基础设施即服务云绑定的平台即服务	可提供通用能力，但只能在特定上下文中使用，由确定的IaaS云组成，可以是单个公有云或单个私有云基础设施类型	Cloud Foundry，AWS弹性Beanstalk

3. 多云概念与现状

多云的特点是“串行或同时使用来自不同提供商的服务来执行一个应用程序” ⁶ 。其他作者使用互连云这一术语来描述跨云的不同互连模式，但采用的是相同的方法 ⁷ 。文献中已定义了多个展示同时使用多种构成混合异构私有云和公有云的云的场景 ⁸ 。

云爆发 是最常见且更简单的混合/多云模型。在此模型中，当计算能力需求激增时，在私有云中运行的应用程序会“爆发”到公有云中。
联邦云 场景的特点是，一个云服务提供商从其他提供商处转租容量，同时将其闲置容量提供给一个云服务提供商联盟。
多供应商场景 中，用户或代表用户行事的代理负责管理服务的多云资源供给。对此功能的访问可以直接提供，也可以通过云市场提供，以隐藏管理复杂性。

在这些场景中，迄今为止大多数工作集中在基础设施即服务层。虽然如今在电子科学或未来互联网公私合作项目等背景下，已存在关于现有云联邦（如欧洲格利德基础设施）的显著示例 ⁹ 和未来互联网实验室 ¹⁰ 。这些现有示例的特点是通过使用同质化技术环境，避免了大部分相关的互操作性问题。

PaaS互操作性是Cloud4SOA ¹¹ 解决方案的重点，该方案提供了一种可扩展的方法，用于在采用相同技术的不同云服务提供商之间语义互联异构的PaaS服务。soCloud ¹² 定义了一种面向服务的基于组件的PaaS，能够实现跨多样化云环境的应用程序可移植性、资源供给、弹性和高可用性管理。 ¹³ 提出了一种联邦多云PaaS基础设施，该基础设施考虑了跨云迁移服务的特定需求，以及管理跨越多个多云PaaS的分布式应用程序的需求。其开发过程包含了用于管理我们多云PaaS和SaaS应用的基础设施服务。

4. 多云PaaS期望能力与构建模块

超越当今的PaaS服务，本文旨在描述一种多云PaaS，即一种开放、灵活且可互操作的解决方案，能够简化在公有云和私有云中运行的应用程序的开发、部署、集成以及整体管理过程。为实现这一目标，接下来的章节将详细阐述多云PaaS设想模型及其创新功能。

4.1. 多云PaaS设想模型

为了描述多云平台即服务（PaaS）的构想特性，将采用 ²⁰ 提出的模型。该模型从服务提供商的角度定义并整合了云的四个核心元素：

多租户 是充分利用PaaS云环境的关键因素：通过实现多租户，平台能够达到规模经济，降低每位用户的成本，并能够与更广泛的社区共享持续改进。然而，这也对其架构设计中的隔离提出了额外要求，即应用程序的执行在安全、性能、可用性和管理级别方面不应对其他应用程序产生任何影响。
云覆盖 代表弹性因素，通常指扩展能力。不仅指传统意义上的增加基础设施容量，还包括：支持多个平台的能力，以及跨越云并连接环境的可能性。
服务交付 包括服务管理、监控和资源供给、按需付费定价以及计费功能。
功能范围 代表任何开发平台中都具备的传统软件平台功能（非云特定）。

4.2. 多云PaaS期望能力

针对多云PaaS的每个核心元素，详细说明了其特性和期望能力。需要注意的是，尽管当今市场上的一些现有PaaS提供了部分所述能力的覆盖，但没有一个平台能够提供完整的期望功能。

4.2.1. 多租户执行隔离

在云计算的背景下，多租户是一种云的设计，旨在将正在使用的计算资源在不同的并发用户之间共享。隔离是指将一个共享环境感知为专用且安全的能力。在PaaS环境中运行的应用程序之间实现完全隔离可以采用多种策略 ¹⁹ 。其中识别出以下方法：

虚拟多租户 ：该方法主要依赖于基础设施管理层中资源虚拟化（虚拟机）和虚拟机监控器提供的隔离能力。近年来，这些方法已逐步发展为使用容器技术，尽管尚未广泛普及；
有机多租户 ：该方法基于在不同PaaS组件层级上实现的隔离，例如应用服务器、数据库管理系统等。

多级安全 ：尽管云计算为计算资源和软件提供了范式转变的技术解决方案，但关于数据隐私和保密性的担忧仍然是采用的主要关注点。在PaaS和IaaS多层中提供的底层（数据）安全和资源弹性的能力，是用户采用基于云的交付模型所必需的。

合规：公共云和混合云场景的特点是数据持续流动，无法分配到特定位置。这导致了对各种数据保护法规的不确定性，因为这些法规跨越国界，从而使得全球范围内的数据保护法规合规变得复杂。使用平台即服务来开发处理机密和个人数据的应用程序的企业或个人，需要保障其隐私。因此，从法律角度而言，在云环境中提供实现数据保护和隐私的机制应是一项基本功能。

4.2.2. 云覆盖

自助服务 ：该能力要求对资源的供给、配置和管理实现完全自动化，以弥合应用程序开发与运维之间的差距。首先，必须包含沿整个应用生命周期（考虑不同的环境，即开发、测试和生产环境）部署和推进应用程序源代码、软件及制品的能力。其次，必须提供对应用程序二进制文件以及应用基础设施组件（如操作系统、应用容器、数据库管理系统、负载均衡器等）进行自动化部署和配置的能力。最后，还需通过技术无关的方式，基于模板实现虚拟机监控器特定的虚拟机实例化，提供虚拟服务。在多云部署场景中（涉及多个IaaS提供商），由于当前不同虚拟机格式之间缺乏互操作性，因此需要进行虚拟镜像转换流程。

透明性（独立性）和对底层基础设施的完全控制 ：在底层基础设施管理方面，理想的PaaS服务需要具备透明性，以使用户能够对底层基础设施实现完全控制。这将通过完全自动化和自助服务来管理底层基础设施的复杂性而实现，同时为高级用户提供对应用执行的可见性和控制能力。

应用弹性 ：弹性是PaaS应用执行的一个关键核心特性。它定义了底层基础设施适应应用程序需求的能力，可能同时考虑功能需求和非功能需求（例如并发用户数、应用响应时间、打开的数据库连接数等）。弹性是指增加和减少资源的能力，而可扩展性仅指资源的增加，尽管这两个术语通常被用作同义词。

通常考虑两种可扩展性：横向可扩展性和纵向可扩展性：横向可扩展性指的是通过增加或减少实例数量来满足例如变化的请求数量；而纵向可扩展性指的是实例本身的大小，从而隐含地关联到维持该大小所需的资源数量。云弹性所需的能力必须同时包含纵向和横向弹性，以及快速上下扩展。

互操作性和可移植性 ：云计算采用的主要障碍之一是跨提供商和产品之间的互操作性和可移植性。在平台即服务（PaaS）范围内，存在两种实现互操作性的方法：

PaaS环境间应用程序的互操作性和可移植性：这是在不同PaaS服务之间迁移应用程序的能力。
PaaS执行环境（IaaS）间应用程序的互操作性和可移植性：一个PaaS部署可以通过相同的API和相同的应用程序与多个基础设施即服务云进行交互。

部署优化：最佳执行场所选择 ：该功能提供了重要优势，因为用户不再局限于单一提供商，而是可以根据待部署服务的类型及不同的应用程序执行需求，在不同的云服务选项中选择最佳的服务部署方案。这些选择示例包括：基于以往应用程序执行经验对提供商的信任级别、生态效率、风险、成本、所提供的安全级别、法律约束或服务质量参数（如可用性、性能、运维等）。

4.2.3. 服务交付

服务级别协议（SLA）管理 ：SLA管理是提供商业化可行的平台即服务（PaaS）方案的关键方面。重要的是，在此背景下，SLA管理包含两个方面：一方面是平台即服务提供商与平台即服务用户之间的SLA；另一方面是平台即服务提供商与其用于应用程序执行的各个提供商之间的SLA。多云PaaS方法需要具备支持用户管理这两类SLA的功能。

应用执行监控与审计 ：它指的是平台即服务用户在应用程序执行期间评估和验证服务提供商所提供的服务水平协议和实际服务质量的能力，以及了解PaaS和IaaS提供商内部流程的途径。对于用户而言，合规性和安全控制（事件清单、事件处理与纠正措施、灾难恢复计划和业务连续性等）以及数据位置可追溯性等方面至关重要，有助于克服使用云平台时固有的控制权丧失问题。

考虑多种定价模型 ：定价是云服务提供商的关键因素，因为它会影响客户行为、对提供商的忠诚度，并决定组织成功。云计算中的典型定价模型基于按使用付费。然而，该模式可进一步细化：如每台虚拟机、每小时、每CPU小时。这些与基础设施即服务（IaaS）特征相关的定价方式也常被应用于平台即服务（PaaS）服务中。此外，其他定价模型如订阅模式也开始出现，这类模式基于每月使用量进行计费。然而，考虑到服务等级协议（SLA）云条款多样性的更先进的定价模型尚未进入市场，而这些模型对于实现多云PaaS而言是必要的。

4.2.4. 功能范围

编程模式和应用程序架构 ：人们始终强调，云基础设施的基本特征是能够内在支持弹性、可扩展和资源友好的应用程序执行。然而，这些特性并非独立于应用程序架构和平台而获得；多云PaaS必须支持充分发掘云优势和特性的能力。

集成：指与遗留软件和本地资产（即许可软件）以及第三方云服务（云编排）进行集成的能力。在考虑新服务开发时，多云PaaS必须能够实现对遗留软件和许可软件的适配与组合。

应用程序数据管理功能 ：如今大多数平台即服务（PaaS）提供的数据管理服务仅支持可扩展性有限的MySQL、PostgreSQL、CouchDB或其他易于与平台后端集成的开源数据管理解决方案，但这些方案为用户提供的可扩展性和功能非常有限。其他方法则依赖于将其PaaS产品与数据即服务（Data-as-a-Service）产品（如AWS S3、SimpleDB或微软Azure）集成。在多云PaaS方法中，这些集成需要进一步扩展。

5. 平台即服务层面的多云

在本节中，我们将介绍ASCETiC和SeaClouds的架构及其多云方法，并对这两个项目在前一节中确定的核心元素和创新特性方面进行比较分析。

5.1 平台即服务层面的多云：ASCETiC 应用管理器方法

ASCETiC项目致力于提供新颖的方法和工具，以支持软件开发者优化能源效率，并最大限度地减少在云环境中设计、开发、部署和运行软件所产生的碳足迹。该项目试图覆盖从SaaS到IaaS，经过PaaS层的三种典型云堆栈。在本节中，我们将重点解释ASCETiC PaaS层面的多云方法。

应用程序描述平台即服务层被实施，遵循开放虚拟化格式（OVF）规范 ²² 来定义一组完整的虚拟机（VM）及其在IaaS提供商处的部署关系。利用OVF标准中提供的可扩展性，新增了若干字段以反映多种需求：

服务等级协议协商条款，例如：虚拟机消耗的电量、最高成本或垂直弹性限制。
当服务等级协议条款即将被违反时，应用于自适应规则中的规范。

尽管选择了OVF，因为它是相当标准且被多个虚拟化提供商支持的格式，但该项目也已开始研究TOSCA ²⁴ 的使用。目前尚未发布支持此格式的ASCETiC实现。在图1中，我们可以观察到ASCETiC PaaS的架构框图。该框图将在接下来的段落中用于详细解释ASCETiC在平台即服务层的工作流程。

ASCETiC的用户将通过应用管理器（AM）提供的REST接口提交其应用程序，该应用程序由镜像和开放虚拟化格式（OVF）描述组成。一旦接收到该OVF和镜像，应用管理器将检查其有效性，并开始准备一系列服务等级协议模板。

对于存储在提供商注册表（PR）中的每个提供商，应用管理器（AM）将创建一个模板，供SLA管理器（SLAM）与ASCETiC PaaS所连接的每个IaaS提供商进行协商。这些模板连同OVF文档将通过应用管理器（AM）提交给SLA管理器（SLAM）。

SLAM将联系IaaS提供商中的对应组件。它将获取针对该特定应用程序部署在每个IaaS上的报价，并对这些报价进行排序后返回给AM。同时，在向用户展示这些协商结果之前，PaaS价格建模器会更新IaaS提供商返回的价格，生成新的价格。

在此阶段，应用管理器可以执行两个操作。如果用户指定希望进行手动协商，则应用管理器将显示所有报价，供用户选择其中一个。如果提交应用程序时启用了自动标志，则应用管理器将根据SLAM选择的排序（基于成本）来选择最佳报价。

应用管理器随后将应用程序移至上下文化阶段。虚拟机上下文化模块将准备要在所选IaaS提供商中部署的镜像。预计不同的IaaS提供商会具有不同的上下文化流程。

现在，应用程序将由应用管理器进行部署。应用调度器将联系IaaS提供商，并根据OVF文档中指定的初始部署计划启动创建所需的各个虚拟机实例。每个阶段的应用程序部署详细信息通过REST接口向用户提供，用户可以通过轮询该接口精确了解其部署状态。此外，还提供了AMPQ接口，供用户订阅并获取相同信息的通知。

应用程序运行后，用户将拥有与典型云应用管理器相同的功能。可以删除部署、向其中添加更多虚拟机、移除虚拟机、修改虚拟机的属性等。主要区别在于开始使用性能、能耗或成本等方面的术语来管理应用程序。

SLAM模块正在积极监控应用程序是否在协商的参数范围内运行，这些参数既来自IaaS提供商，也考虑了应用程序的行为。如果出现违反这些参数的情况，SLAM会通知自适应管理器（SAM）。SAM将触发OVF文档中预先定义的一些规则，以尝试使应用程序恢复到服务等级协议（SLA）规定的边界内。

同时，用户可以获得一组关于能耗和应用程序性能监控的功能：

用户可以随时在应用程序执行过程中注册一个事件。事件是在应用程序中频繁发生的、具有连贯性的某种情况。
用户可以在应用监视器中存储任何类型的指标。应用监视器为用户提供REST和AMPQ API，以便从其应用程序中以编程方式使用它。

IaaS需求：当然，ASCETiC AM的运行离不开兼容的基础设施即服务。ASCETiC项目同时正在开发必要的组件，例如在IaaS层面兼容的SLA管理器以安装在感兴趣的IaaS提供商处，以与ASCETiC PaaS进行联合。有关此的更多信息，请访问 ²¹ 。

状态：之前的所有工作流和功能在应用管理器的实际实现中均已正常运行，其代码在 ²¹ 处公开提供。ASCETiC项目已在三重测试环境上验证了该解决方案。每个测试环境均配备基于OpenStack的兼容ASCETiC基础设施即服务提供商。为验证上述工作流，选用了三种不同类型的应用程序，这些应用程序具有显著不同的需求和行为特征（从典型的弹性云应用程序到更多高性能计算类型的应用程序）。ASCETiC项目仍在持续开发中。预计该组件的新功能将朝着支持正在运行的应用程序进行IaaS提供商迁移的方法方向发展。

5.2. 基础设施即服务和平台即服务层面的多云：SeaClouds方法，PaaS统一层

SeaClouds提供了一个平台，通过开发云服务编排器和一套管理复杂应用程序的工具，实现基于服务的应用程序的无缝自适应多云管理，从而避免云厂商锁定问题。该平台通过使用统一管理API和通用指标来监控和验证功能性和非功能性属性，支持将基于云的应用程序的模块分布在多个技术各异的基础设施即服务或平台即服务之上。

SeaClouds依靠Apache Brooklyn ²³ （一个顶级的Apache项目）作为其部署引擎。Brooklyn是一个通过自主蓝图对基础设施即服务中的应用程序进行建模、监控和管理的框架。Brooklyn蓝图表示一个应用程序：模块的构件、软件栈、模块间关系的配置、自动伸缩策略等均可在蓝图中描述。Apache Brooklyn是一个拥有活跃社区且日益流行的开源项目。这一事实以及Brooklyn提供的特性（声明式部署、支持实体的广泛目录、完整的图形用户界面等），从能力和维护角度证明了在SeaClouds中选择Brooklyn作为部署引擎的合理性。目前，Brooklyn使用符合CAMP语法的蓝图，并暴露了许多CAMP REST API端点。然而，已开发出一种非官方的TOSCA扩展，SeaClouds参与了该扩展的实现。

TOSCA是一项OASIS开放标准，用于定义服务和应用程序的描述，包括其组件、关系、依赖项、需求和能力。它可以被描述为一种以应用程序为中心的技术，这一概念与SeaClouds方法高度契合。因此，SeaClouds采用了TOSCA，并使用TOSCA规范来描述部署蓝图。TOSCA蓝图为底层的基础设施即服务或平台即服务提供商提供了必要的抽象层。在实现方面，针对IaaS提供商，部署引擎使用Apache jclouds ²⁶ ；而对于PaaS提供商，尽管存在一些可完成类似任务的库，但它们无法满足项目所需的能力。

为解决此问题，SeaClouds构建了一个抽象层，以简化对PaaS提供商的管理。

该抽象层即为PaaS统一库 ²⁷ 。该库以统一的方式提供对平台即服务提供商中应用程序管理的基本操作，依赖于各个平台官方的Java客户端。开发者可以通过Java代码调用该库来部署应用程序，或使用其内置的REST服务（该服务基于该库运行）。支持的操作包括：部署、取消部署、启动、停止、扩展和绑定服务。当前支持的提供商包括基于CloudFoundry v2的提供商（Pivotal、Bluemix、Canopy Cloud Fabric等）、基于OpenShift v2的提供商（OpenShift Online）以及Heroku。

该库将登录提供商与要执行的实际运维操作解耦，因此其结构分为两个主要接口：PaaS客户端，负责登录提供商以获取会话对象；PaaS会话，作为前述各种基本运维操作的统一接口。

SeaClouds监控并评估应用程序的响应时间、可用性和吞吐量。根据开发人员在设计新应用程序时为这些指标指定的期望值，生成相应的监控规则和服务等级协议（SLA），并将其包含在TOSCA部署应用模型中。设计和部署阶段的操作流程如下：

用户表达全局服务质量：响应时间、可用性和吞吐量。
规划器生成监控规则（用于评估服务质量）和服务等级协议（用于跟踪违规情况）。
用户同意该协议并启动部署。
部署器部署监控规则并启动协议执行。

应用程序部署后，将通过MODAClouds项目开发的Tower 4Clouds平台进行监控 ²⁸ 。Tower 4Clouds的主要能力包括：

用户定义需要在运行时进行评估的监控规则形式的服务质量约束。这些规则与云服务提供商无关。在SeaClouds中，规则根据应用程序所需的响应时间、可用性和吞吐量生成。
与应用程序一起部署的数据采集器将监控数据发送到中央数据分析器会根据已安装的监控规则来确定应监控的资源及其监控方式。在执行扩展或迁移操作后，无需重新配置。对于PaaS应用程序，已实现一个应用程序数据采集器，能够收集响应时间和吞吐量测量数据。SeaClouds平台负责在应用程序部署后自动部署数据采集器并进行配置。
数据分析器处理数据采集器收集的数据，执行聚合和/或验证监控规则中规定的条件。可以在监控规则中定义一些预定义操作，并在满足条件时执行。

5.3. 比较分析

下表对ASCETiC和SeaClouds在多云PaaS核心元素以及已识别的期望能力方面的做法进行了比较和总结。

比较维度	ASCETiC	SeaClouds
多租户执行隔离	虚拟多租户	虚拟多租户和有机多租户
多级安全	未考虑	未考虑
合规	未考虑	未考虑
自助服务	基于标准（OVF, TOSCA）	基于标准（TOSCA）
透明性	完整（IaaS）	完整（IaaS）和部分PaaS（取决于PaaS provider能力）
应用弹性	基于规则	仅在基础设施即服务层面上考虑
互操作性和可移植性	通过jClouds支持的基础设施即服务	跨： jClouds支持的基础设施即服务平台即服务 (Heroku、OpenShift和Cloud Foundry)
部署优化	支持（基于自我管理）关于能源和价格优化	基于奖励的支持
服务水平协议（SLA）管理	支持（能源、价格和性能）	支持（性能）
应用执行监控与审计	应用程序监控	应用程序监控
考虑多种定价模型	是	否
编程模型和应用程序架构	是（并行PM） OVF虚拟设备	TOSCA编排
应用程序数据管理功能	不支持	支持数据库模式