选择正确的云采用模式

发现最佳采用模式以集成新服务和扩展业务功能

模式包含适用于复杂任务的最佳实践和专业知识,这些都是从真实活动中反复提炼而来;它们有助于以清晰的格式定义良好的解决方案,以便处理反复出现的问题。计划实现一个云呈现的企业应该将 “云采用模式” 视为启动该流程的一种方法。作者将详细介绍如何应用云采用模式(每种模式都概述了其具体特征)来支持企业的云实现的业务和技术需求。这些示例展示了云解决方案供应商如何构建私有和公共云,将客户端应用程序全部托管在云环境中(比如,IBM® 云服务产品提供的环境),或者部分托管在云中,部分托管在本地。

Tina Abdollah, 高级认证执行 IT 架构师, IBM

Tina Abdollah 是 IBM Global Business Services 的一名高级认证执行 IT 架构师,也是 Open Group 一名杰出的认证 IT 架构师,还是 IBM Academy 的一员。她有着超过 25 年的分布式网络环境信息技术系统工作经验,主要关注使用各种技术和方法,比如企业基础架构、云计算、业务流程服务优化以及 SOA/Web 服务,设计并实现大型复杂企业 IT 解决方案。



Bernie Michalik, 高级IT认证架构师, IBM

Bernie Michalik在设计、构建和实施复杂IT解决方案方面拥有二十二年的经验,担任过许多不同类型的角色,从领导大型团队创建大型的系统基础结构到单独为全球客户开发定制软件。他的经验涵盖了广泛的方法论。



2013 年 11 月 28 日

模式包含反复从客户和合作伙伴活动中提取的适用于复杂任务的最佳实践和专业知识。模式可帮助用户以清晰的格式定义良好的解决方案,处理反复出现的问题;不管使用什么技术(包括软件、中间件或编程语言),都可以将该模式应用于具体的使用案例。

随着越来越多的解决方案被部署到云中,随着云计算逐渐成为一个新兴开发领域,出现了很多新产品和新技术供云用户使用;理解云模式,特别是采用模式,并协调最合适企业实现场景、动机和缓解措施的模式,可帮助您构建一个良好的云应用程序。

例如,对于某些需求而言,如果该解决方案需要与驻留在内部云环境或其他云环境中的 IT 组件相集成,那么完整的解决方案(其中所有 IT 资源都驻留在云中)可能并不是最佳解决方案。与某些需求匹配的拓扑结构和模式相集成可帮助架构师缩小解决方案元素范围,从而支持功能性和非功能性需求。

模式还可以帮助用户识别选择一种模式对另一种模式的影响,这有助于架构师向企业突出显示选择的多样性。

本文目的是帮助云架构师选择一个合适的云采用模式,该模式可帮助扩展业务功能,并集成现有本地系统和云供应商提供的新服务。本文的焦点主要集中在集成方面,使用采用模式以一种抽象形式支持云服务模型(基础架构即服务 [IaaS]、平台即服务 [PaaS]、软件即服务 [SaaS] 以及业务流程即服务)和云类型(公共、私有、混合和社区),从而对云解决方案产品进行分类。这些抽象形式将帮助您根据自己的业务模型、所需云成熟度级别选择适合的采用模型和技术(比如,软件、平台和工具),它们的主要目标是向您提供第一个关键步骤,实现向云实现或扩展迈进的切实可行的整体方法。

在下面小节中,我们将回顾关键云采用模式并介绍其属性、特征、拓扑结构、动机和其他决策因素;我们提供了一些用户场景和案例研究示例,帮助提供相关的背景。

满足云采用模式

一般而言,根据应用程序、数据和基础架构共享特征,可以将云模式分成 4 类:

  • 应用程序在本地云(私有云)上托管;数据和基础架构不能共享。
  • 应用程序在公共云上托管;数据和基础架构可以共享。
  • 应用程序结合使用私有云和公共云(混合云);数据和基础架构可以选择性地共享。
  • 社区云,是专为特定社区功能而设计的,允许社区用户之间相互协作。

这些云模式与云服务模型相关但不同于云服务模型。云服务模型(对本文而言)也可以分为 4 组:

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

这里介绍的采用模式是基于第一组特征的,包含所有云服务模型。该云采用模式称之为:

  • 主要混合云 (PHC)
  • 扩展的混合云 (EHC)
  • 完整云 (FC)
  • 扩展的完整云 (EFC)

以下小节概述了每种模式的属性、特征和拓扑结构。各个小节还将向您提供使用它们的动机、选择某个模式的利弊之处以及采用特定模式的影响。


主要混合云 (PHC)

