当我们谈论一个PaaS解决方案快速部署能力是筹码。虽然我认为谈论快速部署和也许比较速度的一个解决方案，另一个有趣的是，我认为谈论一个特定的解决方案部署的机制是更有趣的。也就是说，我觉得更有趣，更重要的问题是：什么部署的风格是特定的解决方案？
在一个非常高的水平，我觉得两个主要部署风格渗透到景观PaaS的今天：包含和引用。我想比较每一种方法，但在这之前，让我用几句话来描述每个风格。
- 包含 ：所含的部署模型，PaaS解决方案部署包包含的大多数，如果不是全部，所需的配置以及应用，配置的逻辑基础上的环境。比如，如果一个解决方案来部署虚拟图像中所包含的模型中，虚拟机将具有必要的信息和逻辑嵌入配置在启动时。它并不一定需要与外部系统或等待其他演员的指示。
- 参照 ：参照部署模型，PaaS解决方案部署环境中使用一个最小化的基本包。在一些点在部署过程中，部署的环境促使必要的配置信息以某种方式与第三方通信。让我们回到上面的例子中，如果被部署在一个虚拟的形象参照模型，虚拟机将启动，然后与第三方服务（无论是通过发起一个请求或等待指令）进行通信。这种第三方服务将发送主办的环境内的虚拟机的配置信息去说明。
当比较这两种方法，它是有帮助的，理解各的优点和缺点。细看包含模型揭示了一个显而易见的好处：那就是速度。在这个模型中，部署包包含了大部分，这将需要什么，以充分配置本身。它不依赖，联系外部服务和拉下必需的二进制文件和配置信息。
这种优势来源于一个明显的缺点：管理人员的负担。通过建立越来越多地信息进入部署包，必须维护和更新的内容量增加。虽然它不是一个巨大的问题，如果你只有少数几个离散的包，你可能无法依靠。您可能期望一定的时间后，排列的数量，以支持必要花费大量的时间更新部署包。如果是这样的话，你可以很容易地结束了行政费用增加的情况下快速部署的好处是否定的。
引用的方法避免了上述缺陷。包含模型中的所有内容，如包装，而是在参照模型的部署软件包知道足够多的与外部系统的集成，以获得正确的配置信息（认为厨师和木偶）。这意味着，你只需要更新和维护配置数据和配置行动，在一个单一的位置，而不是在每一个部署包。由于所需的不同环境中的数量增加，这种方法可以意味着一个显着的减少在管理人员的负担。
当然，这枚硬币有一个侧空翻。引用的方法通常会导致较长的部署时间 - 依赖于安装和配置内容为您的环境，由于部署包包含内容很少，在部署过程中，他们必须以其他方式接收该数据。这可能会或可能不会为您的特定用途的情况下是一个大问题，但它是一个值得考虑的潜在的缺点。
那么哪种方法更好呢？我认为，一个来自众多用户的经验，有没有办法来概括这个问题的答案。一般情况下，不经常更新的内容和环境的排列数是相当约束的，所包含的部署模型可以极为有效和高效的。另一方面，在内容是动态的，不断变化的情况下，参照部署模型是一个虚拟的要求。从用户的角度来看，我强烈建议追求的解决方案，支持两种部署模型。工具不应该决定你的方法。 应该按照您的要求，打造特定的使用场景！
