回到链条： 聆听与可用性之间的联系

随着 F5 在我们的平台上转向 DevOps 和 Agile 开发风格，我们已经形成了这样的原则：发布产品并不是成功的标准。

今天，我们摆脱了门槛，开始审视整个生命周期—— 发布创作、倾听意见（F5 内部和外部的意见），然后将这些经验反馈到开发中。 我们优先考虑客户反馈，尤其是来自在生产环境中运行 F5 的客户的反馈。

我们的目标始终是打造更好的产品并填补我们的空白。 但这也是为了在高级功能和易用性之间找到平衡。 我们希望为客户提供先进的功能，但我们也明白最终用户不一定是我们之前合作的系统架构师。

为了让更广泛的受众能够使用复杂的功能，我们将追溯链条，并通过新的、更丰富的 API 实现配置自动化。 这就是我们今天所拥有的 F5 自动化工具链。

利用自动化工具链，我们正在突破我们认为可以做的事情和可以实现的功能的界限。 我们发现这在很大程度上与 API 的体验有关，这促使我们推行声明式模型。

为什么 API 的用户体验很重要？ 这很重要，因为今天使用它的人不是那些系统架构师。 他们是链条中处于第二或第三级的开发人员和工程师。

我们的客户希望获得易于集成的服务，并且即使不是专家也可以使用。 这意味着 API 不再是事后才由专家设计的。 我们设计的 API 非常清晰简洁，因此只需查看一下界面就能轻松推断出应该如何使用。

通过使 API 具有声明性或基于意图，我们正在改变整个方法。 我们不会向用户提供两页的配置简介，而是简单地要求他们： 告诉我们您想要什么结果。

我们正在实现这种自动化来使用复杂的服务，而不仅仅是简单的服务。 您仍然拥有 F5 平台的所有功能，但现在可以轻松地将这些复杂的功能提供给需要它的人们。

事实是，并非每个客户在自动化道路上都处于同一阶段。 我们的客户遍布各个领域，因此我们还构建了自动化工具链，将其作为一组组件，可以将其分解并独立使用，然后在适当的时候组合成一个单元。

在该生命周期中，存在一些离散步骤，每个步骤均由自动化工具链的一个组件处理：

• 引导。 当您只想在某处运行 F5 实例时，这是初始步骤。 如果您是客户，并且想要在公共或私有云中引导BIG-IP实例，我们可以提供 F5 云模板来帮助您实现这一点。
• 入职。 在这里，您将该实例带到可以部署服务的地步。 您不希望开发人员必须设置所有 IP、配置用户、日志记录等等。 他们也不想这么做。 这就是 F5 声明式入职扩展的作用所在。 它允许我们提供一个非常简单的声明式接口来处理初始配置。
• 部署application服务。 这是在每个环境中每天都会发生的事。 部署新服务。 更改或删除该服务。 修改它或者添加新的功能。 为此，我们有 F5 App Services 3 (AS3) 扩展，它提供了一个基于结果的声明式 API 接口，并具有模板化配置的能力。 我们的大多数客户都从 AS3 开始，因为它往往能立即提供最大的价值。
• 监控和遥测。 当您使用自动化工具链时，数据现在默认可用，因此使用 F5 遥测流扩展并尽快将该数据从设备上传输到其他系统是有意义的。 这可能是像我们的BIG-IQ管理平台这样的产品，基于云的分析解决方案或其他工具，允许您将大数据原则应用到您从设备获得的信息中。
• 变更管理。 变化会发生，并且将一直发生。 回顾 DevOps，我们也正在远离大规模的改变和重大的发布。 如今，它的变化单位已随时间而变化。 您可以逐渐向客户提供新功能，他们可以根据需要采用这些功能。 这些改变都不会破坏之前的内容或要求进行大量修改。

所有这些都基于对描述您期望结果的平台的单个 API 调用。 F5 将呼叫处理为在 BIG-IP 设备上需要执行的所有操作以达到该状态，并响应说“是”（已完成）或“否”（存在问题）。 这一切都是基于自动化系统既定的模式和方法，以非常稳定的方式完成的。

结果是，自动化工具链减少了与我们的平台集成所需的工作量，几乎是毫不费力的。

我们对 F5 平台未来如何集成的看法是，我们希望成为生态系统最容易集成的平台。 就客户或合作伙伴为我们的平台编写的每一行代码而言，我们都希望以该行代码成本 100 倍的价格提供其功能和可用性。

归根结底，这并不是做一些简单的事情。 这是用非常简单的方式做非常复杂的事情。 这就是 F5 自动化工具链所提供的。