没有人否认SaaS是一个非常热的话题。真的非常热。2010年，Gartner指出95%的组织将增长或者维持他们在SaaS上的投资。根据GigaOM的数据，SaaS公司的估值要远超过传统软件厂商的估值。当绝大多数的组织都在增加他们对SaaS的投入，很多组织也在考虑一种将他们现有应用以SaaS交付出来的模式。“SaaS你的应用”意味着什么呢?接下来的文章将重点介绍如何在现有应用基础上创建(或转换)成SaaS。在这篇文章里，我们将指出SaaS的关键判别要素，以及当你在规划和架构你的软件时你该考虑哪些因素。

　　ASP(应用托管)和SaaS的对比

　　“SaaS难道不是ASP模式下的产品和服务的重新包装吗?”对这个问题的回答显然是“肯定不是!”，但在对比多个打上“云”标签的产品时，你确实很容易弄混。公平的说，SaaS是对ASP引入的概念的扩展，但是却有着非常明显的差别。

　　我们快速过一遍两种交付模式的差别。

　　从本质上来说，ASP替客户运营软件环境，而SaaS则让客户通过可扩展、自服务的方式租用他们的服务。

　　SaaS你的应用——确认架构

　　在一个应用能够以SaaS方式交付之前，你必须评估它的架构是否可以支持。

　　无状态的Web服务器：为了能够清晰的支持横向扩展和增加新的机器，构建Web服务器的时候必须要求他们不能有任何本地的状态。Web服务器必须依仗一些共享的数据库来保存他们的状态。为了提供一个“面向云”的应用，如果你的Web服务器有本地的状态，你就不可能支持一个无缝的、自动的弹性扩展。

　　没有硬连接：如果你的应用服务器有一些硬连接(比如写死的IP地址)作为数据库或者服务器-服务器的连接方式，你在迁移应用到云端的时候肯定会遇到问题。这些问题不容易被发现，但是你务必要保证不同层之间都可以独立的扩展，而不需要拆开层之间的连接。

　　可扩展的数据模型：如果你已经预见了特定客户的定制化需求，这一点非常关键。是否允许用户扩展现有的数据对象、增加新的数据结构、以及施加唯一的验证逻辑?如果是这样，那么就需要在设计数据存储的时候设计一种方式，支持用户的扩展。

　　多租户的支持：这并不像想象中的那么直接。SaaS的一个关键原则是将多个用户，或者租户，放在同一个服务器或者软件实例里面。这种模型的好处是软件提供者可以获得高效的运营，因为他妈呢不再需要为每一个用户维护唯一的环境了。这一点同时意味着，多租户可以在你应用的各个层次都发生作用。三个渐进的阶段包括：

　　第一阶段：为每个客户提供唯一的Web应用和数据库。虽然底层的基础架构是租户之间共享的，也必须为每个客户分割出唯一的应用环境。这个分割的好处是实现租户之间的物理隔离(这在某些行业，如医疗行业，会很关键)，并且提供每个用户按照自己定义的日程来升级的可能。这个虽然会和ASP模型混在了一起，但是一个有着好的架构、高度自动化的应用提供方式的软件仍然可以让这种交付模型变得持久。

　　第二阶段：允许客户共享应用(版本)但是维护独立的数据库。在这个场景下，软件只需要安装一个版本，但是每个客户的配置信息提供了一个独立的数据库的连接方式。在这里，物理数据的分割仍然存在，仍然支持每用户加密或者直接数据库隧道，但是全部应用的维护变得更简单了。

　　最终：实现像Salesforce那样的模型，所有的租户共享相同的应用版本和数据库。数据在逻辑上实现隔离，但是共享同一套物理资源。

　　界面的配置：如果租用你软件的客户不需要做任何修改，那么显然没有必要暴露用户驱动的配置点。但是，如果你希望用户都以自服务的模式，获得扩展数据模型、更改外观、设置组织特定的流程、构建安全组和权限这方面的灵活性，那么如何设计你的应用来支持用户驱动的配置变化将变得非常关键。SaaS的一个关键原则是“自服务”，不需要用户致电服务提供商来实现任何更改。通过在你的架构中暴露一些可以支持的、用户驱动的配置变更，你可以让自服务变得更现实，进而让支持的成本变得更低。

　　API：如果你不能提供API，那么你就不能成为真正的云端应用。没有API的应用将逐步成为“烟囱”式的应用，变得更难集成或者以后更难管理。好的API的设计需要投入，但是却能够让SaaS应用的客户变得更能接受你的产品。

　　细致的考虑安全架构：显然，当构建一个“共享托管”的应用时，安全是一个主要的考虑因素。在这里，“安全”指的是包括“你的身份是如何鉴权的”、“你的身份是如何授权的”、“静态数据是如何加密的”、“传输数据是如何加密的”、“审计是如何实现的”乃至更多。理想情况下，你的应用允许通过SAML这样的标准机制实现SSO，来让用户只需要记住一个账户和密码就可以登录不同的SaaS系统。

