为什么复杂性破坏了人工智能野心

混合云蔓延和供应商疲劳正在产生最终的讽刺：组织无法使用AI解决其IT问题，因为他们的IT问题阻止了他们使用AI。

在我建立企业系统的11年中，从实践的医疗保健云基础架构到VMware的混合云解决方案，到现在建筑F5的大型IP管理平面 - 我见证了许多有望转型的技术周期。大多数交付的复杂性。但是，我在2025年观察到的是不同的，坦率地说，更令人不安。

企业技术景观提出了一个引人入胜的悖论：在人工智能有望解决我们最复杂的运营挑战的那一刻，那些相同的复杂性正在阻止组织有效地部署AI解决方案。当我分析时F5的最新申请策略报告旁边A10网络的应用负载平衡研究，数据揭示了我从自己构建这些系统的工作中认识到的AI愿望和基础架构现实之间的令人不安的脱节。

我们面临最终的讽刺：组织可以使用AI来解决他们的IT问题，因为他们的IT问题阻止了他们使用AI。

数据中的唤醒电话

这些报告中的统计数据立即引起了我的注意，因为它们反映了我与企业客户的工作中所看到的。F5的研究表明，96％的组织正在部署AI模型，而73％的组织希望AI优化其应用程序性能。从表面上看，这看起来像是AI的巨大采用成功。

但是后来我看到了另一个数字：60％的IT专业人员陷入了手动操作任务中。在我目前为大型企业管理Big-IP的管理平面的角色中，我经常看到想要AI驱动的自动化的团队，但可以找到带宽可以实施的团队，因为他们不断进行消防。

AI采用障碍的转变讲述了一个更具启发性的故事。在2024年，数据质量是主要障碍。到2025年，它转移到了人类技能群体上 - 54％的组织缺乏足够的AI专业知识。但是在这个方程式的两边都工作过，我怀疑真正的问题不是缺乏技能，因此缺乏发展和运用这些技能的时间。

当A10的研究表明，有58％的组织认为API蔓延为重要的疼痛点时，我知道我们不仅仅在研究效率低下。我们研究了防止AI实施的根本原因：团队不知所措，因为他们可以管理复杂性，以至于他们可以退后一步，以实施可以为他们管理这种复杂性的解决方案。

我在复杂性方程式的两边都学到了什么

我从VMware到F5的旅程使我在这场复杂性危机上有一个独特的有利位置。在VMware，我是团队的一员，有望简化混合云。在F5，我现在帮助企业管理这些承诺创造的复杂性。

在VMware的四年中，我致力于开发其混合云解决方案，该解决方案启用了跨本地和云环境的无缝工作负载管理。我们将核心VMware技术（如VSphere和NSX）集成了公共云平台。从表面上看，它是优雅的：一个管理界面，一致的政策，环境之间的工作负载移动性。该解决方案足够成功，Forrester将VMware命名为Hybrid Cloud Management的领导者。

但是，实施告诉我，“无缝和简单”是同样的事情。每个云提供商都有不同的API，安全模型和操作过程。我们所谓的统一管理仍然要求团队了解多个平台的细微差别。我们解决了技术整合挑战，但是我们没有消除运营复杂性 - 我们只是集中了它。

现在，在我担任F5的大型IP管理平面技术领导者的角色中，我看到了该方程的另一面。我与已经实施了这些混合解决方案的企业合作，并正与我们认为我们已经解决的运营负担努力。他们重新管理跨多个云的应用程序，处理每个环境的不同负载平衡要求，并试图在从未以相同方式工作的平台上保持一致的安全策略。

F5报告发现，有94％的组织在多个环境中部署应用程序，中位数是四个不同的公共云供应商，这只是我所支持的企业的日常现实。当我看到79％的人将应用程序从公共云转移到本地时，我就会意识到这种幻灭。我们承诺的混合云灵活性成为他们无法理解的混合云复杂性。

最让我着迷的是这种复杂性如何复合。每个其他云提供商都不只是添加一个平台来管理 - 它添加了指数集成点，API关系和潜在的故障模式。旨在提供运营灵活性的解决方案正在消耗运营能力。

AI实施讽刺

这种复杂性最令人沮丧的部分不仅仅是运作。这是错过的机会。我经常看到可以从AI驱动的基础架构自动化中受益匪浅的企业团队，但他们陷入了供应商API管理的循环中，该供应商API管理会消耗其带宽。

我反复观察到的是：一个组织将实施自动化，该自动化在其基础架构堆栈堆肥，云平台，监视工具上都可以通过API互相交谈。然后，供应商推动了与现有集成兼容的API升级。突然，随着团队争先恐后地更新集成，应减少手动工作的自动化成为紧急手动工作的来源。

使情况变得更糟的是，每个供应商都接近相同的功能。与Azure S相比，AWS的负载平衡器API使用完全不同的身份验证，数据结构和错误处理，这与本地解决方案完全不同。一个团队可能会花几个月的时间建立AI驱动的流量优化，以与一个供应商的API完美配合，却发现他们在扩展到另一个平台时需要重建所有内容。