主要混合云模式是一种将本地或托管部署扩展到云环境中的方法。处理实例是根据需求部署的或预先分配好的,它们通常并没有集成到运行时服务提要中。

该模式有一个单向方案可实现服务交付,每次仅依赖一个运行资源。数据中心功能提供这类服务作为数据服务、业务支持服务(用于计费、客户管理等等)、操作支持服务(比如,服务自动化,计量等等)、支持服务、监控服务、安全性服务和网络服务。

特征

利用该模式,可与本地组件进行有限的集成;组件与非双向同步是松散耦合的。该模式不与其他云解决方案相集成。

拓扑结构

从概念上讲,主要混合模式可以用图 1 来表示:

图 1. 主要混合云拓扑结构
主要混合云拓扑结构

左侧的本地组件和驻留在右侧云组件之间的集成是有限的。逻辑上看起来类似于图 2:

图 2. 主要混合云逻辑结构
主要混合云逻辑结构

动机

采用该模式的动机理由包括:

  • 您需要使用附加功能来处理那些本地系统无法满足且可不限制本地系统输入进行操作的状况。
  • 您需要预先处理一些原始数据,但不需要在本地存储这些原始数据;只需存储结果。
  • 您需要使用一些在本地无法运行的软件组件
  • 您没有现成的技能组合来搭建环境或运行本地软件。
  • 您的上市时间太短,而且只有云供应商才能满足业务需求,内部技术无法满足这些需求。
  • 您认为您可能需要一个扩展的混合云,但是您还没有做好准备。

关键用户场景

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

  • 您想要运行其他批处理流程,但是您本地系统上目前没有处理窗口。
  • 您有一个大数据项目可从互联网上收集数据,但您想要根据本地系统的输入对其进行数据挖掘(例如,业务智能 [BI] 报告)。
  • 您想要在云中托管一个内容管理系统,该系统包含本地内容管理系统的一个子集。
  • 您想要测试一个在操作系统上运行的新应用程序,该操作系统可在云中运行但是不能在本地运行。
  • 您想要通过复制对外部用户共享本地数据。
  • 您想要提供核心服务之外的其他服务(比如数据分析),这些服务是基于本地系统的,但是对于核心业务来说并不是必需的。
  • 您想采用外包的电子商务功能提供给 SaaS 供应商,比如付款服务或账单服务。

决定因素

决定您是否采用该模式的因素有:

  • 想要限制对完整云部署的承诺。
  • 风险隔离:例如,批处理可能失败,但是对常用环境没有严重影响,风险隔离会减小对您核心业务的影响,而且不需要太多内部设备支持。
  • 投资最小化:您想要在发布完整云之前快速获得初步云经验。
  • 灵活性:该模式支持您以最小承诺扩展现有业务。
  • 最小化集成和流程依赖性。
  • 不需要对您的数据进行分区。
  • 不需要实时事务。

影响

如果您采用该主要云模式,需要考虑的关键影响包括:

  • 需要维护一个云支持结构和一个本地系统支持结构,可能会包含冗余或冲突。
  • 如果云环境需要本地监控,那么可能需要您自己提供监控,这种情况的可性能很小。
  • 您需要做的工作是限制从本地系统到主要混合云服务的集成。
  • 与云供应商一起建立治理模型(例如,变更控制,QoS)和标准。
  • 需要建立合同管理、条款和条件。
  • 云解决方案安全性可能不同于本地解决方案。
  • 现有操作支持功能可能不能扩展到云解决方案,可能需要检查和改进当前支持结构。
  • 建立验证和审计云供应商提供的服务的指标。
  • 可能要求用户教育和培训中包含扩展功能。
  • 需要获得应用程序迁移和批处理管理支持。
  • 需要一个灾难恢复计划来包含云扩展。
  • 接收实时集成和主要混合云服务的能力可能有所限制。

扩展的混合云 (EHC)

扩展混合云涉及将一个或多个本地或托管环境附加到云环境中。扩展混合云由一个混合资源环境构成,结合使用本地和云资源来提供云服务;依赖这两种环境来交付真实的端到端功能。扩展的混合云对服务交付有双向依赖,因为它们依赖两个独立的资源进行激活和运行来交付服务。

特征

该模式可与本地组件大量集成,这些组件与双向同步紧密耦合。这使得该模式不同于主要混合模式。现有 IT 和云环境之间的数据和功能的耦合较为紧密,以便于交付预期的服务;不过,这是一个独立的云解决方案,而且不能与其他云解决方案集成。所有集成均发生在本地系统上。

拓扑结构

从概念上讲,扩展的混合模式可以用图 3 表示:

图 3. 扩展的混合云拓扑结构
扩展的混合云拓扑结构

