回溯链路：监听与可用性之间的关联

Hitesh Patel

随着F5在平台开发中逐步采用DevOps和敏捷开发模式，我们形成了一项共识：产品发布并非衡量成功的标准。

如今，我们正在摒弃单一的成功标准，着眼于整个生命周期，即发布成果、听取相关方（包括F5内部和外部）的意见，再将这些经验反馈到开发中。我们几乎将客户反馈置于其他一切事项之上，尤其重视在生产环境中运行F5的客户所提供的反馈。

我们的目标始终是打造更好的产品并弥补不足，同时在高级功能与易用性之间取得平衡。我们希望为客户提供高级功能，但也明白，最终用户未必是前期与我们合作的系统架构师。

为了让更多用户能够使用复杂功能，我们将工作向下游延伸，通过功能更丰富的新API实现配置自动化。这促成了如今的F5 Automation Toolchain。

借助Automation Toolchain，我们正在突破以往对自身能力和可实现功能的认知边界。我们发现，这在很大程度上与API的使用体验有关，因此开始推动采用声明式模型。

为什么API的用户体验很重要？因为如今使用API的并非系统架构师，而是处于后续两三个环节的开发人员和工程师。

我们的客户希望服务易于集成，即使其客户并非专家，也能轻松使用。因此，API不能再是仅面向专家设计、事后才考虑的部分。我们在设计API时力求清晰简洁，让人只需查看接口，就能轻松判断其使用方式。

通过将API设计为声明式或基于意图的模式，我们正在改变整个实现方式。我们不再让用户按照长达两页的配置说明操作，而是直接询问：告诉我们您希望实现什么结果。

我们还让这种自动化能够使用复杂服务，而不只是处理简单任务。F5平台的全部强大功能依然可用，而现在，需要这些复杂功能的人员可以轻松使用它们。

此外，并非每位客户都处于自动化进程的同一阶段。我们的客户遍布这一进程的各个阶段，因此，我们还将Automation Toolchain构建为一组可拆分并独立使用的组件，并可在时机成熟时整合为一个整体。

在整个生命周期中，各个独立步骤分别由Automation Toolchain的相应组件处理：

• 引导部署。 这是让F5实例在某处运行起来的初始步骤。如果您希望在公有云或私有云中引导部署BIG-IP实例，可以借助F5 Cloud Templates完成此操作。
• 接入配置。 在此阶段，需要将该实例配置到可以部署服务的状态。您不希望开发人员必须设置所有IP地址、配置用户和日志等内容，开发人员也不愿处理这些工作。这正是F5 Declarative Onboarding Extension的用武之地。它提供了一个非常简单的声明式接口，用于完成初始配置。
• 部署应用服务。这是每个环境中的日常工作，包括部署新服务，更改或删除该服务，以及修改服务或添加新功能。为此，我们提供了F5 App Services 3 (AS3) Extension。它提供声明式、基于结果的API接口，并支持将配置模板化。大多数客户会从AS3入手，因为它通常能快速带来显著价值。
• 监控和遥测。使用Automation Toolchain时，默认情况下数据已可用，因此适合使用F5 Telemetry Streaming Extension，尽快将数据从设备传输到其他系统。这些系统可以是F5的BIG-IQ管理平台、基于云的分析解决方案，或其他可对设备数据应用大数据方法的工具。
• 变更管理。变更不可避免，也会持续发生。回到DevOps，我们也在逐步摒弃大规模变更和重量级发布。如今，变更以小单元的形式逐步实施。可以逐步向客户提供新功能，供客户按需采用。这些变更不会破坏现有功能，也不需要进行大量修改。

所有这些操作都以对平台的一次API调用为基础，该调用用于描述期望的结果。F5会将此调用转换为BIG-IP设备达到该状态所需执行的全部操作，并返回响应，说明操作已完成或存在问题。整个过程遵循成熟的自动化系统模式和方法，以非常稳定的方式完成。

因此，Automation Toolchain大幅减少了与F5平台集成所需的工作量，让集成变得轻松易行。

对于F5平台未来的集成方式，我们希望让生态系统能够更轻松地与平台集成。我们希望客户或合作伙伴为平台编写的每一行代码，都能在功能和易用性方面带来相当于该行代码成本100倍的价值。

归根结底，关键不在于完成简单的任务，而在于以非常简单的方式完成极其复杂的任务。这正是F5 Automation Toolchain所能实现的。

关于作者

Hitesh Patel

Hitesh Patel 的更多博客文章