随着运维流程变得越来越灵活，IT团队面临着越来越大的复杂度。当应用动态改变时，可以使用敏捷或者持续应用开发。但是当IT资源本身动态变化的时候怎么办呢?

多云和混合云是这一新的、动态的IT大格局的一部分——并且带来了新的风险。要解决这里的问题，一些企业使用了基础架构即代码方案。

配置管理(CM)在大规模IT基础架构里一直是必需配置。有一些CM工具，来自于云供应商，比如Amazon Web Services或者Microsoft Azure，或者来自于虚拟化或私有云软件供应商，比如OpenStack或者VMware。

基础架构即代码通过为应用程序创建虚拟托管模型来扩展了CM。这样虚拟的托管模型散布在多个云环境和数据中心平台里。

虽然基础架构即代码是CM的一种扩展，它其实是作为DevOps的扩展才开始流行起来。用户无法在还没有搭建好的服务器或者云服务上部署应用程序。因此，DevOps工具和脚本必须包含这些配置任务。这使得DevOps脚本和工具是和配置绑定的;如果从一个云平台改变到另一个平台，用户就必须更改脚本。基础架构即服务提供了一种方式，将应用程序的虚拟世界和底层资源，包括云，隔离开。有更多的托管方案存在，基础架构即代码就会更加有价值。

基础架构即代码模型为部署描述创建了中间层;用户将应用程序部署到基础架构即代码所创建的抽象的托管模型里，基础架构即代码随后将其适配到当前使用的任意云，多云或者混合配置环境里。基础架构的变动在应用程序和运维层是不可见的，并且添加新的云供应商仅需要在基础架构即代码里完成其定义即可。

但是，基础架构即代码的用户需要注意如下三大重要步骤：

1.将基础架构即代码从DevOps中隔离

IT团队能够将基础架构即代码部署到定义了配置脚本的任何环境里，并且使得应用程序能够适配几乎所有公有云服务或者数据中心平台。

IT团队需要基于哪种基础架构即代码将部署配置，来定义IT资源的抽象模型。基础架构即代码工具和实践变化很大。一些用户为每个应用程序都构建了基础架构即代码，而另外的用户为每种类型的云托管环境，比如基础架构即服务，平台即服务或者Docker，构建通用的模型。

总的来说，最好减少创建出的抽象托管模型的数量，因为当添加新的托管选择时，你必须调试每个模型。工具允许的情况下，考虑层级构建模型，这样部署应用组件——或者某个应用的一部分——的基础架构即代码模型，可以在部署整个应用程序的模型里直接引用。

2.为使用的所有云或者数据中心环境保护对基础架构即代码的支持

一旦你理解了所需模型，要确保它们能够支持计划使用的特定的云供应商和数据中心的配置。几乎所有基础架构即代码工具，比如Chef和Puppet，都让用户为任何环境定义自己的配置规则，但是流行的公有云，私有云和平台方案——比如hypervisor，容器系统和服务器操作系统——都作为基础架构即代码工具集的一部分提供。还可能有社区的支持，其他用户将他们的配置规则贡献出来。从已经能够工作的配置上开始开发，比从头开始构建自己的要更加容易。

3.将事件流从基础架构推广到部署工具

完成基础架构即代码方案中最微妙，困难和重要的事情是，处理基础架构即代码和其他工具集成的事件流;大多数情况下，这意味着使用DevOps工具。应用程序生命周期运营管理需要根据情况选择合适的软件——这些条件就是基础架构即代码里的事件。这些事件，通过托管资源生成，充当干什么事情的信号。他们通常激活一个自动化流程，比如通过在别的地方托管来替换发生故障的应用程序组件。

基础架构即代码事件和流程紧密链接，这也是为什么大多数计划使用混合或者多云部署的企业会研究其DevOps工具对基础架构即代码的支持，而并不使用单独的工具。基础架构即代码和DevOps的集成确保事件触发流程的正确设计和实现。

将基础架构即代码集成进DevOps还能够帮助用户避免常识性错误。如果已经有了特定的工具，并且如果基础架构即代码集成进了DevOps的话，使用基础架构即代码计划托管资源就会更为容易。这是因为虚拟化整个部署流程以及基础架构即代码的资源角色会更加容易一些。DevOps工具和包会公布其支持的公有云服务，如果DevOps工具包含基础架构即代码组件，用户就知道该工具能够和列出的公有云一起工作。

要更加高效，基础架构即代码必须和DevOps紧密合作，但是同时又保持自己的特性。如果不仔细的话，就会开发出界线模糊的配置和部署实践，并且逐渐侵蚀资源的独立性——这其实是基础架构即代码的最大优势所在。在多云和混合云的部署里，维护敏捷基础架构至关重要，因此这应该成为特定的目标。