欢迎来到「不可变基础设施」时代

伴随着最近的“容器革命”，一种新概念变得流行起来：不可变基础设施。事实上，「不可变基础设施」这一律念不是刚刚冒出来的，它也不是必须须要容器技术。然而，经过容器，它变得更易于理解，更加实用，并引发了业内普遍注意。

什么是不可变基础设施？

我将其定义为在生产环境中仅经过替换组件而不是修改组件来更改基础设施。具体地说，这意味着一旦咱们部署了一个组件，咱们就不会再修改它了。这并非说组件没有任何状态变化（毕竟丝绝不变也就意味着它不是一个很是实用的软件组件），而是说运维人员无须在程序的原始API /设计以外引入任何改变。

这种状况并不罕见，举例来讲，假设咱们想要更改某一配置文件，而该配置文件又正在被某些应用程序使用，若是是动态基础设施，咱们可能须要使用一些脚本或配置管理工具来进行这种更改。它会对有问题的服务器进行网络调用，而后执行一些代码来修改文件。它还可能了解并修改该文件的依赖关系（好比须要重启的程序）。随着时间的推移，这些关系可能会变得愈来愈复杂，这就是为何许多CM工具都有一个资源依赖模型来帮助管理它们。

动态基础设施VS.不可变基础设施

动态基础设施与不可变基础设施之间的权衡其实很是简单。使用网络和磁盘IO等资源，动态基础设施效率更高。在这种效率下，传统上它的速度要比不可变快，由于它不须要像许多版本的组件那样须要推送那么多的比特或存储。回到咱们更改文件的例子。传统上，比起更换整个服务器，更换单个文件无疑更快。

另外一方面，不可变的基础设施为结果提供了更强有力的保障。不可变的组件能够在部署以前预先构建，生成一次，而后重复使用，这与动态基础设施不一样，后者的逻辑须要在每一个实例中进行评估。这就可能形成意料以外的结果，由于您的某些环境可能处于您指望的不一样状态，致使部署出现错误。您可能只是在配置管理代码中犯了某个错误，但您又没法在本地复制生产环境的情况，所以可能很难测试该结果并发现错误所在。毕竟，这些配置管理语言自己很复杂。

在“计算机协会”（ACM）杂志ACM Queue的一篇文章中，Google的工程师清楚地阐述了这一挑战：

结果是，人们试图经过消除应用程序源代码中硬编码的参数来避免这种神秘的“配置”。它不会下降操做复杂性或使配置更容易调试或更改；它只是将计算从真正的编程语言转移到特定于领域的编程语言，而这个领域一般具备较弱的开发工具（例如调试器、单元测试框架等）。

容器时代的变局

效率的权衡一直是计算机工程的核心。然而，随着时间的推移，这些决策的经济学（包括技术和金融层面）都在改变。

在编程的早期，开发人员被教导使用简短的变量名，以牺牲可读性为代价来节省几字节的宝贵内存。为了解决早期硬盘驱动器的空间限制，开发了动态连接库，以便程序能够共享公共的C库，而不是各自须要本身的副本。

而在过去的十年里，因为计算机系统的强大功能的改变，这两种状况都发生了变化。如今，开发者的时间比咱们经过缩短变量节省的成本要昂贵得多。像Golang和Rust这样的新语言甚至带来了静态编译的二进制文件，由于若是发生错误的DLL，将没法处理平台兼容性问题。

基础设施管理正处于相似的十字路口。公有云和虚拟化不只使得服务器（虚拟机）的速度快了几个数量级，并且像Docker这样的工具已经建立了易于使用的工具，来处理预先构建的服务器运行时，来经过层缓存和压缩来实现高效的资源使用。这些功能使得不可变的基础设施变得实用，由于它们是如此的轻量级和无摩擦。

Kubernetes在不久以后也进入了这一领域，接过这一火炬并继续朝着目标，建立了一个“云原生”原语的API，它假定并鼓励了一种不可改变的哲学。例如，ReplicaSet假设在咱们的应用程序生命周期的任什么时候候，咱们均可以(而且可能须要)从新部署咱们的应用程序。为了平衡这一点，Pod Disruption Budgets（Pod应急预算）将指导Kubernetes应用程序如何从新部署。

以上种种进步的融合使咱们进入了不可改变的基础设施时代。并且随着更多的公司参与进来，这个数字还会增长。今天的工具使咱们比以往更容易接受这些模式。那么，你还在等什么？