混合云实现： F5、Azure 和 Azure Stack
当今时代，许多 IT 部门受到领导层的压力，要求其从传统内部数据中心的静态特性转向更具动态的以云为中心的架构，以提高敏捷性、灵活性和可扩展性，同时降低运营成本。 由于公有云和私有云各有优缺点，约 71%1企业实施混合模式是为了获得更多的优点，同时消除许多缺点。 然而，几乎所有这些组织都通过采用非同质的云基础设施和应用服务来实现这一目标，这大大增加了负责设计和维护这些部署的跨职能团队的复杂性。
将两个（或更多）不同的云环境链接起来以构建混合云不仅从敏捷性、灵活性和扩展性的角度而言是有益的，而且还支持一系列难以实现或不可能实现的专门用例。 可以说，其中最常见的是：
建立和维护高度可用、地理冗余的私有云备份以防止重要应用停机的成本非常高，并且可能会使运行单个私有云所需的投资增加一倍。 您不仅需要两倍的物理硬件，还需要一个独立的数据中心，该数据中心位于不同的地理位置，拥有自己的电源、冷却系统和人员。
或者，HA 和 DR 环境可以安置在公共云中，且成本仅为其一小部分。 每次从私有云备份应用数据时，都会对其进行存储，而实际的应用和网络资源则处于休眠状态，直到需要时才使用，即在发生灾难或私有云故障的情况下。 如果需要，这些应用和资源将使用存储的数据启动和运行，从而确保应用的可用性和业务连续性。
在私有云中开发新应用的成本可能比在公共云中高得多。 它需要前期资本投资来运行工作负载，而且不能保证它能够在当前市场中发挥作用或被采用。 出于这些原因，公司遵循“快速失败，廉价失败”的原则，利用公共云的按需容量在生产模式下开发、测试和运行新的应用程序。 一旦被认为操作合理或被用户广泛采用，应用程序就可以迁移到私有云，从长远来看，这可能更安全、操作更便宜。 或者，他们可以留在公共云中，部署在更长期、更具成本效益的环境中，使用更便宜的预留实例等。
云爆发通常被认为是最理想的混合云功能，但它实际上可能是最难实现的，经常成为许多混合云策略中的白鲸。 随着云爆发，应用主要在私有云中运行。 当需求超过容量时，额外的请求将被重定向到在租用的基础设施上的公共云中运行的精确副本。 然而，这只是暂时的状态，旨在处理短时间内出现的意外流量高峰。 一旦较高的流量期持续下去，公司就可以扩大其私有云的容量。
为云爆发配置混合云环境本质上是困难且复杂的。 它需要两个环境之间的协同关系以及故障安全编排，以确保重定向自主且无缝地进行，并且对最终用户的体验几乎没有影响。 当用于运行和支持应用的基础设施、服务和工具在每个环境中都不同时，负责配置和管理的团队面临的困难会进一步加大。
并非所有的云都是一样的，这并不奇怪。 每个公司都有自己独特的基础设施、网络和应用服务、开发工具、用户界面以及与其他云竞争对手的差异化。 例如，Sharepoint、Exchange、SQL Server 或其他 Microsoft 技术的用户迁移到 Microsoft Azure 要比迁移到 AWS 或 Google Cloud 要容易得多。 这些平台和服务的差异导致云之间的不兼容，并使开发混合云环境的任务极具挑战性。
然而，微软通过 Azure 和 Azure Stack 分别在公共云和私有云环境中提供同义的资源和服务，在支持混合云创建方面取得了长足的进步。 Azure Stack 刚刚发布，它为用户提供了公共云的许多功能和优势，同时还具有内部数据中心的控制和安全性。
我们将比较三种常见的高级混合云模型，以展示这种新方法与 F5 高级应用服务相结合如何大幅简化混合云的开发和运营。
模型 1 – 非同质云平台和application服务
我们的第一个示例是混合云环境，该环境使用 Azure 和 Azure 原生应用服务作为公有云方面，同时利用 VMware 和 F5应用服务作为私有云组件，如图 1 所示。
不同环境之间明显缺乏一致性，这使其成为最难实现和操作的模型。 对于前面讨论的 HA/DR 用例，应用必须单独配置才能在每个云中相同地运行。 鉴于虚拟机、API 和底层网络资源的差异，这不太可能是一项简单的任务。 由于在每个云中运行应用程序都需要复杂的管道，这些差异降低了应用的整体可移植性 - 这实际上使实现类似结果所需的工作量增加了一倍。 此外，每个平台都有自己独特的门户界面和开发人员/管理员工具，这种模型很快就会变得非常复杂。
这只是考虑平台的差异。 当添加不同应用服务的影响、不同的界面、管理工具和配置要求时，复杂性会呈指数级增长。 而且管理功能障碍并不是唯一的问题；功能不一致会阻止应用在每个云中配置相同的服务，从而使您面临额外的风险。 例如，不同的安全服务会导致不同的防火墙规则集和策略。 这些可能会产生安全漏洞，从而导致应用停机或因任何随后的网络攻击而导致客户数据丢失。
模型 2 – 非同质云平台与同质application服务
此设置与模型 1 中的设置类似，但每个云环境均由 F5应用服务支持，如图 2 所示。
凭借一致的应用服务，所有 F5 服务、配置和策略都可以通过单一窗口管理在各个环境中复制，从而减轻系统管理员的压力。 无需学习和平衡两组独立的功能、界面和术语，只需在混合云环境中部署一套标准化、功能丰富的服务即可。 而且这些服务与云无关（即它们在所有云中以相同的方式运行），消除了使用云原生服务可能产生的供应商锁定的担忧。 然而，该模型并未解决与不同平台基础设施相关的问题，需要将这些问题考虑在内。
模型 3 – 同质云平台和application服务
该最终模型得到了进一步的渐进式改进；采用模型 2 中描述的配置，并用 Microsoft Azure Stack 替换 VMware 私有云，如图 3 所示。
对于不熟悉 Azure Stack 的人来说，这个云平台被设计为私有云中 Azure 的扩展（或只是另一个区域），具有相同的服务、工具和虚拟基础设施。 其价值在于能够轻松地在混合云环境之间传输工作负载，而无需重构应用。 同时，Azure工具和门户界面的一致性降低了管理复杂性。 作为应用程序所有者，您可以在 Azure 中开发和测试应用程序，然后快速无缝地将其转换到 Azure Stack 进行生产部署（反之亦然），同时使用相同的企业级 F5应用服务支持两个实例。
与模型 1 相比，该混合云模型结合了一致的应用服务和云基础设施的优势，同时将系统变量的数量从四个减少到两个，大大增强了应用的可移植性并减轻了 IT 管理压力。 通过统一平台和应用服务，网络运营商和 IT 管理人员可以将其混合云架构视为单一、同质的实体，而不是两个单独的整体。
F5 的 BIG-IP 虚拟版本 (VE) 在两个平台上以相同的方式运行，通过复制支持应用服务来增强 Azure/Azure Stack 架构的奇偶校验。 开发人员不仅可以在一个环境中开发应用程序并将其迁移到另一个环境中，还可以镜像整个生产就绪堆栈，包括所有相同的 BIG-IP 配置、策略和应用服务。 这消除了无数小时的应用重构和测试的需要，并允许开发人员继续做他们最擅长的事情：编写代码。
对于将应用程序迁移到公共云的开发人员来说，保护应用及其数据的安全通常是一个问题——但事实并非如此。 开发人员可以在他们的 Azure Stack 环境中构建应用程序，而安全架构师则在 F5 的 Web应用防火墙 (WAF) 上配置必要的设置。 整个堆栈可以在 Azure 中复制，同时确保应用将受到同一行业领先的 WAF 的保护。 有了相同的策略和规则集，就不会出现因采用不同的 WAF 而产生的任何安全漏洞或弱点。
而且由于 Azure Stack 支持 Azure 资源管理器 (ARM)，F5 的大量 ARM 模板可用于在两种环境中自动部署和配置 BIG-IP VE 实例，从而显著缩短启动时间并提高混合云效率。 最终，F5 为实现与 Azure 的紧密集成所做的所有工作现在都使 Azure和Azure Stack 客户都受益。
企业选择投资混合云战略的原因有很多，实施该战略的方式也有很多。 通过多样化和使用多个不同的云平台和应用服务提供商，公司使实施和运营混合云架构的任务变得更加具有挑战性。
通过在云环境中对 F5 高级应用服务进行标准化，同时利用 Microsoft Azure 和 Azure Stack 云平台的同质性，IT 组织可以创建真正的混合架构，并在生态系统之间实现应用的完全可移植性。 通过支持具有相同 BIG-IP 流量管理和安全服务的应用，网络和安全运营商可以优化最终用户的应用可用性，同时使用一致的安全功能和策略保护应用及其数据。
在云计算发展历程的这个相对较早的篇章中，许多 IT 组织面临着压力，需要对其长期云战略做出艰难的决策——是完全采用公共云，还是完全采用私有云，或者两者兼而有之。 F5 针对 Azure 和 Azure Stack 的应用服务通过创建一个整体解决方案来减轻这一决定的影响，其中整个应用组合可以随时在云环境之间迁移，以适应不断变化的业务需求。
