对SaaS公司来说，软件开发是一个完全不同的过程。产品周期更短，维护成本更低，使用的技术更时兴。现有的软件公司的开发团队更习惯于客户端-服务器(client/server)而不是更现代化的网络技术，这样一来公司就需要帮助他们的开发人员提高开发多租户的，以网络为中心的软件的能力。软件公司们需要抛开Flash，Silverlight或者WPF等传统技术，转而投入更新颖的(也许是不够成熟的)技术，例如HTML5，CSS3，JavaScript和jQuery。

架构真的真的非常重要

对SaaS产品来说，坏的软件架构比常规软件更加常见。使用支持一百个左右用户的专用服务器或虚拟机的套装软件，可能就没法很好的拓展到支持数百或者上千用户。即使横向扩展是可行的，对资源的不充分利用会使提供SaaS服务的成本超过预计的每月的经常性收入MRR的10%。开发者必须熟知，在缺乏恰当的优化的情况下，延迟(Latency)问题会导致公共云的表现非常差。由于许多用户的共享资源都处于同一个防火墙的保护下，安全性对于软件架构来说必须是最根本的。

需要做如此多的该死选择

现有的IDE(集成开发环境)下，最新的语言和工具可能不能很好地被支持——由于微软放弃了类似WPF这样的专利平台，Microsoft’s Visual Studio 2012 最终给HTML5提供了像样的支持;对Eclipse来说，情况依然很麻烦

选择使用哪种IaaS对开发SaaS有意义重大的影响。开发者必须按照配置，负载均衡和缩放(scaling)来选择特定的IaaS API来进行编程。由于对这些API没有一个固定标准，许多的选择是无法实现兼容的。亚马逊的AWS是行业领导者，但是OpenStack(由Rackspace使用NASA的技术)和CloudStack(使用来自Citrix的技术并购买了Cloud.com的域名)提供了AWS的IaaS专用API之外的开源选择。

通过提供诸如数据库和对Ruby或者Python等语言的支持，PaaS可以降低实现SaaS的复杂程度，并“屏蔽”了许多与SaaS应用程序管理部署和缩放相关的细节。不幸的是，PaaS比IaaS更缺乏标准化。对SaaS软件商来说，被锁定于特定的PaaS接口比特定的IaaS接口更让他们担忧。PaaS的开源标准更少。软件开发者必须要决定他们要适应一种PaaS平台，还是推出他们自己的偏底层的IaaS 栈(stack)的方案。

同时，开发者还要做出很多选择，实现与第三方工具集成，以提供诸如测试，计费，审计，多租户启用，以及系统监控领域等IaaS的产品的关键功能。对计费来说，类似Zuora或者Metanga的第三方工具包是能够获得的。RightScale或者类似产品提供了SaaS管理工具并提供了云资源服务商无关的IaaS接口。

一些代码和方案可以迁移到云端

对现存系统来说，有许多传统代码可以转换到SaaS上。代码为SaaS而进行转换，这一过程需要一定的时间，但是最终能够实现。对服务器代码来说，这可能需要更高效可扩展的代码，还需要更有效的基于租户之间更多资源共享的多租户架构。CorentTechnologies 提供Java和SaaS管理工具的中间件，可以协助把套装软件的代码转化成SaaS式的。Apprenda 为.NET的实现提供了PaaS实现方案，可以协助把现有代码转换用于开发新SaaS软件。

一些公司的SaaS产品和他们的套装软件使用同样的数据结构。如果数据库是很多租户共享的，那么在SaaS实现方案中很可能会包含租户id。像Sage这样的公司的套装软件和SaaS软件共享同一个数据库。其他的像Cherwell Software这样的公司允许户把同样的数据在SaaS模式和套装软件模式之间免费迁移。

SaaS在消灭丰富互联网应用程序（RIA）

世界级的SaaS软件将会消除对迅速落伍的丰富互联网应用程序框架的需求，包括Flash，Adobe(Apache)Flex，JavaFX，和WPF/Silverlight。特别指出，任何SaaS应用都不需要Java浏览器插件，也不需要面对频繁的更新需求、显著的安全风险、许多用户在无意间感染上的需要频繁更新桌面Java的可怕的Ask Toolbar垃圾软件。

这些庞大的插件增加了专用技术的数量，增加了安全风险，拖垮了浏览器。对这些RIA插件的升级需要用户干预，并使公司IT复杂化。HTML5高效的应对这些RIA专有框架，例如W3C加密媒体扩展下的HTML5视频元素和视频内容保护。

SaaS意味着桌面上的HTML5

