选择正确的云采用模式

模式包含从重复的客户和合作伙伴参与中提炼出来的复杂任务的最佳实践和专业知识。 模式有助于以清晰的格式定义好的解决方案，以解决重复出现的问题； 然后可以将其应用于具体的用例中，而与所使用的技术无关，包括软件，中间件或编程语言。

随着越来越多的解决方案部署到云中以及云计算成为商务的新兴发展领域，云用户可以使用新产品和技术。 了解云模式，尤其是采用模式，并将最合适的模式与业务的实施方案，动机和缓解措施进行协调，可以帮助您构建合理的云解决方案。

例如，如果解决方案需要与驻留在本地或其他云环境中的IT组件集成，则其中所有IT资源都驻留在云中的完整云解决方案可能不是满足某些要求的最佳解决方案。 具有与特定需求匹配的拓扑和模式可帮助架构师缩小解决方案元素的范围，以支持功能和非功能需求。

模式还有助于确定选择一种模式而不是另一种模式的含义，这有助于架构师向业务部门突出所做选择的后果。

本文的目的是帮助云架构师选择合适的云采用模式，以帮助扩展业务能力并将现有的本地系统与云提供商提供的新服务集成在一起。 重点主要集中在集成方面，该方面使用采用模式来支持两种云服务模型（基础架构即服务[IaaS]，平台即服务[PaaS]，软件即服务[SaaS]和业务流程即服务）和云类型（公共，私有，混合和社区）以抽象的形式对云解决方案产品进行分类。 这些摘要应帮助您根据自己的业务模型，所需的云成熟度级别和技术选择（例如软件，平台和工具）选择适当的采用模型-主要目标是为您提供第一个关键步骤之一通向云实施或扩展的整体路径。

在以下各节中，我们将回顾关键的云采用模式，并描述它们的属性，特征，拓扑，动机和其他决策因素。 我们提供用户方案和案例研究作为示例来帮助提供上下文。

满足云采用模式

一般而言，根据应用程序，数据和基础架构共享特性，可以区分四种类型的云模式：

• 应用程序托管在本地云（私有云）中； 数据和基础架构不共享。
• 应用程序托管在公共云中； 数据和基础架构可以共享。
• 私有和公共（混合云）应用程序的组合； 数据和基础架构被有选择地共享。
• 专为特定社区功能设计的社区云，以允许社区用户相互协作。

这些云模式与云服务模型相关但与之不同。 云服务模型（就本文而言）也可以分为四个不同的组：

• 基础架构即服务
• 平台即服务
• 软件作为服务
• 业务流程即服务以支持不同类型的服务

所描述的采用模式模型基于第一组特征，并包含所有云服务模型中的一些。 云采用模式称为：

• 主混合云（PHC）
• 扩展混合云（EHC）
• 全云（FC）
• 扩展全云（EFC）

以下各节概述了每个模式的属性，特征和拓扑。 每个部分还提供了动机，说明了为什么您可能会使用它们，选择一种模式而不是另一种模式的利弊，以及采用特定模式可能带来的影响。

主混合云（PHC）

主要的混合模式是一种用于将内部部署或托管部署扩展到云环境中的方法。 处理实例是按需部署或预先分配的，通​​常不会集成到运行时服务提要中。

此模式具有用于服务交付的单向方案，该方案仅依赖于一次可操作的一个源。 数据中心功能可以提供以下服务，例如数据服务，业务支持服务（用于计费，客户管理等），运营支持服务（例如服务自动化，计量等）以及支持，监视，安全性和网络服务。

特点

使用这种模式，与本地组件的集成受到限制。 组件松散耦合，没有双向同步。 没有与其他云解决方案的集成。

拓扑结构

从概念上讲，主要的混合模式可以表示为图1：

图1.主混合云拓扑

左侧的本地组件和右侧的云组件之间的集成有限。 逻辑上看起来像图2：

图2.主混合云逻辑结构

动机

您可能会采用这种模式的动机包括：

• 您需要额外的处理能力，这些处理能力在内部无法满足，并且可以在没有来自本地系统的有限输入的情况下运行。
• 您需要预处理大量原始数据，但是您不想将所有原始数据存储在内部。 您只想存储结果。
• 您需要不能在内部运行的软件组件。
• 您没有设置内部环境或在本地运行软件的现有内部技能。
• 您的上市时间很短，云提供商可以满足您的业务需求，而本地技术则无法满足您的业务需求。
• 您认为您可能需要扩展的混合云，但是您还没有准备好这样做。

关键用户方案

使用主要混合模式的企业通常具有以下业务需求：

• 您想运行其他批处理，但本地系统上当前没有可用的处理窗口。
• 您有一个大数据项目，该项目从Internet收集数据，并且您要基于本地系统的输入进行数据挖掘（例如，商业智能[BI]报告）。
• 您想在内部托管一个内容管理系统，其中包含您的内容管理系统的一部分。
• 您需要测试一个新应用程序，该应用程序必须在可在云中运行但不能在内部运行的操作系统上运行。
• 您希望通过复制为本地用户共享本地数据。
• 您想在基于本地系统的核心服务之外提供其他服务（例如数据分析），但对于核心业务不是必需的。
• 您想将特定于外包的电子商务功能（例如付款服务或计费）外包给SaaS提供商。

