如何SaaS化你的应用？.docxVIP

PAGE 1 PAGE 1 如何SaaS化你的应用？  本文将重点介绍如何在现有应用基础上创建(或转换)成SaaS。在这篇文章里，我们将指出SaaS的关键判别要素，以及当你在规划和架构你的软件时你该考虑哪些因素。  没有人否认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应用的客户变得更能接受你的产品。  细致的考虑安全架构：明显，当构建一个“共享托管”的应用时，安全是一个主要的考虑因素。在这里，“安全”指