从云服务市场的某些视角看，业务连续性是从故障预防和恢复过程进化而来的，一系列内置的实现系统弹性的特性。

　 　 这在基于Web的应用领域最常见，通过低成本和广泛普及的公有云资源提升高可用系统架构的弹性。但现在还无法确定这样的模式能否适用于企业级的日常应用。而基于云实现弹性还面临一些逻辑上的障碍，例如法规遵从、成本和需要对应用的设计做更改等原因。

　 　 “在世界末日到来时，所有设备都失效……而您需要为这样的失效搭建系统，”总部位于洛杉矶的亚马逊云服务（AWS-Amazon Web Services）分销商Stratalux Inc.,创始人和CEO Jeremy Przygode这样认为。

　 　 是否企业希望考虑应用的弹性“取决于应用、复杂度和多少人愿意为这件事付费，”Przygode说。

　 　 新模式：在云中构建故障预防

　 　 在云计算时代，由于弹性设计已经加入到最新编写的应用中，供应商宣称云的中断对他们所提供服务带来的影响就像打了一个嗝。而Web公司已经具备重新设计系统架构的能力。

　 　 当亚马逊在6月发生停机时，电子商务网站Decide.com几乎没有感觉到影响，“我们在物理上是隔离的，因此我们设计的系统可以预防，除了所有的亚马逊站点都瘫痪以外的其它任何情况，”CTO Kate Matsudara说。

　 　 Decide的服务在多个不同的Amazon Availability Zones之间实现冗余，Amazon云的一个设计使得机器的实例可以运行于多个相互隔离的站点之间。任意跟客户相关的关键服务都至少能在一个以上的站点可运行，Matsudara说。

　 　 “当亚马逊停机发生时，我们确实获得提示和通知，但当看到这个的时候，我们只是在另一个Zone中添加更多资源，然后就可以承担了”，她说，“这非常简单而且平常——这些都是在云里发生的，因此您需要为此做设计和准备。”

　 　 “这里您可以选择很多不同的设计模式”，她说，“其中之一可以想象成断路开关，当您有了下游延迟的感觉时，只需把软件架起感觉像故障不存在一样，这样依然可以为用户提供服务。”

　 　 举个例子，假设Decide.com的某个目录（例如销售运动相关产品的）失效，运行网站的软件将禁止用户点击“sports”，但是其它的目录部分都可以正常地提供服务。

　 　 其它的一些运行亚马逊AWS的公司依也在致力于增强应用的弹性。例如，Netflix认为这样的弹性非常重要，因此设计了一个名为Chaos Monkey的开源工具，它可以随机地关停一些亚马逊的机器实例，以测试他们的应用是否可以在系统故障时生存。

　 　 新视角：多个云故障切换满足企业需求

　 　 专家认为，虽然AWS的冗余可以满足网站类公司的需求，但真正企业级的弹性应用应该需要横跨多个云实现。

　 　 “这已经是亚马逊固有的(满足故障需求)的思维方式，但是……把亚马逊作为唯一的供应商本身是个单点故障，”Przygode说。

　 　 “任何需要弹性的云应用应该可运行于任意的云，而不是绑定到某个指定的云，” The Virtualization Practice LLC.公司的CEO Edward Haletky这样说。

　 　 感谢通用编程语言和网络虚拟化，在应用层面实现跨云的弹性在技术上是可行的，根据Haletky的说法。

　 　 “如果单说应用，我可以设计一个Java或PERL或PHP甚至是C的app，可以横跨多个网络，使用物理或虚拟的VPN和L2网络排列在一起，”他说，“可以这么做，问题在于您是否希望这样，以及您能否承担这么做的费用？”

　 　 新挑战：企业级应用和云弹性之间的障碍

　 　 虽然这样的设计技术可行，但在今天的企业级应用和将来更为弹性的和地域上分布式的模式之间依然存在很大的障碍。

　 　 为防止应用故障，app的设计都是松耦合的，以避免某个组件的故障会对所有依赖于它的组件造成影响。App的组件还应该是冗余部署的，可以互相接管工作。

