混合云落地：F5、Azure与Azure Stack
简介
如今，许多IT部门迫于管理层的要求，正从传统内部数据中心的静态模式转向更具动态性、以云为中心的架构，以提高敏捷性、灵活性和可扩展性，同时降低运营成本。由于公有云和私有云各有利弊，约71%1 (https://www.f5.com/resources/white-papers/hybrid-cloud-realized-f5-azure-and-azure-stack#footnote01)的企业采用混合模式，以发挥更多优势，同时规避诸多弊端。然而，几乎所有这些组织都采用异构云基础设施和应用服务，这大幅增加了负责设计和维护这些部署的跨职能团队所面临的复杂性。
典型的混合云用例
将两个（或更多）不同的云环境连接起来构建混合云，不仅有助于提升敏捷性、灵活性和扩展能力，还能支持许多特殊用例，而这些用例在其他环境中实施起来会困难得多，甚至无法实现。其中较为常见的用例包括：
高可用性（HA）和灾难恢复（DR）
为私有云建立并维护高可用的异地冗余备份，以防止关键应用停机，成本非常高，所需投入可能是运行单个私有云的两倍。除了需要两倍的物理硬件外，还需要在其他地理位置建立独立的数据中心，并为其配备专用的供电、冷却系统和人员。
另一种方案是将高可用性（HA）和灾难恢复（DR）环境部署在公有云中，成本仅为前述方案的一小部分。每次从私有云备份时，应用数据都会被存储，而实际的应用和网络资源则保持休眠状态，直到发生灾难或私有云故障等情况时才会启用。如有需要，可启动这些应用和资源，并利用存储的数据投入运行，从而确保应用可用性和业务连续性。
应用开发和测试
在私有云中开发新应用的成本可能远高于在公有云中开发。企业需要预先投入资金来运行工作负载，但无法保证应用能够正常运行或被当前市场接受。因此，企业遵循“快速试错、降低成本”的理念，利用公有云的按需容量开发和测试新应用，并以生产模式运行。应用经确认运行稳定或被用户广泛采用后，可以迁移到私有云；从长远来看，私有云可能更安全，运营成本也可能更低。或者，应用也可以继续留在公有云中，部署到更适合长期使用且更具成本效益的环境中，并采用价格更低的预留实例等资源。
云突发
云突发通常被视为备受青睐的混合云能力，但实际实施起来可能最为困难，往往成为许多混合云战略中难以实现的目标。采用云突发时，应用主要在私有云中运行。当需求超出容量时，额外请求会被重定向到部署在公有云租用基础设施上的完全相同副本。不过，这只是一种临时状态，旨在应对持续时间较短的突发流量。如果高流量持续存在，企业可以扩展其私有云容量。
为云突发配置混合云环境本身就十分困难且复杂。这不仅要求两个环境协同配合，还需要具备故障保护机制的编排，以确保请求能够自动、无缝地重定向，尽量减少或避免对最终用户体验的影响。如果两个环境使用不同的基础设施、服务和工具来运行及支持应用，负责配置和管理的团队将面临更大挑战。
同质化：混合云成功的关键
不同的云并不完全相同，这一点并不令人意外。每种云都有独特的基础设施、网络和应用服务、开发者工具及用户界面，并具备区别于其他云竞争对手的特性。例如，与迁移到AWS或Google Cloud相比，Sharepoint、Exchange、SQL Server或其他Microsoft技术的用户迁移到Microsoft Azure要容易得多。这些平台和服务之间的差异会导致云之间不兼容，使混合云环境的构建极具挑战性。
不过，Microsoft在支持构建混合云方面已取得显著进展，分别通过Azure和Azure Stack在公有云和私有云环境中提供相对应的资源与服务。刚刚发布不久的Azure Stack既能为用户提供公有云的诸多功能和优势，又兼具内部数据中心的控制能力与安全性。
我们将比较三种常见的高级混合云模型，说明这种新方法与F5高级应用服务相结合后，如何大幅简化混合云的开发和运维。
模型1：异构云平台和应用服务
第一个示例是一个混合云环境，其中公有云部分使用Azure及Azure原生应用服务，私有云部分则采用VMware及F5应用服务，如图1所示。
不同环境之间明显缺乏一致性，因此该模型的实施和运维难度很大。对于前文讨论的高可用性和灾难恢复（HA/DR）用例，必须分别配置应用，使其在每个云中以相同方式运行。由于虚拟机、API和底层网络资源存在差异，这项任务不太可能简单完成。要让应用在每个云中投入运行，需要进行复杂的衔接工作。这些差异会降低应用的整体可移植性，实际上，要取得类似结果，工作量会增加一倍。此外，每个平台都有独特的门户界面以及开发人员和管理员工具，因此该模型很快就会变得过于复杂，难以实施。
这还只是考虑了平台之间的差异。如果再加上应用服务各不相同，接口、管理工具和配置要求也存在差异，复杂性将呈指数级增长。管理失调并非唯一的问题；功能不一致会导致应用无法在每个云中配置相同的服务，从而带来额外风险。例如，不同的安全服务需要使用各自独立的防火墙规则集和策略。这可能造成安全漏洞，一旦遭受网络攻击，可能导致应用停机或客户数据丢失。
模型2：异构云平台与同构应用服务
此设置与模型1类似，但每个云环境均由F5应用服务提供支持，如图2所示。
借助一致的应用服务，可以通过单一管理界面在不同环境之间复制所有F5服务、配置和策略，从而减轻系统管理员的负担。无需学习和权衡两套不同的功能、界面和术语，只需在混合云环境中部署一套标准化且功能丰富的服务。这些服务不受云平台限制（即在所有云中以相同方式运行），可消除使用云原生服务时可能产生的供应商锁定顾虑。不过，此模型无法解决平台基础设施各不相同所带来的问题，因此仍需将这些问题纳入考量。
模型3：同构云平台和应用服务
最后一种模型在此基础上进一步改进：采用模型2中所述的配置，并将VMware私有云替换为Microsoft Azure Stack，如图3所示。
对于不熟悉 Azure Stack 的用户，这一云平台旨在将 Azure 扩展到私有云中（也可视为 Azure 的另一个区域），提供相同的服务、工具和虚拟基础设施。其价值在于，无需重构应用，即可轻松地在混合云环境之间迁移工作负载。同时，Azure 工具和门户界面的一致性有助于降低管理复杂性。作为应用所有者，您可以在 Azure 中开发和测试应用，然后快速、顺畅地将其迁移到 Azure Stack 进行生产部署（反之亦然），并使用相同的企业级 F5 应用服务为这两个实例提供支持。
与模型1相比，这种混合云模式兼具一致的应用服务和云基础设施优势，同时将系统变量数量从4个减至2个，从而显著提升应用可移植性，并减轻IT管理负担。统一平台和应用服务后，网络运营人员和IT管理人员可将混合云架构视为一个统一的整体，而非两个彼此独立的单体。
真正的混合云：适用于Azure和Azure Stack的F5
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组织面临压力，需要就长期云战略做出艰难决策：是完全采用公有云、完全采用私有云，还是将两者结合使用。适用于Azure和Azure Stack的F5应用服务提供整体解决方案，使整个应用组合可随时在不同云环境之间迁移，以适应不断变化的业务需求，从而减轻这一决策带来的影响。
脚注：
1 RightScale《2018 年云计算现状报告》
发布于2018年5月9日