1. 我在思考什么
在大公司，有更多机会了解行业动态，参与行业变革。
大平台的运行，不是依靠某一个人或几个人。如果这样真的能实现，那也就不能称之为大的平台。一个萝卜一个坑，各自分工，相互协同，才是现代的管理方式。
平台做得好，有影响力，个人也会有加持。但常常会陷入一种认知误区：将平台的能力当作自己的能力。而实际上，自己只是负责其中一个小的模块。如果自己不主动学习、思考平台的框架设计，认识不到价值密集区域，那么平台的能力也就和自己无关了。
非常幸运，我有机会参与一场 ToB 的 IT 基础架构的技术变革。在平台产品取得成功、获得影响力时，我也在不断思考，平台的核心竞争力在哪里，如何继续扩张将影响输出到其他行业。下面的内容，就是我给这些问题的答案。
2. SaaS 的特点
SaaS 是通过随时可达的方式，直接对用户提供服务的互联网软件。常见的 SaaS 有在线邮箱、笔记、办公套件、CRM、ERP 等。
2.1 从产品侧看
多租户。SaaS 通常是一套软件，服务所有用户。多租户模式，压缩了 SaaS 提供商的运营成本。但为了保证租户数据的安全，需要对数据进行隔离。不同的租户使用不同的数据库实例，或者通过租户 ID 的外键，对数据进行过滤。
可定制。一套通用的 SaaS 不能够满足全部客户的需求。SaaS 提供商通常会提供一些配置给客户使用，甚至直接针对客户进行定制化开发。
面向企业。虽然有提供给个人使用的 SaaS ，但是 SaaS 主要是面向企业的。ToC 的 SaaS 收费困难，通常仅能通过广告获得一定收益。ToB 的 SaaS ，天生具有盈利基因，很容易就能收支平衡。这是由于，SaaS 通常提供的是工具、效能服务，企业更愿意为提升生产效率付费。
2.2 从开发侧看
质量要求高。ToC 产品出了问题，只能通过官方渠道投诉，然后不了了之。但是 ToB 不一样。企业会找到售后，处理不好，会直接影响合作是否继续。
无状态。为了能够平行扩展，满足租户不断增长地性能需求，SaaS 应该是无状态的。通过异地多机器部署 SaaS 实例，分担不同租户的访问请求。将缓存、持久化、消息队列等状态，全部使用集群的方式存储，对 SaaS 提供服务。
开发框架。SaaS 需要统一的开发框架。开发框架提供的公共模块，能够减少开发量、学习成本，加快定制化开发的速度。
功能性 API。通过 API 调用，SaaS 的能力边界会被扩大。发送通知、在线支付、查询地理位置等，如果让 SaaS 实现这些功能，需要消耗大量时间，同时还不能保证质量。因此 SaaS 依附的平台应该提供相应的 API。这些 API 直接影响到 SaaS 对平台的粘性。
3. 为什么要使用 PaaS
这两年多，我的主要工作就是做 SaaS 开发，也参与过少量 PaaS 的开发。我以使用方的角色描述，PaaS 能带来什么，更加合适。
开发框架。正如上面所说的，为了提升开发效率，SaaS 开发者需要开发框架。但 PaaS 提供的开发框架，实际上主要是为了解决一致性的问题。PaaS 在进行部署时，会对 SaaS 进行编译封装，SaaS 得告诉 PaaS 一些必要得信息，比如环境变量、日志格式、启动参数等。
状态服务。由于 SaaS 无状态，PaaS 需要提供 MySQL、RabbitMQ 等公共服务，不同的 SaaS 之间，这些服务又是相互隔离不可见的。
API SDK 包。PaaS 通过企业总线（ESB）或网关（API GATEWAY），提供了大量第三方服务。开发者直接通过 HTTP 请求调用 API，容易拼错参数。通过 API SDK 包的方式，将远程 API 封装成本地函数调用，对开发者更友好。
编译部署服务。提交代码之后，通过点击按钮可以完成 CI/CD 的全过程。
监控服务。PaaS 提供日志查询，进程、服务监控等监控服务。这些指标通常是开发者关心，用来定位问题、优化性能使用。
增强服务。基础的监控服务通常不具备侵入性，对 SaaS 没有影响，但功能较弱，不能满足开发需求。这时，就可以使用增强服务，比如 Sentry、APM、Ceph 等，需要进行配置，才能使用。
正是由于 PaaS 提供了这些公共服务，SaaS 开发者只需要关注代码，实现功能即可。PaaS 带来的是开发、运维、运营效率的整体提升。
4. 如何跨行业迁移 PaaS
SaaS 能对接场景，与营收、成本直接关联。但如果场景无法收敛到足够少，PaaS 会是一个不错的解决方案。
上图是，一个通用的 PaaS 解决方案。
对于 PaaS 平台，Gartner 把它们分为两类，一类是应用部署和运行平台 aPaaS（application platform as a service)，另一类是集成平台 iPaaS（integration as a service）。 人们经常说的 PaaS 平台基本上是指 aPaaS，如 Force 和 Google App Engine。甚至衍生出了大量容器即服务的公司，直接提供容器部署服务。
我认为 PaaS 的核心价值在 iPaaS 层。
在我经历的 PaaS 技术变革中，最开始是通过本地目录隔离部署，之后改为 Docker + Slug 部署，现在直接使用的是 K8S + buildpack 部署。实际上，这些对 SaaS 开发者、用户来说，意义不大，反而是 PaaS 开发者获得了更多收益。平台更易维护，资源利用效率更高，对标业界标准等。
aPaaS 层同质化严重。一套好的 aPaaS 可以全行业通用。甚至，我认为 aPaaS 层可以与 DevOps 打通，aPaaS 直接执行 DevOps 流程即可。
但，iPaaS 层不一样。iPaaS 是领域知识密集型的一层。
在运维领域，配置管理，执行作业，都是运维才会接触到的概念。iPaaS 需要将其抽象产品化，通过 API 的方式对外提供服务。
在电商领域，iPaaS 提供支付、物流、商品管理等平台服务。这些细分的领域，需要专业的人员去抽象、合规，最终仅通过 API 的形式对 SaaS 层输出领域能力。
能够将需要长时间高强度训练才能掌握的能力，通过 iPaaS 有效地传导给 SaaS 开发者、客户，才是 PaaS 的核心竞争力。
