PaaS的BC/DR的优点以及常用方式

　PaaS有业务连续性和灾难恢复功能，从持续运行角度来看，PaaS将是一个有价值的选择。本文将介绍PaaS的BC/DR的有点以及常用方式。
　　
　　我认为PaaS是Web应用程序开发的未来趋势。传统开发平台已跟不上时代。PaaS有很高的效率，非常完善的功能和很少的成本等优势，这让PaaS如何不成为主要部署方法？
　　PaaS最大的卖点就是BC/DR（业务连续性和灾难恢复）。你不能否认一个可靠的BC/DR设计的重要性。即使是有适度地部署且规模较小的组织，也需要确认它们的应用程序可用并提供尽可能接近100%的时间可用。这也是基于Web的应用程序迁移的一个主要原因：这样用户在世界上任何一个地方以及各种条件下，都可以访问关键任务软件。
　　PaaS有几个不同的方式来完善BC/DR计划。首先也是最重要的是，简单地在这些组织提供的基础设施和平台上部署软件，这可能是一个重要步骤，就可以建立一个本地部署或者自我管理的部署。类似Google和Amazon这样的企业拥有巨额预算来维护他们的平台，给他们提供SLAs超过99.5%正常运行时间的能力。大多数企业则没有这样的资源。
　　最明显的是租户共享基础设施，即他们自己的公司主机。对Google来说，你是在利用他们使用相同基础设施来部署自己的产品。如果你在Microsoft的PaaS上开发，你可以利用他们软件的底层结构，像Bing 和 XBox Live.。当然如果这些服务足够好，你也应该相信它也可以为你的应用程序提供足够好的服务。
　　但是完善的基础设施和服务不是你所需的全部。有时候突发灾难，地震、飓风和其他自然灾害导致的停电并让整个数据中心脱机。世界上所有的钱和资源都无法拯救因意外而中断的基础设施。
　　不过没关系，因为PaaS解决方案为您的软件提供简单的全球分布。你可以将应用程序部署在世界各地多个位置，轻松设置负载均衡，例如Microsoft的Traffic Manager，在这些网站之间分配流量或因故障转移流量。一个中心脱机并不意味着你的服务停机，如果你利用一个高可用性和永久存储的后端应用程序，例如DynamoDB或者Google Cloud SQL，你可以确保没有宕机和数据丢失。
　　动态可拓展性是一大特点，对PaaS来说更加容易。有时候可用性受到限制并不是因为故障或者灾害，而只是由于流量容量和响应性。对于一个面向公众的应用程序来说，没什么比速度慢或者链接反应迟钝更糟糕了。人气是一个应用程序的生存关键因素。利用缩放选项，大多数PaaS可以提高你的应用程序的实例数量，确保流量使用高峰期不会降低你的服务。动态扩展可以根据你已创建的规则，瞬间作出反应且无需你的干预。
　　在一个PaaS平台上迁移现有的开发或者规划一个新的解决方案，似乎是一个艰巨任务的开始。有许多缓冲方法来解决，但PaaS尽全力解决前期问题。你可以放心，PaaS有内置的BC/DR特性，你的应用程序或者服务的业务连续性将是小菜一碟