与主要混合模式中的集成相比,左侧的本地组件和位于右侧的云组件之间的集成更为密切。

从逻辑上看,该集成如图 4 所示:

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

动机

采用该模式的原因有:

  • 云组件依赖本地数据存储,反之亦然。
  • 本地运行设备对于云组件来说是必需的,反之亦然。
  • 本地处理对于云处理来说是必需的,反之亦然。
  • 实时或近实时处理以及与云组件和数据存储通信也是必需的。

关键用户场景

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

  • 在云和本地系统中以同步方法创建、更新或存储数据的事务处理。
  • 业务流程事务需要集合云处理和本地处理方能完成。
  • 关键组件必须驻留在本地系统,而其他组件则位于云中的事务中。
  • 本地事务,在该事务中,某些报告功能(比如,专家数据分析等等)需要使用云中的适用于该报告的附加数据和流程。

决定因素

帮助您决定是否应该采用该模式的因素有:

  • 支持现有本地 IT 投资的重用。
  • 拥有根据隐私因素进行数据分区的功能。
  • 提供实时或近实时 BI 或流程集成。
  • 通过云组件扩展现有业务功能。

影响

如果您采用该混合云模式,要考虑的关键影响有:

  • 本地操作人员必须理解云组件,反之亦然(例如,停机时间、故障恢复,等等)。
  • 必须更好地管理服务水平协议。
  • 在将工作负载和数据移到云中之前,需要执行以下操作:
    • 验证数据隐私和合规性
    • 验证和集成工作负载流

此外,这种模式要求服务客户与供应商进行紧密协作,因为该模式是基于双向依赖的。这包括:

  • 一个中间件框架,用来设计和路由本地和云服务之间的通信。
  • 必须建立治理流程和标准,以支持变更控制和生命周期管理。
  • 计划和设计集成、测试和支持。
  • 必须明确定义角色和职责;可能需要执行一些组织和文化变更。
  • 必须与外部云供应商签订合同协议,并且必须得到各方认可。
  • 云解决方案的安全性很可能与本地解决方案保持一致。
  • 操作支持功能可扩展到云解决方案。

完整的云 (FC)

一个完整的云解决方案包含交付一个生产就绪的解决方案,只使用一个或多个云供应商的云服务即可完成此任务。用于交付客户可见服务(比如业务和操作支持系统)的完整云解决方案的所有功能都完全位于单个云托管环境中。

面向非生产环境的元素(比如开发和测试)可以使用混合云或一个完整的本地解决方案。另外,出于生产目的,非生产元素不能改变完整云的定义。

特征

该模式不能与现场组件和支持结构相集成。所有集成都出现在一个云环境中,由一个数据中心托管供应商管理。应用程序集成发生在云平台中,并利用了常用云框架和 IaaS。

拓扑结构

从概念上讲,完整云模式可以图 5 表示:

图 5. 完整的云拓扑结构
完整的云拓扑结构

左侧的本地组件和驻留在右侧的云组件不能集成,所有集成都只能发生在云中。

从逻辑上看,该集成类似于图 6:

图 6. 完整的云逻辑结构
完整的云逻辑结构

动机

采用该模式的原因有:

  • 您需要使用最佳组合和经过行业验证的云解决方案来确保成功。
  • 您目前没有内部云技术集(硬件或者软件的)来构建云环境以及开发和管理该解决方案。
  • 您的上市时间太短,需要使用一个现有云供应商。
  • 这是一个短期的或试验性的商业计划,而且您需要利用一个外部云环境来减少前期投资。
  • 您的成本考虑;与在您自己的环境中构建相比,使用一个外部云供应商可能比较便宜。
  • 您可以将解决方案部署在一个私有托管云或公共云环境中,这很大程度上取决于您的安全性和隐私性、灵活性、支持性和及可访问性因素。
  • 您可能想要让自己成为一个云服务供应商 (CSP),向现有或者新客户提供您的解决方案。该云服务将使用一个现收现付 (PAYG)、计量和退费云模型提供一个新的 ROI,并在您的行业领域扩展商业地位。

关键用户场景

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

  • 需要短期解决方案,比如营销活动。
  • 依赖技术的解决方案与您本地 IT 不兼容。
  • 一个技术验证、概念验证或试点项目网站。
  • 一个新业务或服务产品线。
  • 有独立第三方赞助的合资企业。
  • 业务流程事务需要云和本地处理或数据,其中所有组件都驻留在云中。

决定因素

决定您是否采用该模式的因素有:

  • 需要减少本地 IT 支持
  • 云环境的灵活性和弹性
  • 更具成本效益的模型,比如 PAYG
  • 更短的上市时间
  • 新业务 ROI