大多数新的产品将会使用桌面HTML5技术，这一技术同样可以被SaaS所利用。HTML5能够提供RIA的功能，并且不需要传统插件。微软(Silverlight)和Adobe(Flash)放弃了他们对RIA的支持，青睐于HTML5.

许多软件公司并不情愿采用HTML5来开发他们的产品，这是因为市场上XP操作系统仍有高达40%的占有率，而XP系统并不支持能够兼容HTML5版本的IE浏览器(IE9及以上)。随着微软于2014年4月8日开始停止支持XP操作系统，那些使用不支持HTML5的微软操作平台的用户在急剧减少。大多数的流行浏览器(Chrome、Firefox和IE)已经使用了一种自动更新升级的模型，这一模型解决了长久以来支持旧版本浏览器的问题，并保证了遵循HTML5的新兴标准很快就会实现。

移动端可能需要本地应用

大多数的SaaS应用既需要桌面版又需要移动端版本。虽然HTML5成为极为普遍的桌面版软件，它在移动平台上的使用还是取决于应用的需求。对合适的开发平台的选择不是一成不变的——鉴于HTML5技术的不断成熟，开始支持更多的对用户体验的需求，并适用于移动端的硬件和API接口。关于如何在移动应用App和HTML之间做选择，在"从HTML5和本地移动应用之间选择"这篇文章(译者：敬请期待)里有深度讲解。

SaaS意味着公开的API（应用程序接口）

SaaS的架构包括开发一个快速安全易用的数据服务层，这个是一个公开的API的基础。SaaS产品应该预留有接口，这些接口允许VAR或者第三方开发者开发额外功能，与其他软件包——特别是数据分析和大数据应用——整合，并为移动应用提供服务。SaaS应用不像套装应用，客户不能够从一台他们控制的机器上直接接触数据——唯一接触数据的方法是通过供应商提供的一系列必要的API。

一条告诫：公开的API必须是一致的，可靠的和标准化的。一旦公开，这些API将会保留并且不会在该软件的未来版本中取消。这需要在架构过程中对将要公开的API深思熟虑，以保证他们是可扩展的。

SaaS意味着多租户

服务器端的开发有一项明确的新要求。不同于套装软件只需要支持单一租户，SaaS条件下许多租户共享同样的(虚拟)服务器，因而对SaaS的表现的要求会更高。多租户分享数据库要求额外的安全措施以从逻辑上把来自同一服务器上的不同租户的数据隔离开。根据客户的安全需求，SaaS软件可以在多租户之间共享应用服务器，但是允许互相之间没有数据交集的特定租户有专门的数据储存空间。多租户共享有三种模型：单个用户一套数据库;单用户一套数据库结构(shema);以及一个完全共享的数据库，在这一数据库中每个用户的数据按照租户ID来隔离储存于物理存储空间里。Corent Technologies 是一项中间件产品，它支持以上全部三种租赁模式。

SaaS意味着无状态的架构

除了多租户以外，SaaS系统的架构应该是无状态的。现代软件系统通过RESTful接口来展现其功能性——为了表现最佳的性能，可扩展性，弹性和容错能力，这些服务应当是完全无状态的。如果服务器端的应用程序是无状态的，那么在使用高峰的时候，它随时可以创造更多的服务器实例(machineinstance)，相应的在利用率降低的时候可以减少数量，藉此来释放虚拟机资源。

无状态设计需要类似AWS 简单存储服务 (Simple Storage Service, 或S3)，AWS 弹性区块存储(Elastic Block Storage, 或EBS)或者Rackspace’s 云端块存储(Cloud Block Storage)——而不储存于任何单个服务器。服务器通过(RESTful)接口，采用请求处理机制(基于服务器的)来进行解耦。这是一个典型的三层架构。这要求SaaS公司对用户请求的处理必须借助IaaS供应商的负载均衡来实现，而负载均衡要能够为任何用户提供可扩展的服务，就要求SaaS应用程序必须是无状态的。由于无状态的服务器实例需要反复创建和运行，数据只能存储在共享存储上，而不可能处于任何一个单一的服务器实例上。在服务器崩溃的时候，管理服务器实例的软件——例如亚马逊的ElasticBeanstalk——将会转入另外一个实例来代替已经崩溃的那个服务器实例，并随时随地获取存储在云端各处的数据。当处理能力过剩时，那些多余的虚拟服务器将会被释放，并且客户端的应用程序将会连接到另一个备用服务器实例来完成余下的交互。

无状态的架构并不是SaaS应用程序的必要条件，但是是让SaaS应用程序实现成本最小化、性能最优化、可靠性最大化所必备的。

SaaS需要制定数据分析的计划

