云启动了过时应用

现在让我们假设您建立了一个私有云环境。首当其冲的问题是您想把哪个应用迁移到这个云环境中，过时应用还是新研发的应用？这真的是个很好也很值得思考的问题。

如果您决定把过时应用迁移到该环境中，您也许需要考虑选择那些实实在在可以从云里得到好处的应用。这里也许有两个原因为什么把应用迁移到云中会得到好处。这些应用也许拥有不同的使用模式，在一段时间内需要迅速上升或下降的容量，或者这些应用需要为很多用户来配置。云也许无法给那些使用稳定的应用增加很多价值。

第一个需求可以用云来解决，您可以在这个环境中来配置应用；第二个需要请求配置服务。我们要先审查一下这些应用在不同情形下需要响应哪些特性。

配置应用

我觉得把那些有不同使用模式的应用迁移到云是很有意义的。为什么呢？我们在应用对若干条请求响应缓慢时都感到很有压力。云可以在性能低下时启动第二个应用程序来解决这个问题。使用负载平衡器可以将请求发送到任何一个任务中以确保一个适当的响应时间。

我所写的是一个假设，这个假设是应用中的多个任务同时运行而不影响该应用的性能。如果您的应用是个网络服务器用于管理多个网页的显示，那当然没什么问题。但如果您的应用是个订单管理系统事情就会比较棘手了。您需要保留一个独立的数据库来确保全部的用户都能访问系统中所有的订单。那么，首要的问题是您的应用和数据库哪个是瓶颈。如果是后者的话，在应用里创建两个请求是无法解决问题的。您需要首先创建一个数据库集群来移除瓶颈。一旦完成了，如果问题还是存在您可以尝试为应用创建多个请求。

现在我们意识到为了增加流量的重复应用也许会要求您对应用，使用的中介软件和数据库有一个灵活的牌照制度。比较理想的是您只在实际使用该软件的时候才支付牌照费用。但很遗憾很多ISV尚未在他们的牌照制度中开发这个水平的灵活性。

从自动化的角度来看，您需要为配置应用研发一套scripts。理想的情况下您会给该应用配备一个探测分析器以确保实时响应。然后您还需要研发一套使得第二个请求合理化的机制。第二个请求将会配备负载平衡器。

以上所有的一切都要对终端用户透明化。由IT部门负责管理建立请求，包括当那些请求不再需要时自动或手动将其关闭。

服务配置

服务配置对应用适配有着更高的要求。当然，现在您希望可以自动执行过去那些由服务生手动执行的任务。所以首先要查看的是否可以通过API或其他方法来启动任务配置。相应的信息会被传到应用上吗？我们能够在任务完成时看到该请求的状态吗？

当然，为了建立服务配置您需要创建一系列的工作流来自动化那些配置用户时需要的流程，让其可以访问该环境。比如当商业用户请求配置一个邮箱时，他会被要求提供一定的信息。该信息将会被自动传入到应用中去然后开始配置邮箱。该应用会传回这个任务的状态（比如成功配置或失败了，如果失败的话最好说明原因），这样云平台就可以通知用户并将必要的信息和状态保留好，一旦配置成功就可以访问该服务了。

这个环节里重要的地方是由应用提交的“服务”必须要是可访问的。通常公司创建网络服务都是为了跟云环境和这些应用之间对接，将用户从这些变化中屏蔽了出去。这样做的好处是可以把应用打包转移到云环境中，而无需让用户知道这些改变的实施过程。如果您想把您的应用转移或重新规划到云中的话也可以采取这个方法。

很显然一些应用也许拥有双重特性（工作量的可变性和用户配置），在这种情况下两个问题就都应该考虑。

我应该从云启动过时应用开始吗？

上面我们讨论了为什么要把您现有的应用迁移到云的两个主要原因，剩下的问题是，您该开始把已有的应用转移到云了吗？还是应该把它们保留在传统环境中并且为其包装上新的功能，特别是为云研发的功能吗？

坦白说，这个问题的答案肯定不止一个。这要看您的应用处在生命周期的哪个阶段。如果您准备在可预见的未来取代某个应用，也许就不想花时间和经历来配置它了。但如果这是一个非常关键的也是您还想保留一阵子的应用，请确保一件事情：用云思维去建立任何新功能。