业务流程是Iaas云的重要组成部分，可以帮助管理员更容易的进行部署。

诸如OpenStack的Iaas云应该是动态的。如果管理员需要手动创建云结点、实例和网络，那就完全没有利用云计算的灵活性。

像大多数被认为是OpenStack云的基本功能，流程作为独立组件包含在OpenStack中，被称作为Heat。如果你选择了开源的OpenStack云架构，预计大部分功能会以这种方式实现。Heat被设计为创造人类和机器可访问的服务，管理云中的基础设施与应用程序完整生命周期。

Heat通过模版实现业务流程引擎。

将物理数据中心转换为OpenStack云，需要物理到虚拟的迁移计划和工具。Heat在理论上是可以使用的，但不是以业务流程引擎为预期目的。Heat模版最适合部署相似的服务器。他们允许IT实现从旧数据中心到软件定义数据中心的过渡迁移：这通常意味着全新的架构，可以享受云架构带来的灵活性。

OpenStack Heat模版实际上与AWS CloudFormation模版格式的完全兼容，OpenStack数据中心内的实例都经过特定的配置。只要AWS和OpenStack实例的功能兼容，混合公有-私有云迁移是可以实现的。但OpenStack也不是100%能够兼容AWS的。

Heat模版在一个文本文件中描述了需要的内容，方面人员进行读写(见下述范例)。选项包括不同类型的基础设施资源，如服务器、浮动IP地址、卷、用户等等。模版同样可以管理这些资源之间的关系，还可以通过自动化实现复杂配置。

Heat并不只是创建资源；它管理整个资源生命周期。要做到这点，必须紧密与DevOps自动化服务集成，如Puppet与Chef，实现管理不同软件组件的状态。

A sample OpenStack Heat template.

heat_template_version: 2013-05-23

description: Simple template to deploy a single compute instance with parameters

parameters:

key_name:

type: string

label: Key Name

description: Name of key-pair to be used for compute instance

image_id:

type: string

label: Image ID

description: Image to be used for compute instance

instance_type:

type: string

label: Instance Type

description: Type of instance (flavor) to be used

resources:

my_instance:

type: OS::Nova::Server

properties:

key_name: { get_param: key_name }

image: { get_param: image_id }

flavor: { get_param: instance_type }

范例中部署了一个虚拟机实例。Heat模版由两部分组成。一部分定义了参数，包括key_name、image、和instance_type。第二部分定义了通过该模版管理的资源，本例中为my_instance。为了管理这个资源，需要在一开始定义三个被成为属性的参数。在这里get_param语句定义了所有需要的属性数值。

这个OpenStack Heat是可用的，但对于需要定义成百上千OpenStack实例的管理员来说，并不会太有效果。参数值要求一个接着一个，最后实现大规模部署，这也是云计算资源通常的目标，是一个缓慢的过程。为了使其更快，需要在模版中使用环境文件。这些文件里包括了所有可用参数的数值集。

OpenStack Heat友好度如何？

虽然Heat很容易通过自动化工具实现有效和简单管理，但却不是特别方便用户使用。管理员不喜欢手动处理含有大量需求配置为ASCII文件。他们还有许多不同的选择来让云业务流程管理更轻松。

云业务流程工具目的在于更轻松的管理大规模云。许多公司都试图填补国内云管理空白，包括Cloudyn、Dell和RightScale。

是否还能够从OpenStack社区获得更高的期望呢？可能不会。虽然不是很直观，Heat确实是提供了有效的模版工具来管理云部署。这是一个后端功能，任何用户都可以打造一个灵活的前端接口来管理它。

前端的一个问题在于要如何开发才能让云业务流程更容易：为了更高效，前端工具必须能够访问OpenStack Heat模版中的相同的参数和配置选项，意味着这些解决方案也不见得会简单多少。