大数据不能够忽视数据的本地化问题(locality)。将PB级别的数据转移到云端，并用Hadoop来处理非结构化数据是有问题的。不幸的是，公共云架构的带宽至今不支持在不需要考虑性能后果前提下的虚拟化存储。SaaS系统所产生TB级别的数据在进入数据分析进程时，必须保证计算和数据就近原则，即这些数据和大数据分析系统必须在同一个地方。

SaaS意味着频繁而非颠覆性的升级

SaaS公司能够迅速的发布新功能，同时无需担忧大量发布新版本所带来的大量支持服务和漏洞修复。由于不需要向市场大量释放不同版本的软件，SaaS公司能够用最小的成本来维护旧版本，所以能专注于创造新发明。像NetSuite和Salesforce这样的公司同时支持两个版本的软件，并且他们的客户可以在短短6到12周内从旧版本升级到新版本。此外，我们无需检测不同版本的数据库、操作系统或者不同客户站点上的服务器。一个典型的例子是，一个只有两到三个需要支持的版本，并且每个版本都只有单一的运行环境。这样的软件需要的检测数量远远少于有多个操作环境的系统。

SaaS公司花费更多的时间在创新而不是软件维护上。对SaaS公司和他们的客户来说这是一个巨大的优势。相比于套装软件用户。他们可以更迅速的把创新落在实处。套装软件的客户无法承受每年无数次颠覆性的升级。

SaaS公司需要额外小心，不要由于软件的倒退或者打破客户定制而破坏客户的工作环境，也不要任意改变用户界面，迫使客户增加额外的训练和适应时间。鉴于任何计划外的当机都都可能影响成千上万的客户，软件的正常运行变得非常关键。SaaS软件的架构必须能够有极强的容错能力，并且能够很快的从故障中恢复正常。

由于需要在不干扰正常服务的情况下完成升级，或者至少是能够在很短的时间内完成，这一过程变得更加复杂。这排除了在升级过程中可能出现的冗长操作，例如数据库重建。SaaS云模型的优势在于新版本可以在转移用户之前在一个全新的的运行环境中完整运行。迁移用户到新机器上运行新版本的进程是很快的。相比之下套装软件需要在同一台机器上升级软件运行环境(支持软件可能同样需要升级)，这一过程花费的时间就会长很多。

SaaS公司更倾向于采用NoSQL数据管理软件，例如MongoDB。因为它不依赖于固定的架构，而这样的架构若想要在短期内改变是很不现实的(同样不现实的是提高性能降低数据管理成本)。

一些SaaS公司，例如NetSuite在几周之内支持两个版本，并允许他们的客户在这几周内自主选择转换时间。然而大多数SaaS公司会同时为他们的所有客户进行升级。

SaaS需要高可靠性和冗余性

连续性要求是一个关键的SLA指标，需要通过有着全面的冗余性以及失效切换设计的容错架构来实现。IaaS平台并不像大型的、昂贵的IT系统一样有着良好的可靠性，因此对于可靠性的考虑主要落在了SaaS本身的设计上。SaaS架构必须保证有良好设计的软件的失效倒换(即高可靠性，H/A)能力，并保证从数据丢失或者崩溃中恢复的时间是最短的。服务器实例的失效、网络、软件、数据可用性，或者数据的完整性，都有可能发生。软件架构必须能够预测到失效，并且在这些失效场合下都能够在不影响客户实际使用的前提下实现恢复。从失效中恢复并且能够成功的访问到数据，要求必须能够支持冗余的数据。这个冗余必须由IaaS或者数据库平台来提供。比方说，OpenStack对象存储(Swift)能够提供数据的三副本，来保证数据的可用性。数据的崩溃可能是最苦难的，需要一种持续的、能够从前一个已知状态中恢复的能力。

SaaS需要满足安全和合规性

SaaS供应商必须为产品安全负责。这也是套装软件供应商的头等大事。按照Gartner的说法，大多数的安全漏洞发生在应用层面。

由于多租户在不同的场合(有时候是未知场合)在虚拟环境下运行程序，法规和审计问题就变得更复杂了。开发者需要未作常见的运行错误设计代码，例如跨站脚本和SQL注入，它是蠕虫能够攻击数据驱动程序。

SaaS的安全应当是开发过程的一部分，而不是安全漏洞发生之后的补救。由于大多数的漏洞没有被发现，检测和清除并不是可行的战略。市场上有许多的安全框架，下图中所展示的是微软安全开发生命周期：

SaaS需要数据本地性管理

越来越多的国家通过了限制数据移动和存储的法律。套装软件把有关数据存放位置的大多数问题留给了消费者。许多国家有严厉的法律规定数据可以在哪里存储和如何跨国存储。这样一来，遵守所在国法律法规就成为不仅仅是开发者，而且还是SaaS软件操作管理团队的重要议题。

