存储库和标准化有助于解决网络自动化集成挑战
一体化一直是一个令人厌恶的词，它让那些为实施一体化而苦苦挣扎的人咬牙切齿、哀叹不已。 事实上，59% 的 IT 决策者认为“集成是其组织的‘致命弱点’。”（ 《2018 年互联业务集成报告》）
从表面上看，集成始于一个简单的前提：我们如何跨应用共享数据？ 因为没有任何应用— — 哪怕是一个整体 — — 是一座孤岛。 我还没有遇到过不与其他应用应用共享至少一份数据的应用程序。
我们（以及整个行业）已经经历了几次整合时代。 从轮毂辐射模型到企业（服务）总线再到消息队列，集成始终是企业应用战略的一个组成部分。
我们不再称之为企业应用集成 (EAI) - 主要是因为我认为这会吓到年轻人，并让我们这些老年人抓狂 - 但我们仍然使用“集成”这个词。 我们在应用开发领域之外越来越多地使用它。 毕竟，CI 代表持续集成。 我们认为集成对于世界的部署（生产）方面也具有重要意义。 我们也看到了与我们的应用程序开发人员一样多的挫败感，正如那些在面临网络自动化时因缺乏集成工具而感到沮丧的人所指出的那样。
运营需要整合。 没有它，我们就无法实现流程自动化（这就是编排），因为流程必然跨越多个系统、服务和设备——每个系统、服务和设备可能都有自己的操作域和工具集。 没有集成，就无法构建管道；而没有管道，运营将因日益增长的按需频繁部署需求而难以承受。
这时，基础设施即代码和存储库可以提供帮助。 存储库不仅仅是一个可以存储任何类型的工件（从配置文件到 Python 程序到脚本和模板）的地方。 他们可以成为您的（集成）部署管道的积极参与者。
存储库不仅仅是存储箱
存储库不仅仅是存储工件的地方。 我的意思是，是的，这是它们的主要用途，但它们已经发展成为不仅仅是一个储物柜。 如今，GitLab 和 GitHub 等存储库可以成为自动化管道的关键组件。 使用触发器和事件，存储库不仅可以作为存储工件的地方，还可以作为更大工具链中的工具。 Commit 启动一项作业，完成后，调用 webhook 来触发管道中的下一步。
什么是 Webhook？
Webhook 有时也称为“反向 API”，它允许一个应用（如存储库）通过 URL/API 实时向另一个应用发送数据。例如，在提交负载均衡器的新配置后，存储库会触发 Webhook，然后该 Webhook 会将配置或配置的 URI 发送到应用程序（或直接发送到负载均衡器），然后应用程序会加载新配置。
基本上，我们使用存储库的方式与使用企业服务总线的方式非常相似，以便共享数据并在不同的应用和服务中启动操作以完成“流程”。 在商业世界中，该过程可能是完成客户订单并涉及客户信息系统 (CIS)、订单履行系统、计费和供应链元素。
在运营领域，该过程涵盖完成应用或策略部署所涉及的基础设施、网络和安全服务。
对于那些将“技能”视为最大挑战的人来说，更令人兴奋的是，存储库几乎可以完全通过命令行进行控制。 是的，使用大多数 NetOps 已拥有的相同技能。 一点 bash 和一些 PERL*，一个通过 curl 的 API，瞧！
现在，这并不能解决设备层更深层次的集成需求，这表现为缺乏供应商解决方案的挫败感。 因为最终，存储在存储库中并由 Webhook 触发的配置或配置更改仍然必须转换为设备语言。
这就是标准化和解决方案发挥作用的地方。
标准化减轻运营整合负担
自动化是 F5 许多人目前关注的重点。 我们提出的解决方案之一是F5 自动化工具链。 它包括 F5应用服务 3 扩展 (AS3)、F5 声明式入职 (DO)、F5 遥测流和 F5 API 服务网关。 与存储库一起，它们可以帮助组织构建所需的管道，以部署应用（和业务）所需的应用服务，从而保持应用程序的快速、安全和可用。
但是 Lori，您可能会想，这对我需要自动化和集成的所有其他设备和服务没有帮助。
真的。 这是通用应用服务平台标准化能够提供帮助的方式之一。 由于该平台（BIG-IP）对于广泛的应用服务都是相同的，因此您可以使用自动化工具链来部署 WAF、负载均衡器、访问控制以及 DDoS 保护等。 在尽可能少的平台上进行标准化可以减少所有运营（网络、基础设施和安全）的集成负担，从而增加价值。
在数据中心范围内和多云场景中确实如此。 在应用服务和云环境中使用单一平台进行标准化意味着在任何地方部署应用程序时都可以更快地实现价值。
您可以在多个位置找到（完全免费）F5 自动化工具链：
所以请记住，存储库不仅仅是存储东西的地方。 它们是您的自动化工具箱中的宝贵工具，可以用来帮助实现管道所有不同部分的自动化。 在存储库和应用服务平台上进行标准化可以大大减轻“集成”带来的运营负担。
*将“PERL”解释为Python或某些实际可用的脚本语言。 PERL 是唯一一个与curl押韵的语言，我还没有发现任何与wget押韵的好词。