第三方应用和SaaS优势

    软件即服务（SaaS）应用基于提供商自己的自定制软件，无法迁移，除非提供商设立了这样的选项，不过这基本上就是天方夜谭。如果企业关注于迁移，选择SaaS应首先关注那些将自己的应用托管在第三方软件上的提供商，而不是自主开发的提供商。软件开发者可能与多个提供商协定托管，因此这种形式的SaaS的迁移相对容易。也可能是为本地设施购买了一个软件副本，因此在提供商遭遇失败或者软件支持缺失时，“自托管”就是一种选择。

    “迁移SaaS”的最佳来源也是主要的提供商所提供的应用，比如微软、SAP、甲骨文等。几乎所有的厂商都提供SaaS，同第三方SaaS托管签订协议，或者自托管。关键在于不管托管常规应用软件构建起来的SaaS服务在哪里，有多种提供商的产品可用都是受欢迎的选择。专业厂商提供了垂直市场打包服务，不太可能吸引多种SaaS托管提供商的目光，因此就需要不同的方法。

    IaaS取代SaaS优缺点

    SaaS迁移的第二个选择就是“自SaaS（self SaaS）”，软件包许可证，以及云端基础架构即服务（IaaS）托管产品，都似乎为SaaS创造了点什么。这种方法的价值在于最终服务可以和机器镜像一样可移植，为托管增加了更具竞争力的选择。不好的方面在于，这种方法不像是SaaS，从操作系统到软件，自SaaS仍旧导致了用户的硬件成本，以及对于整个软件堆栈的支持。这意味着自SaaS对于已定的应用，能够创造出一个云版本，但是并不会得到SaaS的全部好处。

    DIY SaaS迁移

    这两种选择并不能完全解决SaaS的迁移问题。很多用户正在对SaaS应用和本地应用或者云软件进行整合，构造一种编制化多组件应用。比如，有一家公司将Salesforce CRM服务同SaaS托管的统一通信和协作结合在一起，构造了一个销售支持应用。我们有两个SaaS组件，如果两个都要改变，整个销售支持应用就会有问题。

    完整SaaS应用迁移计划制定

    这个问题的一个解决方案就是合理选择应用整合工具，用来构建更高水平的应用。很多应用前端工具（比如，思杰），可以让用户为低水平应用自定制界面，来提供数据和流程。为一个组件变更SaaS提供商意味着改变了整合定义，但是并不是整个应用。对于这种方法，SaaS服务能够提供灵活的应用程序接口（API）很重要，这样就可以轻松整合。比如，RESTful API通常就比面向服务架构/简单对象访问协议API更易于整合。

    所有的方法都失败的情况下，SaaS整合和迁移问题可以通过自定制基于SaaS API的应用来解决。SaaS API对于开发者来说就像是一种分布式应用组件，因此可以构建到一个程序中。为了让这个过程远离另一个迁移风险，最佳实践就是在本地类/对象中，将访问封装到所有的SaaS服务API中，引用一个新的对象来访问这个服务。某种程度上来说，如果必须改变SaaS提供商，本地对象可以进行修复，来适应新提供商的API。

    SaaS厂商培育迁移市场？

    对于SaaS迁移而言，所有的整合和封装战略都依赖于竞争SaaS提供商已定应用之间的功能一致性。显然，如果一个提供商的统一通信/协作服务提供了视频会议，其他的提供商没有，再多的接口整合也无法弥补功能的缺失。并不是所有的功能区别点都是显著的，因此在承诺SaaS整合或者封装项目之前，要有一个可用服务提供商清单，确保你构建的应用的功能是一种通用功能。

    因为SaaS服务取代了最大量的平台和基础架构组件，它们提供了最大化的好处，也更易于为非技术人员所采用。

    用SaaS调节迁移问题是合理的，但是用户要知道这些调整基本上都是要增加项目成本的，减少整合的SaaS提供商，这些风险都隐藏在SaaS成本节省之下。这些劣势需要在采用SaaS之前作出权衡，要不然处理起来可能比灾难还麻烦。

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。