最近公司要求写了一篇文档，贴出来留存。

预计到2017年，新的商业软件的购买行为，有大约26.2%是提供服务软件的方式实现的，并且SaaS交付模式将占据18%的软件市场和将近20%的APP市场。”（IDC 2013年12月《全球SaaS及云软件2013年－2017年预测和2012年供应商市场份额报告》，文档编号：245084）在这份报告描绘宏伟蓝图中的2017年即将到来之际，我们看到的是中国企业级SaaS云服务市场的风起云涌。AWS一直作为云时代的领军人物，一直在全球作为各国SaaS云服务的基础平台，为数量众多的SaaS合作伙伴提供了稳定的基础架构和完善的生态系统。

AWS作为企业级SaaS云服务最为理想的基础架构平台并不是偶然的，SaaS云服务之所以成为越来越受青睐的软件交付方式，按价值定价、用户自助服务、共享基础架构的多租户、弹性灵活的使用方式以及可以快速服务全球等特点无疑是最为重要的原因。而AWS云服务作为基础架构的特点又恰恰迎合和满足了SaaS云服务的这些要求。例如AWS云具有按使用量付费、资源按需分配、高度可扩展性和持久性、自动弹性伸缩和脚本化资源部署、全球覆盖的基础架构设施等都为SaaS云服务提供了良好基础架构的支撑。

基于AWS平台的SaaS云服务的转型成功案例在全球都有分布，并有多种类型的SaaS合作伙伴提供各种类型的企业级软件。这些服务涵盖了企业软件服务，例如企业常用的客户关系管理（CRM）、企业资产管理（EAM）、企业资源规划（ERP）等软件；商业流程管理服务是以客户为中心的业务流程管理软件；内容管理服务为企业提供内部门户和内容整合的软件服务；数据分析服务基于AWS提供大数据分析服务的平台。同时这些SaaS合作伙伴也涵盖了各种类型，包括了由传统成功转型的、扩展业务发展而来的、通过改革创新而来的以及初创企业等等。

其中传统的ERP厂商Infor的成功的SaaS转型让人尤为印象深刻，Infor公司利用AWS平台来部署Infor的产品CloudSuite，而不是完全由Infor自己打造ERP解决方案的基础架构，SaaS合作伙伴要专注于特定行业，打造具有行业特点的SaaS服务，解决这些行业企业解决方案最后一公里的问题，让客户在AWS云计算的基础上拥有完整的端到端的解决方案，避免了定制化的需求。 随着Infor的客户部署深度的、集成的、庞大的解决方案套件，为了推动在企业软件领域的创新，需要Infor团队快速的推出一个强大，可扩展，高效的架构SaaS服务CloudSuites，而AWS平台提供了理想的选择。

AWS在总结多年服务SaaS合作伙伴基础上推出多项SaaS合作伙伴支持计划，对处于不同的阶段及APN层级的SaaS合作伙伴都有相应的支持资源的投入。

作为ISV合作伙伴要推出自己的SaaS服务永远都不会是一个轻松的旅程，作为SaaS服务平台的基础架构提供者，对于各类的SaaS合作伙伴基于AWS平台可以按照自己的实际需求选择相应架构模式，下面我们将结合基于AWS基础架构的SaaS化的最佳实践对于三种模式的架构作以一一说明。

第一种模式是最为简单直接的“资源隔离”模式。这种模式可以将合作伙伴原来的产品快速的构建成SaaS架构，并在一定程度上获得SaaS模式带来的益处。这种模式需要为每个租户部署整套的应用堆栈，对于每个租户AWS的资源例如EC2实例、ELB和RDS等都是相互独立的，只需要将合作伙伴的原有私有化部署的产品“铲车”式迁移到云端，并配合一定的自动化运维（DevOps）的开发就可以实现。但是这种模式虽然在一定程度上带来SaaS模式的益处，但实际上仍然还是存在各个租户之间基础架构相对封闭无法共享的问题，这种模式只是在某个租户内部实现了资源的弹性扩张和收缩，因此这种架构准确的来说不是一个现代的云架构模式。由于这种模式对于传统的独立软件开发商产品来说是SaaS化最为简单也容易实现，同时能够让传统的软件实现基于云的扩展，这也往往是传统私有化部署产品SaaS化的第一步。

基于AWS的SaaS第二种推荐模式是“容器化”模式，这种模式是在“资源隔离”模式的基础上发展而来，使用目前业界应用越来越广的“容器”技术对资源进行隔离，而不是通过EC2虚拟化的方式对资源进行隔离。现在流行的“容器”技术对于计算资源的隔离方式提供了新的选择，有很多的ISV已经开始对自己的产品进行容器化的改造，将自己产品的一些服务“微服务”化，进行了拆分和Docker化的发布。由于AWS本身对于容器技术的基础型支撑非常完备，因此我们也推荐合作伙伴通过“容器化”的模式进行SaaS化的改造。采用了“容器化”的模式更容易利用目前Docker的生态，使用更多的技术实现DevOps、持续集成和持续部署等现代化改造。AWS的Amazon EC2 Container Service（Amazon ECS）是高扩展性、快速的管理容器集群的服务，可以运行、停止和管理在EC2实例上Docker容器集群，通过简单的API调用启动和停止基于容器的应用，允许通过集中的服务读取集群的状态并与很多Amazon EC2的功能进行集成。合作伙伴可以将自己已经经过容器化改造的服务快速的部署到Amazon ECS中进行集群管理，并通过容器自身的隔离机制实现各个租户资源的隔离。“容器化”的模式可以同样在一定程度上实现了“资源共享”的目的，实现了租户之间“进程”级的资源隔离，并将现代化的微服务的概念引入到原有的技术架构中，但同样也面临着各种挑战，特别是新引入进来的容器技术本身就会为变更管理、集群管理等之前的工作内容有非常大的变化同时复杂性也会大大增加。

