翻译自 A Brief DevOps History: The Roots of Infrastructure as Code 。译者不知受到什么启发，几年前编写过符合 IaC 风格的 WebLogic 和 WebSphere 自动化脚本库：https://github.com/rocksun/ucmd 。
如果您回顾一下计算的历史，就会发现配置管理工具自 1970 年代就出现了。我们是如何从 make 文件到 Terraform 配置的？
DevOps 充满了流行语、行话和缩写。 DevOps 本身才出现了十多年，所以其中一些概念相对较新。然而，有些已经很老了，它们的定义和用途随着时间的推移发生了变化。今天，我将探讨基础设施即代码的历史。它可能看起来很新，但它比您可能意识到的更古老且历史更复杂。
当有人说“基础设施即代码”时，您的想法可能会跳到像 Chef 或 Ansible 或 Terraform 这样的工具，但它的起源远不止于此。它起源于配置管理，大多数配置管理工具都使用某种基础设施即代码方法。事实证明，自从我们第一次决定让机器相互通信以来，我们在管理和配置机器队列时遇到了麻烦，无论它们是云提供商上的虚拟机或容器，还是实验室中的物理机器。
如果您深入研究并一直追溯到现代计算的黎明，配置管理工具自 1970 年代以来就已经存在。 Unix “make” 于 1976 年发布，允许进行基本形式的配置管理，而 PXE 引导于 1981 年引入，为整机带来了早期形式的配置管理。
这两种工具至今仍在广泛使用，但当大多数人想到配置管理或基础设施即代码时，他们不会跳到脑海中。您可能很容易争辩说这两种工具都不是真正的配置管理，但事实是，在我们拥有更复杂的工具为我们做这件事之前，我们已经使用这些工具来尽我们最大的能力来自动化配置。
配置管理的现代定义最古老的开源示例之一是 CFEngine，最初于 1993 年发布。它是由 Mark Burgess 在攻读理论物理学博士后期间创建的。 Mark 的任务是维护一系列 Unix 工作站，它们都运行不同版本的 Unix 并遇到不同的问题，这需要大量耗时的手动脚本编写和一对一的用户支持。
抽象出领域特定语言 (DSL) 背后的这些平台之间的差异使他能够显着减少维护它们所涉及的工作量，于是 CFEngine1 诞生了。这种配置管理方式为我们服务了很长时间，CFEngine 通常被认为是当今工具最早完全形成的起源。
那么，如果配置管理如此古老，为什么基础设施即代码看起来如此新鲜？是因为使配置管理有用的复杂性并不存在于学术界和企业之外吗？不是这样的。但像技术中的许多进步一样，需要处理越来越大规模的复杂性推动了基础设施即代码的演变。
在云计算普及之前，提供计算资源意味着获取新的物理基础设施。公用事业计算或“按使用量付费”的模式尚未广泛应用，因此像今天这样无限扩展规模并不容易。但随着技术的发展，“大规模”所代表的门槛也在不断变化和增长，在 2006 年， AWS 发布了 EC2 的第一个版本。
迅速地，可扩展性成为了每个人的问题。 EC2 使得任何人都可以使用他们所需的精确计算资源变得容易，但是用于管理该基础设施的工具没有跟上为这种环境构建的应用程序迅速增长的复杂性。
手动配置和管理数百个不同环境的指令速度慢且不可靠，因此引入了一类新工具来配置和管理基础设施。
同时，Puppet 和 Chef 也曝光了。 Puppet 于 2005 年发布。它使用自己的声明性领域特定语言来定义系统的资源和状态。 Puppet 实现了许多与 CFEngine 相同的目标，尽管使用的是不同的语言，但大大降低了学习曲线。
2009 年，我们得到了 Chef。与 Puppet 不同，Chef 是围绕 Ruby DSL 构建的。虽然这意味着您可以使用一种接近成熟的 Ruby 的语言，但对于来自 IT 运维背景而不是编程背景的人来说，它可能不太友好。对于很多用户来说，这两个工具之间的区别在于您是否更喜欢编写配置文件或看起来更像程序的东西。
2012 年，Ansible 发布。与 CFEngine 和 Puppet 一样，它使用一种声明性的、特定领域的语言。然而，与 CFEngine、Puppet 和 Chef 不同，Ansible 是无 Agent 的，这意味着它控制的机器上没有安装或运行任何 Ansible。相反，它通过临时 SSH 连接工作，这非常酷。
这些工具各自以其革命性的方式，主导了市场多年。但我们往往将它们视为配置管理工具，尽管它们与现代基础设施即代码工具执行相同的任务，并可以以类似于代码的方式为我们提供基础架构。那么这条线在哪里？模糊程度有多大呢？
最初，我想说这是为应用程序而不是为整个机器管理资源和状态之间的区别，但这并不完全清楚。用于配置机器和操作系统而不是应用程序的工具确实存在于“配置管理”保护伞下的它们自己的类别中。
因此相反，我的观点是：配置管理与上述这些工具一起独立存在，并且作为更大的基础设施即代码概念的一部分存在。
也许更准确地说，基础设施即代码是配置管理的自然演变。那么，这种必然性是如何发生的呢？
容器技术的日益普及和 Docker 在 2013 年的推出导致复杂性再次急剧增加，允许更复杂的解决方案和架构，但在可扩展性方面造成了新的痛点。
这也是在将应用程序开发为微服务集合而不是单体的概念真正开始流行的时候，Docker 非常适合处理这种设计范例。突然之间，我们需要为此类工作构建的更智能的工具。
2014 年，即 Kubernetes 推出的同一年，Terraform 也推出了。与其大多数前身一样，它使用特定于领域的语言提供广泛的基础设施配置管理；但与其前身不同，它主要是为管理 IT 运营工作流而设计的，这些工作流现在比以往任何时候都更加多样化和复杂。 Terraform 已经变得非常流行，并且由于社区的不断壮大和向云的扩展而继续流行。
到目前为止，我们已经走了很长的路程，每种工具都有其优点（通常反映在它们建造时的时间和环境中），但IT运维团队和网站可靠性工程师仍然对基础设施负有过大的责任。
与此同时，软件工程师被赋予使用他们不熟悉的 DSL 工具，并且越来越面临情况，这些情况可以从编程语言的表现力中受益，但却没有真正处理它的方法。事实上，像 Pulumi 这样的产物开始从编程语言能力而非 DSL 接近工具。
沿着这个工具时间轴的每一步都让我们更接近 DevOps 的理想状态。为了简单起见，我跳过了一些工具，比如 Pulumi、Nix 或 SaltStack，但可以说从 make 文件到完整的基础设施即代码演变的最详细时间轴要比这篇长博客文章更长。
基础设施即代码感觉很新颖，但像计算机中的大多数事物一样，它实际上已经存在了很久——我们只是从不同的角度来解决相同的问题，并围绕当今环境建立抽象层以解决我们已经解决过的问题。