通过云服务，你能够为客户和员工带来额外的价值，甚至建立起新的收益流。以下我们将介绍如何在现有应用中找到适当的服务，让它们为迎接云计算做好准备。

　　得益于亚马逊EC2、Salesforce和其它公有云服务取得的成功，许多企业了解了云计算的价值。实际上，越来越的企业开始尝试云计算。为什么不呢?启动一个公有云服务或许可以在最小限度修改现有基础设施的情况下建立一个新的收益流，或是为客户提供便捷的自助服务。不过，启动一个云服务的过程未必一帆风顺。企业IT经理需要确定在苛刻的条件下哪些应用能够转移到云上。此外，他们必须要建立或修改服务接口或API，应对控制与安全方面带来的新挑战，包括建立用于计费与收费的使用情况追踪功能。你是否已经为云业务做好了准备?你的哪些服务已经成熟到可以变成云服务?你如何建立一个成功的商业案例?你如何创建一个成功的云服务，无论它们是简单的还是复杂的?本文将提供一些建立云服务的通用指南，包括如何识别、判断、迁移和检验新的和现有应用服务向真正云服务转型。通过这些信息，你将对如何在企业内部或外部建立一个弹性服务有一个大致了解。

　　步骤1：为云选择正确的应用

　　每个公司都有一个人人都认为会成为优秀云服务的应用。但是往往分析证明情况并不如人们所认为的那样。

　　你需要创建一个商业案例，以证明不同于单个应用或多个应用的云服务具有优势。你需要考虑云服务实际上是什么?需要考虑技术现实，包括迁移成本和性能。换句话说，云服务的真正投资回报是什么?

　　为了确定可行性，你首先需要考虑应用的实际价值。理解云服务的使用案例，例如以下这些常见的案例：

　　1、外部客户能够获取订单信息，包括检查订单状态、延迟和升级等。

　　2、通过向其它外部公司出租库存控制云服务，公司能够获得额外利润。

　　3、公司其他部门能够有效获取正在使用云服务的数据，无论是人至机器还是机器至机器，这将促使数据品质提升。

　　确定潜在的云服务能够解决的问题是确定云服务价值的第一步。需要记住的是，在一些实例中，你需要移动整个应用。而在其它一些实例中，你仅需要通过Web服务协议提供一些简单的服务。

　　一旦在配置云服务之后确定了“原因”和“内容”，你需要确定怎么做，更重要的是，它的成本可能是多少。迁移成本取决于现有应用的状态和应用架构，以及作为云服务，你希望它们具有应用的哪些功能，或是完全像应用一样。

　　很明显，评估方式很大程度上取决于应用类型和你准备提供的服务。以下常用的评估步骤列表将帮助你着手：

　　评估现有应用的状态

　　评估当前用户接口设计

　　评估当前的安全设计

　　确定基于使用情况的账单如何计费

　　评估核心应用和其它再开发任务的修改程度

　　考虑可能使用服务的内部或外部客户数量，评估可能需要哪些额外的架构

　　评估需要增加哪些云计算功能，例如自动配置或多租户

　　评估研发服务接口的成本和投入

　　确定与现有安全系统的整合所需要的投入

　　草拟测试与阶段实施计划

　　评估部署成本，包括以后扩展所需要的基础设施。

　　一个总的原则为，应用越老越复杂，向云迁移的成本也就越高，费效比也就越不合算。与此同时你还要考虑技术的可靠性，例如性能损失。在通过开放的互联网访问时，任何内部应用都会都会出现性能下降。

　　在将应用修改作为云服务时，应当考虑以下因素：

　　迁移成本。这是修改应用，让其满足云计算服务要求所付出的代价。包括所有需要的新硬件和软件，以及调整架构和设计、研发成本、测试资源、部署成本等等。

　　风险成本。换句话说，如果将应用向云计算迁移失败，会遭受经济损失。

　　长期维护成本。随着时间的迁移，你需要在维护云服务方面花费多少资金。

　　商业价值。让应用成为真正云服务的潜在收益已经超过了预期收益，包括战略价值，例如能够为现有客户群提升服务，可更好的挽留这些客户。

　　简而言之：云服务的价值=商业价值-(风险成本+迁移成本+长期维护成本)。这一公式的时间范围为三年。

　　如果一个应用转型为云计算服务具有$20,000,000的商业价值、$5,000,000的风险成本、$4,500,000的迁移成本和$2,000,000的长期维护成本，那么可以表述为：

　　云服务的价值/投资回报= $20,000,000 - ($5,000,000 + $4,500,000 + $2,000,000)

　　因此，云服务的价值大约为$8,500,000。很明显，这例子已经很好的证明了其自身的价值，你的云服务转型相当合算。

