什么是数据作为基础设施？

数据基础设施由https://loading.io/pattern/m-matrix/进行混排

上周的一篇回應文章1結尾是“為什麼不直接使用原生格式和簡單的文本清單，而舍弃这些过于复杂的MVP工具呢？”這聽起來像是“数据即基础设施”。

虽然“基础架构即代码”（Infrastructure as Code）已经被广泛理解和采用，但是“数据即基础架构”则没有被广泛使用（请参阅 Reddit 讨论），也没有那么一致。

它被用来描述Ansible，Idem，Crossplane，以及Kubernetes。在Ansible中，“基础设施即数据”的意思是指“用简单的机器可读格式来描述系统”。Idem将其描述为“描述你想要的基础设施的纯粹数据”。这个术语指的是在Crossplane中，编写纯数据文件并提交给控制组件，以封装和执行资源配置逻辑。在Kubernetes方面，所有的Kubernetes资源都可以用一个简单的YAML文件来表示。

使用这种数据序列化格式是否足以将这些工具与基础设施即代码区分开来？

一方面来说，AWS CloudFormation 使用 JSON 和 YAML 表示，而 Terraform 有一个 JSON 语法，由 Terraform 的 CDK 生成的。Pulumi 甚至也支持 YAML 格式。

     - name: 创建地址
       google.cloud.gcp_compute_address:
         name: "{{ compute_address_name }}"
         region: "{{ gcp_region }}"
         project: "{{ gcp_project }}"
         auth_kind: "{{ gcp_cred_kind }}"
         service_account_file: "{{ gcp_cred_file }}"
         state: present
       register: 注册

另一方面，值得一提的是，Ansible 通常使用 Jinja 模板化（如上所示），类似于 Helm。Idem 提供了一个 参数替换语法。Crossplane 资源可以通过 Kubernetes 配置工具（例如 Helm）来生成，并且 Crossplane 组合定义被描述为“用于创建多个管理资源的模板”，并且还可以通过执行 函数 来生成管理资源。

如果基础设施配置以一种类似代码的格式表示，需要经过评估才能生成配置，从用户的角度和工具及工作流程的角度来看，这在实际使用中与“基础设施即代码”几乎无法区分。确实，有人认为“基础设施即数据”是“基础设施即代码”的一种实现方式，或者说是IaC的一个子集。

与这种说法相反，有些人则认为模板的输入参数实际上也是数据。CloudTruth 将此称为配置数据，这意味着... Helm values 文件和 Terraform vars 文件确实也包含数据，但我认为这属于另一类——输入数据。

StackQL 和 IaSQL 通过数据库查询来查询和操作云资源，采用了一种不同的方法。StackQL 还提供了一种类似于基础设施即代码 (IaC) 的模板格式，用于生成查询，再次模糊了界限的划分。

你认为基础设施即数据（IaD）有哪些独特之处？你认为它相比基础设施即代码，或者与其他形式的基础设施即代码相比（如果你认为IaD是其子集）有显著的好处吗？例如，你认为它是否使基于状态的约束更容易实施？你认为基础设施即数据是否值得拥有自己的术语？如果是的话，你希望它能意味着什么并如何使用它？我之前认为语言无关紧要。这同样适用于基础设施即数据吗？

随时可以在这里回复我，或者通过 LinkedIn 或 X/Twitter 发消息给我，我也会在这些平台上转发此内容。

如果你觉得这个有趣，可能会对我的“基础设施即代码及声明性配置系列”中的其他内容感兴趣。更多详情请参阅我的基础设施即代码系列文章：点击这里。