决定因素

决定是否采用此模式的因素有：

• 您想将您的承诺限制为完整的云部署。
• 风险隔离：例如，批处理过程可能会失败，但可能不会在日常情况下对服务产生影响，并且对您的核心业务的影响将降至最低，并且不需要内部部署设施的大量支持。
• 最小化投资：您希望在启动整个云之前快速获得初步的云经验。
• 灵活性：这种模式允许您以最少的承诺扩展现有业务。
• 最小化集成和流程依赖性。
• 您无需对数据进行分区。
• 无需实时交易。

含义

如果您采用这种主要的云模式，则需要考虑的关键含义是：

• 需要为云维护一种支持结构，为可能包含冗余或冲突的内部部署系统维护一种支持结构。
• 对于云环境的本地监控可能很少，甚至可能需要您提供自己的监控。
• 从本地系统到主要混合云服​​务的有限集成所需的工作。
• 与云提供商建立治理模型（例如，变更控制，QoS）和标准。
• 合同管理需要按条款和条件进行设置。
• 云解决方案的安全性可能与本地解决方案不同。
• 现有的运营支持功能可能不会扩展到云解决方案，这可能需要查看并完善当前的支持结构。
• 建立度量标准以验证和审核云提供商提供的服务。
• 可能需要对用户进行培训，以涵盖扩展的功能。
• 应用程序迁移和补丁管理支持。
• 需要包括云扩展在内的灾难恢复计划。
• 您与主要混合云服​​务进行实时集成的能力可能会受到限制。

扩展混合云（EHC）

扩展的混合云涉及将一个或多个本地或托管环境附加到云环境。 它由混合资源环境组成，混合了本地资源和云资源以提供云服务； 它依靠两种环境来提供真正的端到端功能。 扩展的混合云具有双向的服务交付依赖性，因为它们依靠两个独立的源来活动和运行以便交付服务。

特点

通过这种模式，与本地组件进行了显着集成，并且组件与双向同步更加紧密地耦合在一起。 这与主要的混合模式不同。 数据和功能在现有IT和云环境之间紧密耦合，以提供预期的服务； 但是，这是一个独立的云解决方案，并且没有与其他云解决方案集成。 所有集成都与本地系统一起进行。

拓扑结构

从概念上讲，扩展的混合模式可以表示为如图3所示：

图3.扩展的混合云拓扑

与主要混合模式相比，左侧的本地组件和右侧的云组件之间的集成度更高。

从逻辑上看，它类似于图4：

图4.扩展的混合云逻辑结构

动机

您采用此模式的原因是：

• 云组件取决于本地数据存储，反之亦然。
• 内部部署操作设施对于云组件的操作是必需的，反之亦然。
• 云处理需要本地处理，反之亦然。
• 需要实时或接近实时的处理以及与云组件和数据存储的通信。

关键用户方案

使用扩展混合模式的企业通常具有以下业务需求：

• 事务处理，以同步方式在云中和内部都可以创建，更新或存储您的数据。
• 业务流程交易需要同时完成云处理和本地处理。
• 某些关键组件必须驻留在内部而其他组件驻留在云中的事务。
• 本地事务，其中某些报告功能（例如专家数据分析等）需要来自云的其他数据和流程来生成报告。

决定因素

帮助确定是否应采用此模式的因素有：

• 可以重用现有的本地IT投资。
• 允许基于隐私考虑因素对数据进行分区。
• 提供实时或接近实时的BI或流程集成。
• 通过云组件扩展现有业务能力。

含义

如果您采用这种云模式，则要考虑的关键含义是：

• 本地操作人员必须了解云组件，反之亦然（例如，停机时间，故障转移等）。
• 您必须要求更好地管理服务水平协议。
• 在将工作负载和数据移至云之前，您需要：
  • 验证数据隐私和合规性
  • 验证和整合工作流

此外，由于此模式基于双向依赖，因此该模式需要服务使用者和提供者之间的紧密协作。 这包括：

• 一个用于编排和路由本地与云服务之间的通信的中间件框架。
• 必须建立治理流程和标准以支持变更控制和生命周期管理。
• 集成，测试和支持的规划和设计。
• 必须定义明确的角色和职责； 可能需要进行一些组织和文化变革。
• 与外部云提供商的合同协议也必须得到各方的定义和同意。
• 云解决方案的安全性很可能会与本​​地解决方案保持一致。
• 运营支持功能可能会扩展到云解决方案。

全云（FC）

完整的云解决方案涉及仅使用来自一个或多个云提供商的云服务来交付生产就绪型解决方案。 用于交付客户端可见服务（例如业务和运营支持系统之类）的完整云解决方案的所有功能方面完全驻留在单个云托管环境中。

不面向生产的元素（例如开发和测试）可以使用混合云或完全本地解决方案。 同样，非生产元素不会出于生产目的而更改全云的定义。

特点

