如果没有每个应用程序的架构，就无法实现不可变的基础设施

早在 2013 年，我们就接触到了不可变服务器的概念。 正如术语“不可变”所暗示的那样，不可变服务器是静态的。 它的配置是固定的，不能（或至少不应该）改变。 如果需要更改，则具有新配置的新服务器将替换正在运行的服务器。 之所以这样做是可取的，特别是在云和高度自动化的内部部署环境中，是因为它简化了配置并提高了推动部署的自动化系统的可靠性。

这一概念在云和容器环境中甚至对于网络和application服务都发挥得很好，但在传统的共享基础设施架构中却不那么好。

这是因为共享基础设施的定义意味着多个正在运行的服务。 根据 F5 iHealth数据，多个可以意味着平均 123 个单独的配置（虚拟服务器）。 为了对一个虚拟服务器进行单独更改而尝试停止并重新部署 122 个虚拟服务器，这是不切实际的，也不建议这么做。

但这并不意味着这个概念不切实际或不可取。 采用不可变基础设施以及自动化和基础设施即代码 (IaC) 系统的关键是转向每个应用程序架构。

为什么要使用不可变基础设施？

为什么要对企业网络架构进行如此重大的转变？ 让我引用我自己的话，因为今天我想不出更好的方式来重述：

因为，熵。

Ivar Jacobson等人在《面向对象软件工程》中描述了软件熵定律： “用例驱动方法”：

热力学第二定律从原理上指出，封闭系统的无序性不能减少，只能保持不变或增加。 这种无序性的量度就是熵。 该定律对于软件系统来说似乎也是合理的；随着系统的修改，它的无序性或熵总是增加。 这被称为软件熵。

该定律也适用于必须应用固件或系统级更新的系统。 部署了哪些热修复和补丁。 对于配置的紧急调整，在理想情况下，只能通过严格遵循的变更管理流程来进行更改。 不可变（可抛弃）基础设施试图解决的问题是，你在系统中引入的变化越多，系统似乎就会变得越复杂和不稳定。 紊乱。 混乱。 熵。

这不仅仅是对应用程序服务配置的改变或为一些最近发现的漏洞部署紧急虚拟补丁。 这些是更改application服务配置的充分理由，但并不是唯一的理由。 热修复、补丁和版本依赖性也是您需要更改在共享基础架构上运行的 123 个配置之一的充分理由。

通过转向每个应用程序架构，您可以消除其中一个、两个甚至十个实例对在共享基础架构上运行的其他数百个实例造成中断的可能性。 为每个应用程序提供自己的数据路径，本质上就是为支持不可变基础设施方法奠定了基础，这种方法将更好地支持向自动化、基于代码的基础设施部署实践的转变。

这意味着一个完全基于软件的application服务管道——application服务部署在“微应用服务”架构中，类似于在容器中部署微服务的方式。 

Chef 的Julian Dunn在他的博客“ Immutable Infrastructure”中很好地阐述了这一点： 实用吗？

不可变基础设施通常被定义为您构建一次的堆栈（无论是虚拟机映像、容器映像还是其他东西），运行一个或多个实例，并且永远不会再改变。 部署模型是终止实例/容器并从第一步重新开始：构建新映像并丢弃旧实例。

因此，如果我们将其应用于与给定application最紧密耦合（亲和）的application服务，那么您最终会得到一个两层网络架构，该架构包含核心、通用共享服务（如网络 DDoS 和通过传统基于端口的防火墙进行访问），这些服务输入到每个应用程序的“堆栈”，该堆栈被视为不可变的，并使用基础设施即代码概念进行部署/管理。

但是，如果没有每个应用程序的基础架构，您就无法实现不可变，因为您需要首先将相关的application服务与其共享平台分离。 如果您可以使用相同的平台（仅以软件形式存在），这个过程就会变得更加容易，因为您已经掌握了所需的大量知识和工具集，可以全力推进每个应用程序的不可变模型。

即使您没有考虑真正的不可变基础设施，在最有意义的时候利用它的能力（新的基础设施版本、热修复、补丁等）也会让您和基础设施支持的应用程序的 DevOps 所有者的生活变得更轻松。