开源焦点： F5 基础设施即代码和多云可管理性
您可能已经注意到，多云口号下的一个重要鼓点是可管理性。 这是因为扩展、保护和向用户交付应用程序的任务需要一组特定的服务——负载均衡器、计算、存储、应用程序安全。 尽管云可能（确实）使得配置这些服务的过程变得更加容易，但它却损害了运营。 可悲的是，它将复杂性转移到了其他地方。
如果您是提供这些服务的人，那就太好了。 但如果你是负责配置、调整和管理服务的人，那就没那么酷了。
因为复杂性使得管理更加困难。 没有两朵云是相同的（就 API 和服务而言），这通常意味着人们现在必须处理两个完全独立的操作模型。
因此，可管理性是多云成功的关键因素。
组织可以实现这一目标的方法之一是采用那些简化部署的构造。 这些越来越多地以某种模板的形式出现： OpenStack 我想到的是 HEAT、AWS Cloud Formation 和 Azure ARM。 这些模板根据需要实施的特定配置对 BIG-IP 部署的大部分内容进行编纂，以便提升 BIG-IP 的真正价值（即其服务）。
模板是基础设施即代码 (IAC) 的最佳示例之一。 这是因为它们可以被完全当做代码工件来对待。 它们可以被版本化、分支、合并、检索、克隆并最终部署。
该模型与通过 API 和脚本语言进行云和管理的 DevOps 导向视图非常匹配。 毕竟，如果 DevOps 可以将其影响力扩展到 NetOps，并且反过来他们可以使用 IAC 方法快速部署服务，那么每个人都会很高兴。 这正是医生所要求的，因为 NetOps 缺乏此类服务，严重影响了 DevOps 在云计算方面绕过 IT 的决策。
支持多云可管理性正是我们（现在的公司）在开始为 OpenStack、AWS 和 Azure 开发模板时所设想的。 启用 IAC 方法以提供更高的灵活性和速度是这些模板可通过 github 免费获取的原因。
因为我们的实验室部署不是您的部署，也不是其他人（在您后排，从您肩膀上读出）的部署。 部署具有一组共同的特征，但是所有应用程序都有特定需求，而这些需求无法通过相同的商品化服务配置来满足。 循环负载平衡对于无状态、基于微服务的应用程序来说可能足够好，但对于其他application架构来说，它可能非常低效（更不用说昂贵） - 特别是在云环境中。 您需要自由地调整和优化应用程序性能并确保数据安全和用户交互的安全。
您需要能够提取、克隆并将这些工件提交到您自己的存储库，这样您就可以获得包括 IAC 在内的 NetOps 方法的好处，以便在尽可能多的云环境中部署尽可能多的服务基础。
因此，请按照您的计划提取、克隆、提交和部署 - 无论是每天三次还是每季度三次。 它是开源的，并且始终开放供访问。