使用这种模式，就不会与本地组件和支持结构集成。 所有集成都在一个云环境中进行，并由一个数据中心托管提供商进行管理。 应用程序集成在云平台内进行，并利用通用云框架和IaaS。

拓扑结构

从概念上讲，完整的云模式可以表示为图5：

图5.完整的云拓扑

左侧的本地组件和右侧的云组件之间没有集成，任何集成仅在云内部发生。

从逻辑上讲，它类似于图6：

图6.完整的云逻辑结构

动机

您采用此模式的原因是：

• 您需要通过使用业界公认的最佳云解决方案来确保成功。
• 当前，您没有内部硬件技能与硬件或软件一起来设置云环境以及开发和管理解决方案。
• 您的上市时间很短，需要使用现有的云提供商。
• 这是一项短期或试验性的业务计划，您希望利用外部云环境来最大程度地减少前期投资。
• 您的成本考虑； 使用外部云提供商可能会比在您自己的环境中设置便宜。
• 您可以将解决方案部署在私有托管的云或公共云环境中，这在很大程度上取决于您的安全性和隐私，灵活性，支持以及可访问性。
• 您可能希望将自己建立为云服务提供商（CSP），并向现有或新客户提供解决方案。 该云服务将使用即付即用（PAYG），计量和退款云模型提供新的投资回报，并在您的行业范围内扩大您的商业形象。

关键用户方案

使用完整云模式的企业通常具有以下业务需求：

• 需要诸如营销活动之类的短期解决方案。
• 解决方案取决于与您的本地IT不兼容的技术。
• 技术证明，概念证明或试点计划站点。
• 新的业务或服务产品线。
• 独立方赞助的合资企业。
• 业务流程交易需要云和本地处理或所有组件都驻留在云中的数据。

决定因素

决定是否采用此模式的因素有：

• 消除本地IT支持的需求
• 云环境的灵活性和弹性
• 像PAYG这样的更具成本效益的模型
• 上市时间短
• 新的业务投资回报率

含义

如果采用这种完整的云模式，则要考虑的关键含义是：

• 您必须与云服务提供商建立自己的服务级别协议，以确保它可以满足您的运营需求。
• 您还需要验证云将满足您的数据隐私以及合规性要求和标准。
• 您必须建立治理流程和标准以支持变更控制和生命周期管理以及法律合规性。
• 必须建立业务支持服务以支持新的云模型； 例如订阅，客户入职流程和财务管理。
• 具有自助服务的Web门户以支持供应，报告等。
• 托管提供商必须能够支持灾难恢复和备份，以保护数据和应用程序的完整性。
• 必须具有足够的服务支持和补丁程序管理，以确保环境的健康。
• 在新功能上线之前，需要经过验证的变更/发布管理流程以及多个环境（例如，开发/测试，QA / DR和生产）。

扩展全云（EFC）

扩展云方案是整个云的简单扩展。 选择使用多个云数据中心并链接或分离服务的提供商可能会将其服务组合扩展到众多基础架构中。

特点

通过这种模式，可以与其他云环境中的一个或多个云解决方案集成。 没有与本地资源的集成。

拓扑结构

从概念上讲，扩展的全云模式可以表示为图7：

图7.扩展的全云拓扑

集成发生在不同云环境中的组件之间。 从逻辑上看，它类似于图8：

图8.扩展的全云逻辑结构

动机

您采用此模式的原因与整个云模式的动机相同，但是还需要与其他云集成。

关键用户方案

使用模式的组织通常具有以下要求：

• 提供各种云服务（SaaS，PaaS，IaaS，业务​​流程），使用户可以访问来自不同云服务提供商的服务。
• 根据用户的请求将用户路由到其他云服务。
• 要从一个云服务中提取数据，将其转换，然后将其加载到其他云服务中。

决定因素

帮助您确定采用此模式的因素类似于完整的云模式，即：

• 消除本地IT支持的需求
• 云环境的灵活性和弹性
• 像PAYG这样的更具成本效益的模型
• 上市时间短
• 新的业务投资回报率

此外，您需要解决将其他云服务整合在一起的能力。

含义

如果采用此模式，则其含义类似于完整云模式的含义。 此外，您还必须了解与多个云环境和多个提供商一起使用的操作方面（以及其他方面），以解决以下注意事项：

• 采用开放和行业标准
• 集成框架，可让您集成和编排服务
• 身份验证和授权支持，例如具有单点登录功能的联合身份管理器
• 多租户管理
• 自助服务门户，例如客户和提供商门户网站
• 统一和通用服务平台
• 治理标准，流程和程序
• 需要建立收益分享模型
• 计量和退款功能
• 合同管理
• 监控和审计能力
• 服务自动化
• 补丁管理

结论

游览这些云采用模式的特征-主混合云和扩展混合云以及全云和扩展全云-应该可以帮助您选择合适的云采用模式，以使您的组织更容易集成新服务并扩展业务通过实施新的云环境或扩展现有的云环境来实现功能。

---

翻译自: https://www.ibm.com/developerworks/cloud/library/cl-cloudadoptionpatterns/index.html