　　在进行决策时，你应当考虑表1中所列出的内容：

　　图1　在准备创建云服务时应当仔细考虑以下问题：

　　明确为业务带来的优势。

　　所选应用有明确而经济的可行技术路径以提供云服务。

　　能够定义可用的使用案例。

　　能够整合基于使用的计费系统以测量服务的使用量。

　　能够创建合理的安全架构，保护关键的商业信息。

　　对数据和服务具有良好的管理方法。

　　步骤2：评估现有的应用架构

　　一旦你计算出可行的投资回报，证明你云服务具有合理性，那么你就可以关注现有应用的架构了。其中包括：

　　数据

　　服务

　　流程

　　网络

　　用户接口和API

　　安全性

　　管理性

　　扩展能力

　　这方面更多的取决于应用的老旧程度以及应用是如何设计的。在许多实例中，较新的应用被创建时使用的是针对于行为与数据的API。较老的应用可能根本没有API。在一些案例中，较老的应用在向云服务迁移时需要花费额外的时间与精力。

　　当然，总是有办法与老旧的应用进行沟通的，例如事务接口、直接数据访问，甚至是屏幕抓取。但是这些方法常常存在性能与扩展性问题。是使用这些接口还是对架构进行大幅修改应当考虑效率问题。

　　当你全面了解了应用架构，你将更加深刻地理解将核心应用服务转变为云服务的最佳方式。这包括了解数据库的结构和工作机制、数据库访问方式、业务逻辑的使用与执行、与用户接口的整合，以及核心业务流程的诸多组件等。

　　首先要将应用分解成功能基元，如数据、服务、流程、用户接口等。一旦你全面了解了这些组件，你就能够为应用重新创建逻辑架构，让其适合云服务要求。其次是将新的逻辑架构映射到物理架构中，确定创建物理架构所需要的工作。

　　步骤3：为创建云服务选择最佳的方式

　　目标系统应当为真正的云计算系统。换句话说，他们应当提供现有应用所没有的新功能。例如：

　　机器寻址。无需人参与的访问、分配和使用云服务、机器至机器的能力

　　多租户。能够同时支持大量外部云服务用户，确保性能一致，保证租户不会相互干扰。

　　基于使用的计费。能够监控授权用户的云服务使用情况，根据使用情况进行计费。

　　高级安全性。包括能够管理安全使用方式和基于身份的方式。

　　为新的或现有的应用创建云服务有三个基本的方法。它们的规模分为小、中、大。

　　在小型云服务方案中，我们仅具体化应用的一小部分，通常是那些执行如数据有效性操作的服务。几乎只需要创建一个Web服务。这个Web服务有一个被良好定义的接口，以接受云服务客户的数据、应用所连接的数据库中的有效数据，然后将状态反馈给客户。例如，客户通过开放的互联网使用Web服务确认一个订单。为了说明问题，我们创建一个Validate_ Order()的服务。该服务会做以下工作：

　　启动服务记录服务

　　与客户的使用情况

　　记录时间

　　接受订单号

　　确认订单号

　　在数据库中查找订单号

　　反馈状态，有效或无效

　　记录时间

　　关闭服务

　　当然，你需要保证你能够通过多用户/多租户方法做这个。这意味着你必须为所有的用户平均分配，保护用户流程。此外，你还需要利用按使用量收费的计费系统追踪使用情况，无论你是否对这一服务收费。

　　在部署这种小型解决方案中你能够使用不同的技术，包括在独立处理空间内运行的外部程序。这些外部程序不与核心应用挂钩，可能只需要稍做修改，甚至不需要进行修改。或许服务可能与应用结合紧密，需要对核心程序进行一些修改。它们没有固定的解决方案或是最佳实践。你需要根据具体情况调整每一个云服务。

　　一旦你创建了这种服务，你需要与相关的WSDL相连，以及选择了一个通信方法，这通常被称为REST(表述性状态转移)。客户应当能够通过URL访问服务，因此必须了解如何通过读取WSDL调用服务，以及如何使用REST调用服务。

　　在中型云服务解决方案中，我们通常会面对许多不同的云服务，它们提供了许多不同类型的功能。你可以认为它们的规模是小型云服务解决方案的5至10倍。它们拥有更多可被云服务客户访问的并行云服务。这意味着你需要应对更多的并行和多租户问题。

　　在大型云服务解决方案中，我们通常要应对数百，甚至是数千个被具体化和托管的云服务。这类云服务可能每天会被数千个用户所使用。这些用户的访问方式和目的都不尽相同。我们所面对的挑战并不是服务的具体化，而是这些云服务的并行管理，让其长期处于良好的运行状态。换句话说，核心目标是扩展性与稳定性。

