从我离开公司算起，整整在国内 SaaS 行业待了5年，从2017年开始几乎每年都被称为“SaaS元年”，但是中国的 salesforce 一直都没有出现。究其原因，内因外因皆有，每个人的答案也不尽相同。所以我想从我的角度去聊一聊 SaaS 到底是在做什么。
什么是SaaS
Software as a Service 是 SaaS 的全称，软件即服务，如果从字面去理解，我们日常使用的互联网网站都是SaaS，豆瓣上你可以建立豆瓣小站，淘宝上可以开店卖货，B站上可以建立自己的频道上传视频内容。这些软件无时不刻不在服务于我们的工作和生活，甚至是是我们的谋生手段。国内 C 端的 SaaS 其实已经非常成熟了，他们跟 salesforce 或 workday 的不同就是服务对象主要是个人而不是企业，另一个很显著但又不易察觉的差别在于前者并不通过软件本身谋利，但后者的主要营收来源就是软件 license 费用。
企业 SaaS 也许是更准确的叫法，是从过去需要本地磁盘安装的企业软件套件发展而来的。最好的一个例子就是 Office，过去的 Office 是需要磁盘安装的，并且每台机器都要输入不同的序列号去激活。Office365（在线版）就是 Office 的 SaaS 演化版，打开浏览器即可使用，无需安装，付费也不是按照设备数而是按时间订阅，一般是一年一付。
SaaS 的优势是什么
我过去在 SAP 工作，SAP 一个模块的安装步骤几乎就能出一本手册，从初始安装到运维排障。当一家企业订购了 SAP 软件之后，就需要售后工程师去现场安装，还需要顾问去实施，这里面涉及到大量的人力成本。而且这个成本是无法摊销的，客户数越多成本也越高，几乎是线性增长。
那么 SaaS 的不同就在于当一家企业订购软件时，只需要在线开通一个账号，经过简单配置即可使用，整个过程就好像在淘宝开店一样（这个模式就孕育了最初的有赞）。对于软件提供商来说，几乎什么都没做，也就是数据库里多了几行数据。这样一来跟传统企业套件相比，上线实施的边际成本基本就是零，这也是 SaaS 最大的魅力。客户越多，客单成本越低。
SaaS 的劣势是什么
事情总是两面的，有优势就一定会有劣势。SaaS 的最大劣势或者说难点在于无法针对单一客户提供最独特的服务，即定制服务。基本上来说，一个 SaaS 服务商提供给这个平台上所有客户的服务都是一样的，功能是一样的，连 bug 也是一样的。这一点有没有办法优化呢？答案是肯定的。可以通过功能开关来针对特定客户开放特定功能，比如付费的高级用户会有免费用户看不到的功能。但是基本上来说这种程度的定制是非常暴力的，就是开和关的二元实现。有没有办法更进一步呢？答案是也有。可以增加更复杂的配置项，比如让用户自己定义自己商品的属性，卖汽车的商品属性可能有大几十种，什么排量，排放标准等等，而卖美妆的商品属性有色号等等，再比如网店的装饰图片，排版等等，这些都由客户自己定义。这样从某种程度上实现了代码层之上的定制化。但是这里仍然会存在问题，总会有个想不到的地方客户想改，但恰好又没有作为配置选项的啊，如果是传统软件，那直接一把梭上去改掉就完了，但到了 SaaS 由于改动会影响所有用户的使用，是不是要改，怎么改就会变成需要深入思考的问题了。站在甲方角度这种思考带来的就是效率的低下，可能一个简单的改动就要排期数月。国内的企业软件市场定制需求很多，而且不同企业之间的差异也很大，SaaS 厂商想要一套软件满足所有企业的需求，真的是一件非常非常难的事情。
SaaS 的基本技术素养
综合优势和劣势，如何从技术上去评判一个 web 应用是不是 SaaS，我觉得至少有两点
- 多租户（multitenancy），租户就可以理解成公司，公司之下才是用户，例如张三和李四都是ABC公司的员工，那么他们俩使用自己的用户账户登录后都是只能看到ABC公司的数据。这里的ABC公司就是一个租户。多租户在逻辑上隔离的，租户之间数据互相不可见。但在物理上是共享的，共享数据库，共享服务器。如果一个 SaaS 提供商在新增租户以后，要去装个新的数据库，那么就不是标准意义上的 SaaS 系统了。
- 扩展性，为了满足不同租户的个性化需求，SaaS 往往需要提供相对复杂的功能配置项供租户自己设置。当这种配置项膨胀到一定程度就会需要引入专门的顾问去帮客户做上线前的实施工作。而且很重要的一点是这种扩展性是必须在 runtime 阶段就可即时生效的。如果说每次改动都要部署，停机再发布，那么一个租户的的需求就会导致整个系统的使用受到冲击，这显然是无法接受的。扩展性可以体现在配置项上，也可以是更复杂的嵌入式脚本，甚至是开放平台，即应用市场。
国内 SaaS 困境
除了上述提及的定制化难的劣势，在国内其实还有一个不可避开的话题就是数据安全性。
国外企业对于数据上云的接受程度相对较高，但国内企业绝大多数希望软件只能运行在自己的公司内网，退一步说至少也要保证数据是在自己内网的数据库里。所以这就带来一个软件私有化的问题，其实我一直在思考但也没能想清楚的一点就是“私有化的 SaaS 还是 SaaS 吗？”。一旦私有化其实就在某种程度上推翻了之前所说的优势，回到了企业套件逐个公司安装的老路。由于经历了无数私有化项目，我可以罗列出好几个私有化的痛点
- 安装成本，网络拓扑（公私网DMZ等）都需要满足甲方要求，并且并不是所有甲方的要求都是一样的。
- 安全扫描修复成本，SaaS 公司云上的软件肯定是经过各种安全软件扫描并经过渗透测试的，但是一旦涉及到私有化，甲方肯定会按照自己公司的软件安全要求重新进行检测，这里面差异就会很大，各家的安全扫描软件还有安全标准都不不同，所以结果也会五花八门。
- 机器配置规格不一，有企业自建云的，有租用电信DC的，也有买阿里云之类的 IaaS 的。要知道大多数情况下，甲方都无法按照 SaaS 厂商要求的硬件配置给出机器，这里面讨价还价的过程就太多了，无非都是希望节省硬件成本。我就遇到过要求3台机器，最后只能给出1台的情况。好在 k8s 的出现至少隔离了操作系统那一层对应用软件的影响。
- 业务量增长后扩容，如果是纯云端 SaaS，我们都是采用监控 + 人工/自动扩容的方式进行，因为有 k8s 提供的便利，可以很方便的新购机器加入集群。但在私有化环境里，是原有机器扩容还是新购都是需要先提供估算预案的，领导审批之后 IT 部门才会实施。很多情况下，“估算”真的就是拍脑袋，拍少了业务上去扛不住，拍多了硬件成本又上去了。试问双十一期间需要多少机器才能保证服务不挂呢？如果不经历个几次双十一阿里估计也给不了答案。
- 单独的监控和运维保障，因为以上的种种差异，导致所有私有化环境都是“非标准”的环境，这时候肯定需要建立各自独立的监控系统，其实就跟传统企业套件一样了，每天日常工作都需要逐个对私有化环境进行巡检。私有化客户越多，人力投入也越多。
说了这么多，其实并不是想吐槽私有化不好，其实私有化是完全符合国情的一种选择，国内 SaaS 公司或者想要做 SaaS 的潜在创业者们都应该仔细考虑是不是要做私有化。如果要做私有化，也不应该在短期内高估技术，快速私有化完全是一个需要持续投入成本，并不断演化的工程，只有在踩了无数坑以后才能见成效。
项目 or 产品
私有化往往还只是硬件层面的一种定制，到了软件层面，如果有大量的定制化需求，那么就会演变成一个“非标准”产品，“非标准”产品其实就是项目。虽然前面说了 SaaS 应该有强大的扩展性，但是试想如果本身做的是一个类似淘宝的电子商务 SaaS，结果客户说我也要一个轻量的供应链系统或者ERP系统怎么办？在尚未发展出第三方应用市场的情况下，这个多出来的部分包括跟原系统的集成都是需要当成“项目”来做的。
定制项目做完交付以后，还会面临一个巨大的困境，后期如何升级或者做修复？传统企业软件套件厂商的代码分支通常都会有几百条，对应不同的大版本号，每个大版本号都会有若干小版本组成。一般来说企业采购的软件是不包含大版本升级的，只会有小的补丁修复。但作为 SaaS 服务来说版本升级是一种常规操作，当客户发现云端的服务多了一个功能，而在他本地的却没有，肯定是很难说得过去的。如果这个客户的本地版本又是经过“定制”的，修改过代码的，那么在此基础上的版本升级就会变得异常艰难，就不说开发和运维的工作量，单单测试上就要花很多人力去做功能覆盖，毕竟下层的代码变动过，谁能保证云上的版本是好的，这里也是好的呢？
做项目和做产品其实是两个完全不同的思路，项目目标是交付，是需求驱动，产品的目标是提升竞争力，是功能驱动，需要花费更多的时间。一般来讲一个项目中的“好”功能去回馈到产品，也需要重新设计，抽象出配置项，理清操作关系。想要既把项目做好，又不多花精力的把产品做好，是不可能的事情。如果按照这样的逻辑，最好的产品应该都是来自于那些项目定制型的公司了。可是真实的情况并不是。
从个人角度来说，做项目还是做产品我本身并无偏好，只要公司可以盈利就行。但是做项目就不能融资，因为这不是好的故事，做项目的底线就是要赚钱，做产品可以说一个好故事，早期可以不赚钱，后面通过低边际成本赚钱。这就是在战略层面上最大的区别。“既要”“又要”的事情大家都想， 但是还是要重复一下，“短期内不要高估技术”，项目和产品兼顾，肯定走不通。
思考
最后，如果我作为一个 SaaS 创业者，我要创造一个新的产品，我肯定会去做的几件事
- 私有化。之前也提到了，私有化是符合我国国情的。如果想在国内不完全依靠融资活下去，私有化应该是必做的。甚至我个人认为在战略层面，私有化优先的策略都没问题。想清楚把成本投入在私有过程标准化上下就可以。
- 国际化。给自己留条退路吧，毕竟海外 SaaS 的接受程度更高，在产品设计之处就应该思考出海的问题。尽管会多花费一些成本，但总比等到想要出海的时候才发现整个产品要推倒重来的好。
- 内部开发多用代号，少出现公司名，方便 OEM 和私有化。
- 不要排斥做项目，毕竟“活下去”很重要。但一定要想清楚做项目付出的沉默成本是什么，通过什么方式可以弥补回来。产品的扩展性设计一定要提前考虑，降低项目交付成本。
- 最重要也是最难的，想好要做什么，不在路线图上的事情就不做。拒绝往往是最难最难的。
总结
创建维艰，以上就是我这五年来一些小小的心得，谈不上真知灼见，只是我内心最朴素的思考，希望对读者有用吧。
后记
最近我在B站关注的一位up主在发布了与自己告别的视频之后离开了这个世界，这是自年初《老饭骨》的大爷后，又一位关注的美食博主离世。要说热爱美食的人不爱生活，我是万万不信的，但是往往生活的操蛋程度又会超过自身所能承受的极限。我们生活在一个不易的年代，如果在这样的时代，大家还不能放下异见，互相取暖的话，真的很令人失望。
无论无何，请好好爱自己。借用这位up主的片尾，恰好也是大爷常说的
记得好好吃饭
