尽管企业广泛采用多云策略,但仍然缺乏有效的解决方案来解决执行该策略的组织所面临的诸多挑战。 其中一个挑战是跨多个提供商托管的工作负载的安全互连——随着更多云供应商的加入,这个问题的严重性会变得更加严重。
在多云环境中部署应用程序的大多数组织 (75%) 中,63% 的组织根据以下情况使用三个或更多云环境: 参加Propeller Insights 调查。 总体而言,超过一半(56%)的人发现跨不同云提供商管理工作负载十分困难,并指出存在安全性、可靠性以及总体连接性方面的挑战。
这种困难很大程度上可以归因于相互竞争的运营模式。 每个独立的云云提供商都提供其独有的服务和相应的 API,并且通常要求客户遵守不同的技能组合、政策和方法。 每个云都提供“软件定义网络”体验;但没有两个云提供相同的“软件定义网络”体验。 当没有适当考虑这些跨环境差异时,这通常会导致影响安全性和性能的不一致的配置。
云原生(基于微服务)applications的引入加剧了互连的困难,显著增加了必须进行交叉通信的实例数量。 Propeller 发现“超过 70% 的受访者表示,多云环境中的安全问题因提供商之间的安全服务差异(77%)、API 数量的增加(75%)以及基于微服务的应用程序的普及(72%)而加剧。”
这一困难推动了对多云网络新方法的需求。
多云网络统一了两种不同的方法来简化应用交付:
这两个元素的融合已经导致在客户应用架构中创建了两个抽象层——Kubernetes 用于促进网络工作负载管理,SDN 用于简化网络互联。 但目前这两种方法融合的方式仍然给客户带来很大的痛苦。
许多组织都面临着一个挑战:当涉及多个云时,这些技术要求操作采用过于精细的配置来获得标准化的网络互连方法。 一个云提供商所采用的方法 — — 即使对于像 VLAN 管理这样极其简单的网络任务 — — 也与另一个云提供商所采用的方法明显不同……并且两者都可能与企业为其自己的私有云工作所采用的方法完全不同。 跨云属性的网络配置和管理方式通常导致需要维持一批熟悉各自环境差异的专家,以跟上网络标准化的步伐。
管理这两种解决方案的斗争已经够激烈了;再加上多家云提供商,问题的严重性就更加突出了。 显然,有更好的方法来解决这个问题,即让 Kubernetes 和 SDN 更紧密地结合在一起,解决环境差异,并且不需要成为网络专家就可以实现这一切。 在 F5,我们将这种方法称为“分布式云”。
客户通常会遇到这个问题,因为他们在为其服务选择“最佳网络/云”之前会权衡他们的业务决策和应用需求。 这个决定涉及多种因素——成本、启动能力、部署速度或需要进入特定区域……无论客户决定什么因素,对于其应用程序的成功都至关重要。 在最初的业务决策中很少考虑网络端因素或与其他云的互操作性。 不幸的是,随着应用沿着其预期寿命移动并且业务的其他要素对云的使用做出不同的决策,这会带来新的挑战。
在 F5,我们相信,决定使用特别适合业务需求的云技术本身并没有错 — — 即使这会导致使用多个供应商或环境。 我们并不建议客户只追求任何特定云提供商的优势,而是致力于通过合理且在客户网络技能、应用需求和业务愿望范围内的可扩展解决方案,在所有云提供商之间创造共性。 我们将我们的方法称为“分布式云”。
我们的方法基于三个关键信念:
分布式云模型认为,我们客户的applications用户必须以近乎实时的方式获得最高质量、性能和安全性的服务。 我们的目标是提供一个分布式云,它带来跨云弹性的概念,而不会大幅增加成本、减少配置时间或减少环境差异。
F5 已经通过提供一套一致的技术和实践,创建了广泛的解决方案组合来应对这些关键时刻,但我们正在努力将其扩展到客户架构中的每个应用。 作为我们向更多自适应应用s迈进的使命的一部分,我们打算帮助客户完成这些转变,使他们能够轻松地将工作负载转移到最有效的位置、地区或成本模型,而无需为每个环境雇用一批网络向导。
我们的客户能够利用我们的技术通过其内部关键工作负载在云规模上构建多云桥,这正是我们的独特之处。 我们收购Volterra 后,客户能够通过真正的通用控制和管理平面为公共云工作负载和网络带来相同的流畅度和能力,从而简化网络互联挑战:不再需要在每个云上构建许多团队并管理许多特定于环境的 API,只需在它们之间实现连接!
我们将继续把这作为优先事项:为客户提供简单、有效的多云业务解决方案。 我们坚信,借助 F5 技术打造更好、更快、更安全、更分布式的云,企业“我需要立即完成它!”的恳求完全触手可及。