一、分界线画在哪一层

把一套系统从下往上切成八层，三者的区别立刻就清楚了：

三条分界线，一条比一条往上抬：

• IaaS 的线画在"虚拟化之下"：硬件、机房、平台全是对方的，从操作系统开始就是你的。所以你在 IaaS 上能做的事，跟在一台自己的服务器上几乎没区别——只是这台机器是租的、可以随时换。
• PaaS 的线画在"应用代码之下"：操作系统、运行时、中间件都归对方，你只交业务代码。
• SaaS 的线画在"应用代码之上"：连应用都是对方的，你只交数据和使用方式。

注意最下面两行——数据和用户权限，无论哪一层都仍然在你手上。 这一点最容易被忽略：云服务从来不替你负责数据（这一点在 1-15 讲故障恢复时也提过：那 4 分钟只是机器层面）。

二、同一个需求，三种买法

抽象的分层看着清楚，但落到具体项目上还是难。用一个最普通的例子——一个内部审批系统：

这张表里最反直觉的是：上手越快的，总成本越高。 很多人第一反应是"那当然选便宜的"，但这样看就漏掉了这张表真正的意思。

贵的部分，是你花钱买回来的时间和风险转移：

• IaaS 便宜，是因为你要自己花那 3~4 周把操作系统、运行时、中间件一层层装起来，而且要一直养着它。
• SaaS 贵，是因为别人把这三层都替你做了，代价是流程要按它的做法走。

三、怎么选：一个问题就够了

这套流程是【我们的特色】还是【行业通用】？

• 越通用（审批、考勤、邮件、工单），越该往上走——因为你的做法跟别人没差别，自己造一个不会有任何优势，只会多一份要维护的东西。
• 越独特（核心计价规则、独有的生产工艺、行业特有的算法），越该往下留——因为那一层正是你的竞争力所在，被套进别人的固定流程里就没了。

这个判断可以往下再推一步：同一套系统，不同部分可以落在不同层。最典型的组合是"核心逻辑自己写、周边能力全托管"——用 PaaS 提供的认证、日志、消息队列，把自己的人集中在那段真正独特的代码上。

四、动手 Demo：把分界线和三种买法都摆出来

# 八层责任表：True = 提供商管，False = 你管
layers = ["机房与电力", "服务器与存储", "虚拟化", "操作系统",
          "运行时与中间件", "应用代码", "数据", "用户与权限"]
line = {"IaaS": 3, "PaaS": 5, "SaaS": 6}   # 分界线在第几层之下

for service, cut in line.items():
    # 分界线以上（index < cut）归提供商
    owner = ["提供商" if i < cut else "你" for i in range(len(layers))]
    print(service, owner)

实跑输出：

==================================================================================================
D5 云服务的分类：IaaS、PaaS、SaaS 差在哪一层
==================================================================================================
  【一】把系统从下往上切成八层，看三家各管到哪

  层次                  自建      IaaS        PaaS        SaaS
  --------------------------------------------------------------------------
  机房与电力            你        提供商      提供商      提供商
  服务器与存储          你        提供商      提供商      提供商
  虚拟化                你        提供商      提供商      提供商
  操作系统              你        你          提供商      提供商
  运行时与中间件        你        你          提供商      提供商
  应用代码              你        你          你          提供商
  数据                  你        你          你          你（部分）
  用户与权限            你        你          你          你

  【二】同一个需求（一个内部审批系统），三种买法的对比

  方式            上手时间        三年总成本        谁负责运维
  --------------------------------------------------------------------
  IaaS 自建       3~4 周          约 42 万          你的团队
  PaaS 平台       1~2 周          约 60 万          双方共担
  SaaS 现成       3~5 天          约 72 万          提供商

  ④ 没有【哪种更便宜】，只有【哪种更合适】。
     IaaS 上手最慢但最自由；SaaS 上手最快但只能照人家的流程走。
     选之前先问一句：这套流程是【我们的特色】还是【行业通用】？
     通用的部分越多，越该往上走；越独特，越该往下留。