这是AI的最纯粹形式的AI实现：我们希望AI管理基础架构的复杂性，但是我们可以实施AI，因为我们忙于管理基础架构的复杂性。F5数据显示，与供应商API一起工作是最耗时的自动化相关任务，这不是一个统计数据，这是防止AI采用的日常现实。

供应商关系危机

在分析我们自己的研究和A10的发现的同时，在F5内部工作，这使我对供应商关系有一个不舒服但必要的观点。A10研究的数据特别令人醒目：47％的EMEA IT专业人员和55％的美国高管将由于有限或不良的供应商支持而更改其ADC提供商。

作为为这个领域的主要参与者之一工作的人，我必须承认这反映了一个真正的问题。研究表明，有44％的组织在最近的供应商许可变更方面面临问题，而29％的高管将许可费用作为他们的最高投诉，即使是安全问题。

最困扰我的是时机。当企业需要最大支持的混合云复杂性时，这些供应商关系问题正精确地浮出水面。当组织努力在四个不同的云平台上管理应用程序时，他们需要的最后一件事是对基础架构供应商关系的不确定性。

从我在F5的位置，我看到了这种动态的两面。供应商承受着在竞争日益激烈的市场中证明价值和增长的压力。但是企业也处于压力下 - 他们淹没了运营复杂性，需要减轻而不是增加负担的合作伙伴。

A10数据表明，当组织确实考虑更改供应商时，他们优先考虑集成安全功能（52％），较低的基础设施成本（45％）和优越的供应商支持（EMEA为33％）。说的是，高级供应商支持的排名很高。它表明，当前的供应商生态系统在关键转型期内不满足基本的支持期望。

企业应该做什么不同

经过十多年的建设和管理这些系统后，我了解到，这种复杂性陷阱的路径并不是更多的技术。成功实施AI的企业必然是预算最大或最先进的基础架构的企业。他们首先简化了他们的运营基础。

F5研究表明，93％的组织现在通过数字应用程序产生收入，高于两年前的79％。这不是一个统计数据，这是业务的必要性。当您的收入取决于数字基础架构时，复杂性成为对业务连续性的直接威胁。

根据我在VMware建立混合解决方案的经验，现在支持F5的Enterprise ADC部署，我认为组织需要做不同的事情：

首先，抵制在满足您需求的现有供应商时添加更多供应商的冲动。A10数据显示了管理与多个ADC提供商关系的组织，通常是出于对主要供应商的沮丧而出于挫败感。但是供应商的增殖是复杂性增殖。与其将另一个供应商添加到您的堆栈中，不如花时间解决您的关系或做出故意的供应商整合决策。

其次，无情地审核您的API景观。当58％的组织与API蔓延斗争，并且与供应商API合作是最耗时的自动化任务时，您知道系统中存在浪费。在与企业的合作中，我看到团队管理数十个不同的API，只是用于申请和安全性。每个API都代表开销。质疑每个人是否真正必要。

第三，在自动化之前进行标准化。F5报告显示，有95％的组织正在使用OpenTelemetry等可观察性工具进行标准化。这种标准化为自动化创造了基础。您可以有效地自动化混乱 - 您必须先组织起来。

最后，将供应商选择视为基础架构架构。在评估新工具或供应商时，请提出一个问题：这会降低或增加我们的操作复杂性吗？短期收益值得长期运营债务。

我走的前进道路

在我目前领导F5的大型IP管理平面体系结构的工作中，我试图应用这些教训。挑战是重大的：Big-IP是全球企业的关键基础架构，我们所做的任何更改都必须考虑客户已经管理的运营复杂性。

我关注的一件事是减轻在混合环境中管理我们平台的团队的运营负担。我们没有添加更多需要更多配置的功能，而是研究智能默认和自动化策略管理，以减少操作员需要手动制作的决策数量。

F5研究表明，自动化已成为运营遥测的最佳用例，这给了我希望。组织超越了仅使用数据来提醒的 - 他们希望它能驱动自动响应。从反应性运作到主动操作的这种转变正是打破复杂性周期所需的转变。我还密切关注API蔓延问题。在我的架构工作中，我不断地问：我们正在添加另一个团队必须学习和维护的API，还是简化了现有的API？

展望未来，我相信AI实施成功的企业将是首先解决其运营复杂性的企业。数据显示组织希望AI优化应用程序性能，甚至可以自动处理安全响应。但是，您可以有效地自动化系统，您无法完全控制或理解。

从我在支持AI工作负载的基础架构上工作的有利位置，我看到未来分为两个营地：简化其基础架构以实现AI功能的组织，以及那些仍然被困在复杂性周期的组织。随着AI对业务运营的核心，这两个组之间的差距只会扩大。

当前时刻的具有讽刺意味的是，我们有解决运营问题的工具，但是我们的操作问题阻止了我们使用这些工具。打破这个周期需要纪律，而不仅仅是技术。认识到这一点的企业将是成功发挥潜力的企业。

本文作为Foundry专家贡献者网络的一部分发表。
想加入吗？