影响

如果您采用该完整云模式,那么需要考虑的关键影响有:

  • 您必须与云服务供应商合作,建立自己的服务水平协议,以确保该解决方案可满足您的操作需求。
  • 您也需要验证云是否满足您的数据隐私和合规性需求和标准。
  • 您必须建立治理流程和标准,以支持变更控制和生命周期管理以及法律合规性。
  • 必须建立业务支持服务来支持新的云模型;例如,订阅、客户登记流程以及财务管理。
  • 拥有一个自服务 Web 门户来支持预配置、报告等等。
  • 托管供应商必须能够支持灾难恢复和备份以保护数据和应用程序的完整性。
  • 必须有充分的服务支持和批处理管理来确保环境的正常运行。
  • 在新功能上线之前,需要经过验证的变更/版本管理流程以及多个环境,例如,dev/test、QA/DR 和生产环境。

扩展的完整云 (EFC)

扩展的完整云场景是一个比较简单的完整云扩展。选择使用多个云数据中心以及链接或解耦服务的供应商可能跨多个基础架构扩展其服务组合。

特征

该模式可以与其他云环境中的一个或多个云解决方案相集成,但不能与本地资源相集成。

拓扑结构

从概念上讲,扩展的完整云模式可以用图 7 表示:

图 7. 扩展的完整云拓扑结构
扩展的完整云拓扑结构

驻留在不同云环境中的组件之间会出现集成,从逻辑上看,该集成如图 8 所示:

图 8. 扩展的完整云逻辑结构
扩展的完整云逻辑结构

动机

您采用该模式与采用完整云模式的动机相同,但是还需要与其他云集成。

关键用户场景

使用该模式的企业通常有以下需求:

  • 提供各种云服务(SaaS、PaaS、IaaS、业务流程)使用户可访问不同云服务供应商的服务。
  • 根据用户的需求将其路由到不同云服务。
  • 从一个云服务中提取数据,并对数据进行转换,然后将其加载到另一个云服务。

决定因素

帮助您决定是否采用该模式的因素与采用完整云模式的因素类似,这些因素包括:

  • 需要减少本地 IT 支持
  • 云环境的灵活性和弹性
  • 更具成本效益的模型,比如 PAYG
  • 更短的上市时间
  • 新业务 ROI

此外,您还需拥有结合其他云服务的功能。

影响

如果采用该模式,影响类似于完整云模式。此外,您还必须理解使用多个云环境以及多个供应商来处理这些考虑因素的操作方面(以及其他方面):

  • 开放行业标准的采用
  • 允许您集成和设计服务的集成框架
  • 验证与授权支持,比如具有单点登录功能的 Federated Identity Manager
  • 多租户管理
  • 自服务门户,比如一个客户和供应商 Web 门户
  • 统一和通用服务平台
  • 治理标准、流程和程序
  • 需要建立一个收益共享模型
  • 计量和退费功能
  • 合同管理
  • 监控和审计功能
  • 服务自动化
  • 补丁管理

结束语

这些云采用模式(主要混合云、扩展的混合云、完整云和扩展的完整云)特性的学习之旅将帮助您选择适当的云采用模式,使您的企业通过实现一个新云环境或扩展现有的云环境,就可以轻松地集成新服务和扩展业务功能。

参考资料

学习

获得产品和技术

  • 以最适合您的方式 评估 IBM 产品:下载产品试用版,在线试用产品,在云环境下试用产品,或者在 SOA 沙盒 中花费几个小时来了解如何高效地实现面向服务的架构。

讨论

  • 加入 developerWorks 社区。探索由开发人员推动的博客、论坛、组和维基,并与其他 developerWorks 用户进行交流。

条评论

developerWorks: 登录

标有星(*)号的字段是必填字段。


需要一个 IBM ID?
忘记 IBM ID?


忘记密码?
更改您的密码

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件

 


在您首次登录 developerWorks 时,会为您创建一份个人概要。您的个人概要中的信息(您的姓名、国家/地区,以及公司名称)是公开显示的,而且会随着您发布的任何内容一起显示,除非您选择隐藏您的公司名称。您可以随时更新您的 IBM 帐户。

所有提交的信息确保安全。

选择您的昵称



当您初次登录到 developerWorks 时,将会为您创建一份概要信息,您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。 您的昵称在 developerWorks 社区中必须是唯一的,并且出于隐私保护的原因,不能是您的电子邮件地址。

标有星(*)号的字段是必填字段。

(昵称长度在 3 至 31 个字符之间)

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件.

 


所有提交的信息确保安全。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Cloud computing
ArticleID=954285
ArticleTitle=选择正确的云采用模式
publish-date=11282013