为什么声明性模型对于 NetOps 自动化很重要？

如果你要让所有的事情自动化，你就需要使用声明式的方式。 原因如下。

每当我们谈论自动化时，特别是在 NetOps 和应用服务方面，我们都会敲响声明性的鼓。 但我们尚未真正深入探究它为何重要以及它有哪些好处。 我的目标是立即纠正这个问题。

为了唤起您的记忆，目前有两种模型用于自动化配置和部署一切。

第一种是命令式，我们通过这种命令式告诉目标系统如何去做我们想要做的事情。 如果您曾经打开到系统的 SSH 隧道并在 CLI 上输入一组特定的命令，那么您就参与了命令式配置模型。

第二种（也是首选）是声明性的，我们告诉目标系统做什么，但没有告诉如何做。 出于多种原因，大多数网络自动化解决方案都采用了这种模型，其中最突出的原因是学习和集成特定环境中可能存在的数百种设备和系统需要花费大量的成本和时间。

因此，在命令式模型中，我们必须具体说明配置系统所需的每个命令（或 API 调用）。 在声明式模型中，我们通常仅指定描述我们想要的内容的键值对，然后让其他系统负责执行命令来实现这一点。

非常简单，轻而易举。

现在来回答为什么这很重要的问题。 当你要实现所有事物的自动化时，采用声明式模型有四个主要好处。

1. 减少人为错误

我们知道，大约 22% 的生产中断事件是由于人为错误造成的。 一些相当引人注目的事件（我就不重复讨论了）直接被归咎于简单的人为错误。 在命令式模型中，依赖于 API 调用，每个调用都是一个等待发生的潜在事件。 如果您没有验证变量，或者忘记检查错误代码，或者其他一百种可能的情况，您可能会遇到简历生成事件。 这是一件坏事。

声明性模型基于某种模板或配置文件，该文件将在使用 API 调用执行之前进行解析和验证。 虽然你仍然可能会弄乱配置文件或模板，但是这样做的机会是有限的，因为你正在减少所需的代码。 代码越少通常意味着犯错的机会越少。

2. 减少技术债务

技术债务是我们从开发中获得的一个有趣的比喻，它提醒我们选择的长期成本。 技术债务以多种方式随着命令式模型而增加。 首先，将脚本与我们的目标系统的 API 耦合。 该 API 可能不支持其他任何内容，这意味着我们正在根据每个系统开发脚本。 配置步骤也可能因应用程序而异 - 并非所有内容都是 HTTP，并且并非每个基于 HTTP 的应用都需要完全相同的服务配置。 所以现在我们正在根据每个应用程序、每个系统构建脚本。 基于这个选择，会产生大量的脚本和大量的债务。

相反，声明式方法可以使用相同的部署过程脚本和系统。 虽然模板/配置仍可能是特定于应用和系统的，但它是一个单独的文件。 它消除了脚本的复杂性和数量，从而大大减少了技术债务。 现实情况是，我们的选择总会给我们带来一些债务；我们的目标就是将其最小化。 

3. 消除版本冲突

当您将配置和部署流程与 API 绑定时，您就与该版本的 API 绑定在一起。互联网上有许多社区，其中有充满敌意和愤怒的开发人员大声抱怨 API 的更改以及更改其应用程序所需的工作。网络和应用服务也可能发生（并且将会发生）同样的情况。 因此，如果您受限于某个版本的 API 并且发生了一些变化，您猜会发生什么？ 您将一直更新（或许是重写）脚本，直到天荒地老*。

但如果您采用了声明式模型，您很可能能够忽略对 API 的任何更改。毕竟，您不是使用 API 来告诉系统如何部署服务，而是告诉它需要部署什么。

4. 减少领域专业知识要求

让我们面对现实，如果我要使用网络或应用服务的 API，我必须了解该系统。 如果您不知道虚拟 IP 和虚拟服务器之间的区别，那么您已经遇到麻烦了，我们几乎没有讨论节点与成员。 命令式的基于 API 的方法要求您足够了解目标系统，以便浏览其配置。

使用声明式模型，你需要对目标系统有较少的专业知识，这意味着开发人员和 DevOps 都更有可能使用该方法来自助服务应用。 当然，你仍然需要专家，但对服务消费者的要求会减少，并将配置和部署的负担分散到更广泛的受众身上。

还有其他原因让您希望采用声明式模型来实现 NetOps 自动化工作，但这四个原因最为引人注目。 这是因为它们有利于 NetOps、企业以及需要自助访问网络和应用服务以使应用程序运行得更快、更安全的不断扩大的组成部分。