当你可以进行更基础的集成时，为什么要纠结于API？
基础设施团队采用自动化工具，期望消除手动流程并创建可预测的部署。他们实施Terraform、Ansible和Packer进行编排，使用Prometheus和Grafana进行监控。概念验证成功了，但当他们尝试在多个存储平台上扩展时，自动化策略就出现了分裂。
问题不在于自动化工具本身，而在于每个存储平台都需要单独的集成代码，即使是来自同一供应商的产品也作为独立系统运行，具有不兼容的API。当团队将虚拟机管理程序和网络自动化加入其中时，复杂性成倍增加。分散的基础设施通过强制将硬件复杂性引入管道的每一层来破坏自动化。
每个供应商都是独立平台的集合
存储供应商将自己宣传为统一的提供商，但他们的产品组合实际上是作为不同的API系列运行的。每个系列都需要单独的客户端代码、身份验证流程和对象模型。
主要存储供应商通常在其产品线中提供两个或更多不同的REST API。企业级阵列共享一个具有一致端点和身份验证的API模型。中端和超融合产品使用完全不同的REST API，具有不兼容的资源定义和URL结构。适用于一个产品系列的自动化代码在另一个系列上会失败。团队在单一供应商关系下维护多个独立的存储后端。
这种模式在整个行业中重复出现。拥有广泛产品组合的供应商为每条产品线公开单独的REST API。URL结构不同，身份验证流程不同，对象模型不同。在一个平台上有效的卷创建调用在另一个平台上使用完全不同的JSON结构和端点。团队无法编写通用的特定供应商存储代码，他们必须为供应商产品组合中的每个产品编写单独的集成路径。
即使是架构相似的产品也存在差异。处理块存储的阵列使用一种REST模式，处理文件和对象存储的产品使用不同的REST模式。两者可能都使用HTTPS和JSON，但端点、对象和Token处理方式各不相同。即使阵列来自同一供应商，块和文件操作也需要单独的客户端实现。
相似的功能，不同的实现
分散化不仅限于产品系列，还延伸到功能实现。存储平台通过不兼容的代码路径支持相似的功能。
卷配置存在于所有块平台中，但API调用存在很大差异。一些平台使用简单的Token身份验证，其他平台需要返回会话头的登录调用。一些平台在较新的固件版本中包含CSRF Token。功能集保持一致，但集成代码必须考虑特定于供应商和版本的身份验证模式。
版本控制引入了额外的变量。一些平台使用基于URL的版本控制，其他平台依赖基于头的版本协商。较新的固件公开了额外的端点或字段，而较旧版本会默默忽略或拒绝这些内容。为一个固件级别编写的自动化代码在阵列升级或团队向现有集群添加新型号时会失效。
对象模型也存在差异：
块平台围绕卷、LUN、主机、启动器和映射对象组织。
文件和对象平台以文件系统、存储桶、导出和策略对象为中心。
概念上的重叠很少。团队需要构建单独的块和文件/对象接口并同时维护两者。
基础设施即代码无法解决问题
组织通常认为Terraform提供程序或Ansible集合可以抽象存储差异，但事实并非如此。基础设施即代码工具只是集成工具使用的相同REST API的简单包装器，底层复杂性仍然存在。
供应商为每条产品线提供单独的Terraform提供程序和Ansible集合。每个提供程序公开具有不同参数结构的不同资源。为一个平台编写的Terraform模块无法移植到同一供应商系列中的另一个平台。团队需要为每个平台维护单独的基础设施即代码模块。
基础设施即代码层不能统一存储语义，它以不同的语法再现了分散化。团队用HCL或YAML替换REST API调用，但条件逻辑、版本处理和特定于平台的参数仍然存在。
多层问题
存储集成代表问题的一个维度。虚拟机管理程序和网络自动化引入了独立运行的额外层。虚拟机管理程序管理依赖于具有自己身份验证模型的单独API。网络结构配置通过使用特定于供应商的构造的不同控制器实现。完整的自动化框架必须协调跨存储、计算和网络层，而这些层不共享任何通用模式。
当虚拟机在主机之间移动时，存储路径行为可能会根据阵列模型而改变。当服务器硬件刷新时，网络适配器顺序变得不可预测。自动化通过条件逻辑吸收这些跨层依赖关系，这些逻辑随着每一代硬件和固件更新而增长。
私有AI基础设施使问题进一步复杂化。组织为AI工作负载部署具有不同性能配置文件和对象模型的单独存储堆栈。自动化框架现在必须维护传统块阵列、文件系统、对象存储和AI优化平台的存储集成代码。每次添加都会增加维护负担。
对可扩展性的影响
当存储集成需要针对每个平台和每个产品的代码时，基础设施自动化变得难以扩展。团队编写的Terraform模块在一个数据中心中有效，但在另一个数据中心中失败，因为存储供应商不同。他们为每个阵列系列维护单独的Ansible角色分支。灾难恢复站点与生产环境出现偏差，因为自动化无法解决位置之间的平台差异。
硬件刷新周期也会破坏自动化。新的存储型号引入需要模块更新的API更改。固件升级公开了旧代码无法处理的字段。团队花在维护集成代码上的时间比通过自动化节省的时间还多。基础设施即代码的承诺变成了基础设施异常即代码。
原本应该隐藏平台差异的抽象层反而记录了这些差异。存储后端成倍增加，条件逻辑在模块和角色中蔓延。版本检测变得强制性。随着环境扩展，代码库变得脆弱。
架构替代方案
存储供应商提供REST API，但仅有REST并不能创建一致性。构建可扩展自动化的组织必须考虑跨供应商、供应商产品组合内以及跨功能实现的分散化。
统一基础设施平台采用不同的方法。像VergeOS这样的平台通过单一API将存储、计算和网络集成到单一代码库中。存储抽象发生在操作系统级别，而不是通过针对每个供应商的集成代码。团队编写引用存储服务而不是存储阵列的Terraform模块和Ansible角色。硬件变化对自动化层不可见，因为平台在内部处理抽象。
评估自动化策略的团队应该评估其框架必须维护多少存储集成路径。他们应该测量现有模块中已经存在的条件逻辑。他们应该估计存储刷新后更新代码所需的时间。他们应该测试相同的自动化是否在所有集群中有效，而无需特定于平台的分支。答案决定了基础设施架构是支持还是抵制自动化。
当代码可以描述意图而不编码硬件异常时，基础设施即代码才有效。当每个平台需要单独的实现路径时，就会出现存储集成挑战，但自动化工具按设计运行。它们下面的基础引入了破坏可扩展性的复杂性。解决方案是将该基础统一到单一代码库的基础设施操作系统中。
要了解更多信息，请注册我们的实时网络研讨会：构建端到端自动化链
本文由VergeIO贡献。
Q&A
Q1：为什么存储平台的API集成会破坏基础设施自动化？
A：因为每个存储平台都需要单独的集成代码，即使是同一供应商的不同产品也使用不兼容的API。当团队尝试跨多个存储平台扩展自动化时，需要为每个产品系列编写和维护单独的集成路径，导致条件逻辑成倍增长，代码库变得脆弱，维护成本超过自动化带来的收益。
Q2：Terraform和Ansible这类基础设施即代码工具能解决存储集成的分散化问题吗？
A：不能。这些工具只是对REST API的简单包装，底层的复杂性仍然存在。供应商为每条产品线提供单独的Terraform提供程序和Ansible集合，每个提供程序使用不同的资源和参数结构。团队仍需为每个平台维护单独的模块，只是用HCL或YAML替换了API调用，但平台特定的参数和条件逻辑依然存在。
Q3：如何从架构层面解决存储自动化的复杂性问题？
A：可以采用统一基础设施平台，如VergeOS这类将存储、计算和网络集成到单一代码库的平台。这种平台在操作系统级别进行存储抽象，而不是通过针对每个供应商的集成代码。团队编写的自动化代码引用存储服务而非具体存储阵列，硬件变化对自动化层不可见，从而从根本上消除了多平台集成的复杂性。