读这个输出：第一张表最值得盯的是最后两行——不管选哪一层，数据和用户权限都留在"你"这一列。这解释了为什么"上云"从来不是把责任全交出去：云交出去的是运行环境，留下的是数据的归属和谁有权访问。第二张表则说明三者的差别不在贵贱，而在"你换来的是什么"——用钱换时间（上移）还是用时间换自由（下移）。

五、⚠️ 2026 现状

• PaaS 的形态在变化。早期 PaaS 往往是"一套固定的运行环境，你往里塞代码"，限制较大、迁移也麻烦；今天更常见的做法是按能力拆分——认证、消息、存储、AI 能力各自作为独立服务提供，你可以只挑需要的那几个。这让"分层"从一个整体选择变成了逐项选择，也使得"核心自研＋周边托管"这种组合变得更容易实现。
• SaaS 的定制能力在增强。低代码配置、开放接口、数据导出能力都比几年前好，所以"选 SaaS 就得放弃所有定制"这个顾虑在减轻。但边界仍在：能配的是流程参数，不能改的是产品方向。
• 三层的界限越来越模糊。今天不少产品一条线跨好几层——比如"托管数据库"既是 PaaS 能力，又带着很强的 SaaS 属性；"无服务器"则把资源分配也一并包了。所以判断时别纠结它叫什么，回到那句老话：它替你把哪一层管走了。

30 秒实验

想一件你每天都在用、但不是你公司自己开发的软件（比如公司的邮箱、考勤、报销系统），回答两句话：

1. 你能改它的界面和流程吗？ 只能选选项、不能改逻辑 → 典型 SaaS。
2. 如果换一家，你要做什么？ 如果只是把数据导出来再导进去，说明它跟你自己的系统耦合很浅——这就是 SaaS 的特征：换起来相对容易，但也没什么可改。

再想一个你们自己开发的核心系统，问同样两句。两者的答案对照一下，就能体会"分界线画在哪"的实际含义。

常见误区

1. 错误：三层是递进关系，早晚都要走到 SaaS。——纠正：它们是并列选项，不是成长阶段。走到哪一层取决于"这件事是不是你们的差异所在"。很多公司最核心的系统会长期停在 IaaS 甚至自建——不是落后，而是因为那一层必须自己掌握。把分层当成升级路线，会导致核心能力被无谓地交出去。

2. 错误：SaaS 上手快 3~5 天就能用，所以最划算。——纠正：上手快对应的是长期成本高，而且这笔钱买的不是"省事"而是"改动权"。你花了更高的年费，换来的是"流程按对方的做法走"。如果这套流程恰好就是你们的竞争力，那再便宜也是亏的。 反过来，如果它只是通用的行政流程，那贵一点也值——判断的依据是流程的性质，不是价格的数字。

3. 错误：上云了，数据的安全就该云服务商负责。——纠正：看第一张表的最后两行——数据和用户权限一直在"你"这一列。提供商负责的是机器的运行和平台的可用性；数据流失、权限失控、误删误改，责任都在使用方。这也是各种责任划分模型（业界常说的"责任共担"）的核心意思：平台的安全由平台负责，你的配置和数据由你负责。

4. 错误：IaaS 更自由，所以应该都从 IaaS 开始。——纠正：IaaS 的"自由"同时也是"什么都要自己干"。操作系统补丁、运行时升级、中间件高可用，全落在你们团队身上。如果没有对应的运维力量，IaaS 的自由会变成负债——上手慢 3~4 周只是开始，后面还有持续的人力投入。选 IaaS 的前提是"你确实需要那份控制权"，而不是"它看起来更灵活"。

• ☐ 下一节（2-6 使用整个系统的 SaaS：SaaS、群件、业务应用程序）

相关笔记

• 一切尽在云中 —— 上一篇：XaaS 家族全表
• 云服务的市场规模 —— 三层各自的市场规模与占比
• 云计算对系统架构的改变 —— 哪些系统不宜上云，理由往往在这一层的判断上
• 从系统运用角度看云计算的优越性 —— 机器层面的恢复与数据层面的责任
• 使用整个系统的 SaaS —— 下一篇：走到最上一层时，具体是什么样
• ☁️ 云计算 · 索引 —— 全课路线图