对于 NetOps 来说，基础设施即代码是什么？

随着 DevOps 方法逐渐渗透到网络运营中，它也带来了一些新的术语。 这些口语可能会让以前没有遇到过的 NetOps 感到困惑，并且可能会让被迫接受该方法的 IT 主管感到困惑。

其中包括基础设施即代码的概念。 在开发者的世界中，基础设施主要是部署和扩展应用程序的平台、服务器和容器系统。 基础设施主要在于计算。

墙的另一边是一套更广泛、更强大的基础设施，除了计算之外，还涵盖存储、安全和网络。 毕竟，有四种操作，所有操作都必须同步运行，才能实现持续部署，并实现 IT 和业务领导者在数字化转型中所寻求的那种优化。 这意味着基础设施即代码在生产中包含的系统、设备和服务范围比在开发中包含的要广泛得多。 应用程序部署通常意味着四个操作中的每一个的基础设施都会以某种方式受到影响。 这使得生产中的基础设施即代码变得有点棘手，但也对效率和速度产生了更大的影响。

这是因为自动化可以消除交接之间的等待时间，而这往往是部署效率低下的根源，特别是当手动流程与假期、病假和午餐时间发生冲突时。

这是一个明喻

基础设施即代码是一个比喻；这意味着我们实际上并不想（至少现在不想）将我们的网络和应用服务系统转变为我们构建然后部署的代码。 对于大多数企业组织来说，这都是疯狂的，并会破坏企业网络的稳定性和可靠性。 但我们确实希望利用将配置和配置文件与运行它们的系统分离的系统的优势。

这意味着将配置、策略和配置文件与部署它们的硬件或软件分离。

这个集合随后被视为“部署工件”，可以像代码一样处理。 这意味着它们可以在存储库中存储和管理、进行版本控制和审查。 它们可以像开发人员从存储库（如 Github）拉取、克隆和提交代码一样被拉取、克隆和提交。

我们还应该包括“自动化工件”。 这些是描述与您选择的自动化工具包相匹配的自动化任务的脚本和相关文件。 如果那是 Ansible，那么它就是剧本。 如果它是厨师，它就是一个食谱。 对于 Puppet 来说，这是一个清单。 或者它可能只是一个普通的 Python 脚本。

对于 BIG-IP 和越来越多的网络托管系统，这还包括可能进一步描述更复杂或标准化配置的模板（iApp）。 在这里使用模板是有利的，因为它可以支持核心工具集可能尚不支持的选项和应用服务。

自动化工件与部署工件一起构成了我们称之为“基础设施即代码”的集合。 假设您可以配置一个系统，然后对其运行自动化流程以根据需要进行配置。

当与针对每个应用程序的网络和应用服务方法相结合时，基础设施即代码方法可以显著降低频繁部署的风险。 通过隔离配置并将其影响限制在单个系统中，可以实际上消除部署错误的影响。 这反过来又鼓励每个应用程序的计划更好地符合业务需求和用户需求。

对于具有云意识的组织来说，采用基础设施即代码方法可以减少从数据中心到云或从云到云迁移所带来的摩擦。 由于配置与系统分离，因此它表面上可以部署在其他地方的类似系统上。

有很多好的理由促使人们努力转向基础设施即代码方法，而没有那么多理由不这样做。 基础设施即代码是实现敏捷网络组织在多云、应用驱动的数字经济中取得成功所需的最有利方式之一。