　　在中型与大型云服务解决方案中，你需要对核心应用进行更多系统性重新设计，包括修改核心数据库和计算服务(见图2)。你只能在两种办法中选择一个。

　　1、附加软件提供了云能力。实际上，中间件将原生的应用服务转变为了云服务，并通过产品预先设置的功能管理这些服务。目前市场上已经出现了这类产品，它们通常被称为“云能力软件”。

　　2、彻底从头重新编写应用。重新编写的应用将满足云服务的需要，包括支持多租户。这实际上是一个重新创建应用的机会，或许可以使用更新的编程语言或数据库技术。与在老代码上编写相比，更新的编程语言或数据库技术的成本会更低。

　　图2　通过专门为这一目标设计的软件，你能够具体化云服务，或是通过重新编写应用将服务具体化。最佳办法取决于你的应用。

　　最后，在考虑应用架构、云服务具体化与管理时，你需要考虑使用的标准。这里的大多数标准都与Web相关，例如WSDL、SOAP、REST等。当然，部分标准是在云计算领域中新出现的，包括安全标准和管理标准。应当在项目开始前就考虑好适合你的云服务的最佳标准与解决方案。

　　步骤4：评估安全问题

　　在云计算的执行中，安全性排在首位。在设置云服务的过程中，无论是公有云还是私有云，你都应当考虑安全措施。其中包括创建一个安全模型，选择适当的安全技术，全面了解存在的风险。

　　云服务的安全模型通常十分复杂，使用了大量先进的加密技术与基于身份的安全技术。

　　基于身份的安全技术意味着你可以追踪人类用户的身份、机器用户、数据、服务等，让你能够细致地管理安全问题，确定谁能够访问特定的服务，以及他们能够通过这些服务做什么。例如，我们知道特定身份的机器能够调用服务，因为机器在允许调用服务之前已经经过了授权。身份管理安全软件系统通常需要一资源库以追踪身份，需要能够对所有的参与者进行授权和认证。

　　加密是另一个标准的云服务安全机制。客户和服务提供商应当能够在需要的时候提供加密措施，确保服务提供商与客户之间的会话是私密的。当加密数据从一个系统中传输到另一个系统中，我们称之为动态加密。

　　此外，你还需要考虑保护内部数据。强化的保护措施能够确保外部伙伴无法接触到你的核心应用或是访问数据库。当数据存储在磁盘中时，数据被进行加密处理。当这些数据根据需要被提供给应用或云服务时，它们会被解密。

　　步骤5：确定成本模型和基于使用情况的计费方式

　　最后一步是找出如何追踪你的云服务的使用情况，以及如何根据使用情况进行收费。许多商业软件会为你追踪云服务使用情况。这些商业套件为外部应用，它们可以与你的核心应用和云服务结合在一起。其中一部分软件是常规的授权许可软件，还有一部分是由公有云提供商提供的云服务。选择哪一种取决于你偏爱的成本模式和云服务特点。由于技术很容易获得，因此没有必要自己创建。

　　其次是，决定如何对服务进行收费。部分公有云计算服务的收费方式与手机通信公司为手机服务收费相似。部分服务在企业内部中传输也会收费。以下是几种收费模式：

　　交纳一定费用后不限量使用

　　根据时间收费

　　根据席位收费

　　根据流量收费

　　交纳一定费用后不限量使用收费方式也追踪服务的使用情况，但是客户可以随意使用。通常，这适合于你了解服务用户，以及将提供服务作为一种附加优势。

　　如果你选择根据时间计费，那么基于使用情况的计费系统将汇报使用情况，并为你生成账单。账单将根据预先约定的期间定期自动发送。

　　如果你选择根据席位收费，那么费用总额为用户账号数量乘以每月使用率，或是测量每名用户的使用情况，然后分别计费。如果你选择后者，那么一定要确保套餐能够满足你的需求。

　　如果你选择根据流量计费，那么云服务提供商将根据你传输给客户的数据流量收费。通常，流量者是兆字节级。此外，数据使用量将被跟踪。账单将会被自动发送至云服务客户手中。

　　现在是什么情况?

　　具体化应用数据和使用公有与私有云计算的速度将加快。实际上，创建云服务将为一些公司带来新的营利机遇，同时为向公司内外推广企业应用核心价值提供了一个相对容易的方法。请记住，在开始转向云计算之前应当仔细评估你的应用。一些貌似能够成功转向云服务的应用可能有时候最终会因为一些潜在的原因而无法转型。另一方面，如果你对你的所有应用了如指掌，那么你会很容易找到一些你以前从未想过要迁移至云服务的应用，而这些应用可能更容易转向云服务。

　　一切都由你自己做主。它们会为你带来充足的营利空间，尤其是当你选择部署一些能够为公司提供特色功能的服务。