SaaS需要对数据监管的考虑

SaaS最重要的一点在于，现在是SaaS供应商，而不是IT组织需要为客户的数据负责。精明的公司都理解他们的数据是一笔海量的信息资产，而公司需要从这笔信息资产中发掘出最大的战略价值——现在数据的物理存储位于SaaS供应商的服务器上，但是客户公司仍然必须保证他们的数据符合他们自己的监管政策。除了上文所提及的数据安全和数据本地化相关的监管问题，软件开发者必须允许客户实施IT机构的数据管理政策。这包括：客户的所有数据随时都要处于可导出的状态，这样一来数据可以与客户公司的其他数据一起发挥效用;保证客户可以把数据迁移到另一家供应商而不必担心被这一家供应商锁定。其他的数据管理政策包括数据质量的管理，数据处理流程，以及数据风险管理，都需要SaaS供应商提供。。

SaaS需要更全面的测试

大多数多租户SaaS系统的故障都会影响到全部用户。故障发生更广泛，更有破坏力同时也更公开化。测试必须要保证多用户在共享环境下操作时不会互相干扰或降低安全性。

Netflix开发了一套名叫“Chaos Monkey”的流氓软件，它可以随机破坏进程，Netflix用它来测试以确保业务没有中断。在FieldCentrix，我们使用早期无线数据信息，我们开发了“可恶协议模块(Nasty Protocol Module)”，它可以制造网络错误，数据包丢失和额外的数据包延迟。利用这个模块我们可以保证我们的软件足以应对各种网络错误。对SaaS系统的设计和测试必须保证它能够在一个其基础设施可能出错的环境下正常运行。

SaaS操作给软件开发提出了新要求

SaaS软件的其他独特需求是，新租户需要进行的培训过程和对租户使用进行计费。虽然有第三方软件包能够实现上述功能，但是这些功能需要被加入到软件架构里。

SaaS公司现在负责软件的运营，例如对性能，错误探查，入侵探查，修复，安全性，审计流数据等方面的系统监测。从前，这些“DevOps”职能是属于客户公司的IT部门的，而现在这些成了SaaS公司，或者说无条件的是SaaS公司的开发部门的职责。NetSuite公司没有独立的DevOps部门，他们的软件开发人员同时也在运行着服务。无论如何，软件开发部门现在越来越紧密的与软件运营产生了联系。

为了实现均衡负载、按需求调配额外资源，SaaS软件必须与IaaS/PaaS的功能磨合良好。SaaS公司能够从IaaS供应商、PaaS供应商和第三方工具那里获得极大的帮助。但是这些功能需要被整合到SaaS软件内。SaaS供应商的责任是保证他们的产品能够完全满足他们的客户伙伴的需求。

SaaS需要软件开发方法上的“最佳实践”

SaaS产品更新换代速度极快，频频释放引人注目的新功能保证了SaaS产品始终“新鲜”。这要求开发部门有能力进行高质量高速度的版本更新。这促使开发部门趋向灵活的开发方法，抛弃面向特定目的(ad-hoc)或者“瀑布式”的开发方式。

“连续集成”(CI)方法非常适合SaaS的开发环境。它可以通过保证软件随时处于可发布状态，来确保能够频繁向客户释放软件新版本。不像典型的套装软件那样，在发布周期有一到三年的时间，典型的SaaS公司只有三个月的发布周期，这样一来就没有了“test-in”时间。

SaaS部门必须为他们的技能投资

SaaS部门必须保证为他们的开发团队投资以获得开发SaaS的技术，并取得足够的资源来保证这些技术有用武之地。并不是每个团队和编程者都能从大型计算机转到迷你计算机或者从迷你计算机到网络运算。同样，并不是每个人都能利用软件开发工具和经验成功达到SaaS战略的要求。对开发团队的领导者来说，最重要的是致力于SaaS的技术实现并为技术成功应用指出方向。

SaaS开发是完全不同的

SaaS产品不需要等到RIA程序框架的彻底消亡;基于HTML5的出色用户体验，公开的应用程序接口，高频的版本更新，对第三方软件整合的支持，对分析的支持和对移动端应用的支持——很少有成功的SaaS公司的产品缺少以上这些特质。很多公司都从转向SaaS业务而受益。至关重要的是开发部门有一个计划来保证他们的SaaS产品是“世界级”的——创新性、稳健、可扩展、有弹性、可集成再加上舒适的用户体验。

SaaS应用程序需要使用这些开发的最佳实践。它们还需要满足那些让他们适合部署在企业中的特点，包括安全性、保密性、数据治理、互通性、性能、有效性、和符合法规，正如云战略的这篇文章所描述的：开发企业级SaaS应用程序的要求