　 　 “这对于很多传统的企业级应用而言是很大的挑战，”位于Cambridge, Mass.的分析公司Forrester Research Inc.分析师James Staten这样说。

　 　 以MySQL数据库系统为例，根据Yipit（一家对Groupon这样网站的日常交易进行过滤的Web公司）的开发运维人员Andrew Gross的说法，其原始设计就是在一个地点运行，即应用的主存储站点。

　 　 两个MySQL数据库——或同一个MySQL数据库的两半被设为在同一个分布式的弹性架构中共同工作，或许会拥有不同数据的同一个钥匙。例如，一个数据库中的记录被位于加州的用户使用，而另一个用户位于纽约。要想合并非常的难，因为两个人都认为自己的这份记录才是正确的。

　 　 “为避免这种情况，您需要应用自己对这样的信息进行跟踪记录，并以某种机制告知“正确的记录应该是这份””Gross说，“还有些其它的类似问题，例如两半数据库都需要了解两外一半在跟谁交互”。

　 　 考虑到这些难题，Netflix这样的Web公司考虑了分布式数据库，Gross说他正在评估，也特别提到了Cassandra。

　 　 “这回到一点上，实际上我们不是在寻找某种数据库可以满足所有的需求，而是寻找不同的数据库根据目的的不同，去跟不同的应用去交互，”他说。

　 　 同时，还有个网站显示这些结果，但根据Gross的说法，做这些研究和开发工作的时间已经很紧迫了。

　 　 这类工作也很费钱，Przygode提到，“人们常会说‘你希望扩展云服务的产品线’，这当然不错。但是技术实现上要面临很多挑战，而且人们通常不愿意花这份钱，”他说。

　 　 Przygode也提到，当企业今天选择了某个云服务，也同时拥有了惯性。例如，登陆亚马逊实例并在上边安装SQL Server，用户需要购买Amazon Relational Database Management Service，这在后端内置了冗余和高可用性。

　 　 “这对亚马逊是好事，因为一旦用户选择，就被锁定了，很难从中迁移出来。”Przygode说。

　 　 根据Haletky的说法，即使不考虑云之间的互兼容性，当分布式应用面临中断时，数据移动需要能够运行于物理上分散的其它地点，云应用在不同的服务供应商之间能否实现弹性也是个障碍。

　 　 可以在任何地方运行应用只是理想状态，要实现这种“需要数据无法自由移动，因为跨国数据的使用面临不同的法律法规的要求，”他说，“这只是愿景，但是我不认为在法规维持原状的前提下我们可以实现，即使（数据移动）只是在美国内部，您依然要面临不同的州和联邦法律要求。”

　 　 将来：对云企业级应用的展望

　 　 很多行业分析者都认为嵌入式的云弹性将成为业务连续性和容灾恢复（BC/DR）的工具之一，但是不会取代现在大家熟悉的DR方案。

　 　 “将会是应用去适应架构，应用应该虚拟化来满足松耦合世界的要求，“Forrester的Staten这样说。

　 　 其它的行业分析师预测，取代对应用的彻底更新，真正通用的将会是现代的DR方案，用于企业级方案的在云内部实现的DR，应该是混合了传统的静态容灾站点和几乎可以立即启用新资源的云模式两者的优点。

　 　 “我们很早就开始讨论的事情之一，就是称为‘长明灯’的概念，“位于Liberty Lake, Wash地区的云计算咨询商和系统集成商2nd Watch CEO Kris Bliesner这样说。

　 　 在“长明灯“DR模式下，IT企业应该把自己的系统扩展到亚马逊上，只是在灾难发生时把系统扩展到全尺寸大小就可以了。

　 　 “我们看到如果企业（RTO恢复时间目标）是三到四个小时，可以通过亚马逊，相比传统第二站点只需一部分的投入就可实现DR环境的搭建“Bliesner说，”账单到期即付以及亚马逊具备的多种功能使得这个概念的实现更为可行。”