第三种模式也是SaaS模式的终极目标“共享架构”模式。这种模式是所有SaaS合作伙伴的最终的技术架构演进的目的地，所有的租户的资源都是共享的。在这种模式下可以大量应用现代的架构模式构架新的产品或者改造现有的产品，使用更多的AWS技术的最佳实践帮助合作伙伴实现架构、开发、运维等等方面的诉求。“共享架构”模式将更为集约的使用AWS资源，同时方便的进行流量分发、变更管理、持续集成和部署等操作，是最为适合SaaS大部分业务场景的技术架构。

以上三种模式是合作伙伴产品SaaS化不断演进过程的各个阶段所采用不同的架构模式的体现，通常的演进路径是：资源隔离模式到容器化模式再到共享架构模式。在这里需要指出的是所谓的“架构模式”不是绝对的，或者是说上面三种架构模式不是互相排斥的。因为三种模式各自有自己的优缺点，需要结合到合作伙伴自己产品的架构中灵活使用，特别是在一个大型产品架构中三种架构模式过渡性共存，甚至永久性共存的情况都会大量的存在。

除了以上提到的AWS对于SaaS化合作伙伴产品的最佳架构模式以外，AWS还对SaaS解决方案的设计提供了一些最佳实践。

第一个最佳实践就是将平台化的功能隔离出来，SaaS产品的更新速度是非常快的，但是我们仍然能够总结出一些核心的功能是基本不变或者能够在很多其他新的产品模块中重用的，要将这部分功能分离出来进行平台化改造以服务于更多的其它功能，将这些功能平台化以后也会降低整个系统的耦合性从而支撑更多的SaaS应用的功能。对通用功能的平台服务隔离可以更好的调优和独立扩展，同时重用核心服务并结合应用框架的使用会极大提升应用开发的效率。

第二个最佳实践是优化成本和性能，在传统的技术架构下这两者之间往往需要进行一定的平衡，而在AWS云的架构下的SaaS服务云模式下往往可以实现鱼与熊掌兼得。在每个架构层次实现弹性的横向扩展可以让我们实现按使用量付费的模式，而不需要为了获得强大的性能而提前付出大量的资源成本，同时我们在SaaS的AWS架构下可以使用更小的、平行的资源单位进行扩展而更为贴近SaaS环境下的实际资源需求，在合适的场景下尽可能的采用完全由AWS托管的服务（比如Amazon DynamoDB等）来降低SaaS合作伙伴的运维成本并提升效率。

第三个最佳实践是针对SaaS解决方案设计的，首先对于多租户的设计要针对SaaS应用自身的特点来进行规划，总体的设计原则是系统会有多个帐号，而一个帐号会对应多个用户，一个用户又会对应多个角色；其次是对于系统处理各种请求时要按照优先级进行分级管理，在通过使用AWS各种服务如SQS、SWF等对系统进行解偶后，对AWS资源集约使用的前提下，对请求分优先级处理会极大提升SaaS架构的处理能力和稳定性；接下来要对监控加大投入力度，借助AWS CloudWatch等监控服务，通过粒度更细的监控来控制分布式资源更为有效的弹性伸缩；最后合作伙伴还需要非常了解SaaS应用架构中所有数据的生命周期以及在在各个周期内数据的特点，依据这些特点为数据在AWS的服务中选择正确恰当的存储方式以优化技术架构及降低成本。

第四个最佳实践是收集一切可以收集的数据并从这些数据中挖掘出价值。AWS基础架构自身通过CloudWatch服务就可以收集粒度非常细的指标，同时SaaS应用自身也会产生大量日志及指标数据，这些数据和指标不但要密切监控同时也要全量的妥善保存起来，以便后续的大数据挖掘工作。不要担心在传统模式下数据存储的高昂成本，在AWS云的架构模式下有大量诸如Amazon S3、Glacier等成本极低的存储方式。通过分析这些大量的数据来了解你SaaS服务的客户，能够为业务带来巨大的价值，例如实时自动调整用户体验及与之相关的基础架构，通过使用量的分析改进业务模型等等。

上文通过结合AWS基础架构的特点分析了合作伙伴SaaS服务构建的推荐技术架构以及最佳实践，我们也初步了解了在AWS基础架构上搭建SaaS服务的优势。如果合作伙伴想基于AWS构建企业级SaaS服务云， 对于还没有加入APN的，现在就可以通过登陆APN来进行注册，并且申请加入SaaS合作伙伴计划，通过观看APN的SaaS合作伙伴系列视频了解更详细的内容，联系你的合作伙伴拓展经理（PDM）来获得进一步的帮助。