　　同其它云平台的集成：虽然不是必需的，但云端应用如果能够拥抱其他的云平台，它们将变得更加强大。试想一下，如果你的SaaS应用能够和Google Docs或者Office365实现集成会怎样?如果你可以使用Facebook或者Twitter ID来实现身份的联合呢?

　　以上的列举还不够全面，但希望能够帮助你在将应用作为SaaS的模式提供出来之前，让你重新审视一下你的应用是否适合SaaS化。

　　SaaS你的应用：找到应用托管的环境

　　你已经有了一个SaaS友好的架构。恭喜你。你如何以一种最高可靠性以及最小支持代价的方式来部署呢?你需要找到一个成熟的IaaS提供商，并且提供一个有如下特性的、成熟和弹性的环境。

　　可测量的计费：按量使用是SaaS应用的关键特性，你需要确认你可以轻松的获取按月的使用量。虽然你可以制定一个简单的按用户收费的价格策略(放弃了对类似存储、带宽和CPU之类的资源计费)，你的托管商为你的SaaS提供一个清晰的资源成本结构还是显得很重要。

　　快速的水平/垂直扩展：对于特定的应用，你有时候会需要更多的处理能力，因此你会需要更多的RAM和CPU。但是记住，“云”和廉价硬件提供的横向扩展能力是紧密相关的。你SaaS应用底层的平台必须能够保证能够以自动和自服务的方式提供快速扩展的能力。

　　可访问基于Web的安装包：当需要扩展的时候，选择自动构建新服务器的方式，而不要通过现有应用的镜像来重新组合。如果你使用了VM快照，你将不得不在你需要他们的时候对他们进行升级和补丁，来保证他们可用。相反，如果你可以访问到应用的源码(或者Web安装包)，你可以使用很多工具来快速构建新的服务器。

　　积极的监控：为了能够支持海量的用户，你的应用需要能够对不可避免的、由于硬件和软件问题导致的故障进行快速响应。你的SaaS托管平台需要能够积极的监控到它们服务器的健康状况，不仅需要告诉你问题发生了，还需要能够根据既定的策略采取行动(比如重启服务器、让故障服务器下线、增加更多的服务器等)。

　　全球部署的选项：SaaS软件的一个价值就是它是在公共的互联网上运营。这意味着应用有可能被全球的用户访问。如果你的SaaS应用要考虑到支持全球的用户访问，那么就需要选择一个能够在全球的数据中心提供服务的托管商。

　　一键部署：一个云应用的架构可能并不简单。你的软件可能会需要很多个前端服务器，一个Web服务层，分布式的数据库，批量的任务处理系统，等等。如果可能，找到一个IaaS能够提供将解决方案做成模板，并且支持一键部署的。

　　健壮的备份和恢复选项：灾难总会发生。即使是最好的云环境，在未知问题的发生时，也会毁掉一整个数据中心。你需要保证你的应用数据能够及时(并且常规化)的保存在主数据中心之外的地点。容灾的规划是一个非常严谨的工作。理想状态下，你的托管商需要在这个领域有很多的经验，能够提供权威的帮助和工具来提供可靠的能力。

　　一个架构优秀的应用，如果陷在了一个不入流的托管环境里，会导致你的客户快速流失。除非你提供不可比拟的、必需的功能，否则你的客户会轻松的转投你竞争对手的怀抱。

　　SaaS你的应用—提供注册、管理和计费服务

　　一个好的应用，托管在一个世界级的基础架构上，剩下的就只是让客户来使用了。为了构建一个最小人工介入的、可持续服务的平台，你需要提供如下的功能：

　　注册页面：这个太显然不过了，但是你需要仔细的构建一种能够让客户快速使用起应用的方式。如果你的注册过程还需要让客户拨打一个电话，你已经错了。

　　管理控制台：前面我们提到了界面的价值，它能够允许用户对外观或者功能进行一定程度的更改。不应该让你的客户通过一系列脚本或者REST API来实现这些配置更改，而必须提供一系列让客户查看和编辑这些数据的方法。比如，一个好的管理控制台需要能够支持安全角色设定(用户创建)和计费服务。

　　数据导入/导出服务：恭喜你，有人决定使用你的SaaS产品了。他们如何将现有的数据导入进来?如果你说“手工录入吧”，你已经迈出了错误的一步。数据导入工具允许用户以一种正确的方式开始使用应用，并且创建了一种快速的数据集成的能力。你不仅需要提供简单的数据导入能力，还需要相同简单的数据导出应用的能力。虽然你很自然的希望锁住你的客户，但你让简单的集成变得更困难的同时也在伤害你的客户。

　　花一些时间来考虑如何让你的客户(或者潜在客户)更容易评估、购买和快速使用你的产品。