InPaaS：新一代云计算应用平台

    PaaS平台现状

    按照NIST的定义，IaaS主要提供包括计算、存储和网络等基本的计算资源的交付和管理能力，使用户能够在上面部署任何软件。而PaaS则是被定义为一个建立在云基础设施上的应用部署系统，这个系统为用户提供API,工具和服务来部署和管理应用和服务。而PaaS的用户是开发测试者以及IT运维和管理者。 PaaS经历了一个摸索期后，人们已对PaaS逐渐形成了一个较为清晰的共识，PaaS已超越了IaaS API和DevOps等工具，它通过应用生命周期的管理来加速应用的交付。从早期的PaaS技术的代表者 Google App Engine、Force.com、Heroku和SAE 等中可以看到 PaaS具有以下一些基本特征：

    ·主要提供应用的部署和托管

    ·针对应用开发者

    ·在支持特定的IaaS基础技术

    支持单种开发语言和框架

    ·支持特定的服务，比如自定义的数据存储APIs

    这些PaaS加速应用的交付。首先，它们让包括开发者在内的用户不需要担心硬件和虚拟机器，操作系统，应用服务器，以及对服务管理，使得他们更加快捷和容易地进行应用部署和迭代，以及应用的横向扩展。但其明显的短块是用户很容易被绑定。他们需要使用特定的编程语言来开发应用程序，需要针对特定的服务插件和APIs来编程，或者需要部署应用在特定的IaaS上。这些特点限制了用户对于应用程序开发，部署和运维的自由度和敏捷性，以及应用程序的可移植性。

    正因为如此，新一代的云应用平台技术则实现全方位的应用生命周期管理，关注开放性、应用的可移植性和云间相互操作性，其代表者包括Cloud Foundry, OpenShift, Docker, Heroku, MoPaaS和BAE等PaaS技术或服务，除了在第一代PaaS技术对用户在实现应用交付的加速所提供的功能外，具备以下大多数特征：

    ·多语言和框架：支持多语言和框架以及语言框架的扩展机制

    ·多服务：开放的核心服务以及服务的扩展机制

    多云和多IaaS技术：支持多种IaaS技术和多云的部署，包括公有云和私有云

    多方位的开放将计算资源的抽象提高到应用服务层面，同时将应用的运维交由平台来自动管理，也使得PaaS有效地提供应用程序的可移植性。同时，通过提供方便的工具和不断扩展的服务让开发者对于开发语音、框架、服务和基础设施有了更多的选择自由度。通过计算资源的安全隔离，使得计算资源得以有效的安全的交付和管理。当然，从像Cloud Foundry这样PaaS技术到真正实现PaaS云应用平台服务还需要很多工作。图1是一个基于Cloud Foundry的典型PaaS架构。

    基于 Cloud Foundry 的 PaaS架构

    云应用平台的市场需求

    事实上，市场对云应用平台服务的刚性需求不断的增长，但目前大家理解的IaaS和PaaS反映对计算平台资源抽象的两个极端：PaaS对计算资源的抽象主要从应用和服务层面来进行，而IaaS则更多是物理计算资源的抽象。用户应用需求的多元性需要多元的计算资源抽象。单独IaaS或PaaS提供的服务不可能完全满足市场的需求。下面两个场景则反映了这样的需求：

    一个企业应用软件项目周期一般需要经历多个阶段，比如开发、集成、测试和生产。项目团队需要建立不同的软硬平台支持相应的项目阶段，并且需要不同的训练有素的IT人员来对它们进行管理。另外，从一个到下一个阶段过渡一般需要数月，这也对于连续不断的迭代开发、测试、集成和部署的需求难度增加。而像PaaS的云计算平台服务的支持可以整合这些不同的平台，同时也显着地节省开支和时间，为不断的迭代开发、测试、集成和部署提供方便。据估计，由于缺乏合适的云应用平台的支持，美国近几年年企业每年的IT支出浪费超过300亿美元 .

    以移动和社交应用为代表的互联网经济目前在经历爆炸式增长。这种新的经济具有短平快的特点，要求应用从创新想法到投入市场的周期比以往任何时候都要大大地缩短。大量新的开发者因而也源源不断地进入应用程序开发行业，而这些开发者中的很多不具备相应IT专业知识和经验。如果没有合适的云应用平台支持，应用部署仍然缓慢和痛苦，应用的扩展非常困难，各种服务的管理需要占用很多时间，由此维持应用可靠地运行所需要的工作费时费钱，而且大都是与特定应用无关的重复性IT事物，如应用程序的开发管理，编译，集成，部署，运维，缩放和监控。开发者希望更多地专注于应用的创新和开发，而不被繁琐的IT事物束缚住，实现应用创新的自由和民主。

    企业IT的需求和新经济的发展需要应用生命周期管理变得更快捷和容易。云平台给人们带来的希望包括解决上面这些问题，提供高效的应用开发部署，监控管理，将抽象层面从虚拟机和操作系统提升到应用和服务，以及平台本身的高可用，高容错，可监控，扩展性，容易部署和更新，从而实现简单和敏捷的应用生命周期管理。

[page]    特别是企业云应用平台市场正处于一个快速成长阶段。企业目前正积极的寻求合适的云战略，问题已从“为何”变为了“怎样”.90%的企业和机构考虑采用云计算技术，近80%的企业希望采用多云的应用部署。IaaS首先在企业生产获得牵引力， 通过提供虚拟计算、存储、数据库和其他基础设施硬件服务为企业提供IT资源的整合和管理。但人们发现，IaaS 远远不能满足企业IT的需求，特别在IaaS上进行应用的开发、集成、部署和运维还是相当的费时费钱。由于PaaS通过像Google App Engine 和 Heroku等服务已被充分验证，作为“最后一英里”的云技术，是企业云计算战略的一个关键组成部分。但是不论是IaaS还是PaaS单独都不可能完全满足用户的需求，目前用户以开始考虑和实施IaaS和PaaS的相互渗透和融合。实际上，他们并不关心这些服务是姓“I”（基础设施）还是“P”（平台）。他们希望新的云计算平台能整合企业的各种需求，提供多元的计算资源抽象，让新的应用和服务的开发和部署变动非常迅捷，能让应用保持持久运行。

    需要新一代云应用平台？

    云计算市场希望新一代的云平台能呈现这些景愿，将复杂的云基础设施和各种应用资源变成可配置可管理的实体；提供灵活多样的不同抽象程度的计算资源实体以满足不同业务的需求；让创新更容易和更快捷的同时，还能够能提供企业所需要的对平台本身的控制和能见度。这个新一代的云应用平台应该整合目前包括 PaaS和IaaS 在内的多种技术，同时支持云服务的不同部署方式，包括公有云，私有云，社区云，和混合云，我们暂且称为 InPaaS （Infrastructure-and-Platform as a Service）。具体来说，InPaaS云平台技术具有高可用、高安全、易交互、易组合、易监管、易审计和易维护等特点，特别包括以下的一些功能：

    计算单元管理：根据用户和角色使用平台的不同需求满足其对计算平台资源需求的不同抽象，提供包括虚拟机、虚拟机+OS、容器+应用服务器和容器+应用服务器+框架+应用代码包等不同的计算资源组合单元。对计算单元进行统一交付和管理。

    资源组合和调配：计算单元、服务组件和数据等资源是可配置，可组合，易变更和自适应的；根据不同应用的需求，应用可以通过不同的计算资源和服务组件来实现动态整合并安全交付。

    数据服务：通过数据生命周期管理，包括数据资源的生成和获取，分析和存储，以及处理和检索等。提供平台本身和应用监控，审计，安全和管理的数据服务需求，也作为数据服务组件交付给用户应用使用。

    安全和隔离：平台和计算资源的多维度的安全防护；将安全服务化。对计算资源单元，存储和网络进行有效的隔离和防护，防止非授权的访问和平台内外攻击。实时防火墙，实时的访问策略生成和控制。身份管理和访问授权。持久的审计日志记录和分析。

    安全可信的混合架构：安全可信统一平台支持多云基础架构平台技术；支持公有云，私有云，混合云等部署方式。安全通信机制实现各计算资源单元和组件间的安全通信和协调。支持应用迁移和异地灾备。支持有保证的高SLAs.

    实现InPaaS云平台不是简单地将PaaS和IaaS进行集成，因为目前各种IaaS和PaaS的多种功能重叠、使得叠加后系统性能降低，用户使用复杂度增加。需要更深层了解用户需求，找到适合市场需求的解决方案。另外，人们不断地从不同角度来开发一系列新的云计算技术以解决不同的市场需求，而这些也可以作为InPaaS所需要的一些技术元素。比如，Docker等新一代轻量级容器将有可能成为 InPaaS所需要的轻量级容器技术的候选，以实现所需要的计算资源抽象，交付和管理。此外，SDN等技术也可能是一个实现InPaaS各个节点间和跨云的安全有效的通讯机制。

    就整体解决方案来说，Cloud Foundry 之父Derek Collison和他的初创公司Apcera在云平台技术上走在了前面，他们通过全新的技术架构设计开发出一种策略驱动（policy-driven）的新一代企业云平台 Continuum来整合目前的 IaaS、PaaS和SaaS（下图）。其核心是通过透明地导入策略来提供企业IT所需要的控制和能见度。此外，微软前高管和华纳兄弟的技术总监Jonathan Murray提出了相近的可组合的企业（composable enterprise）的概念来定义新的云平台服务，通过它企业可以建立应用创建，托管，监控一条龙的快速服务来满足业务成长的需求。用户可以通过其来加速生产，应用开发变得越来越标准化。应用会变得比任何时候都更加容易创建，越来越多的服务将不同的组件组合在一起。

    Apcera 的 Continuum 架构