一、这一章换了问法

上一章的十条在回答【一个云是怎么搭出来的】，这一章的十条在回答【搭出来之后靠什么转起来】：

这一章读下去会发现一个规律：越往后越不像【技术】，越像【管理】。这不是教材跑题——机器规模一大，问题的主语就从【机器】变成了【人】。

二、开放到底开放了什么

【开放】这个词被用得太松，实际上它至少包含三条不同的线，公开的东西完全不一样：

三条线不是一回事，而且缺一条就会卡住：

• 只有接口开放：你能调用它，但换不掉它——因为只有一家实现符合这个接口。
• 只有代码开源：你能改它，但如果每家改出来的都不同，你的改动换不到别处去。
• 只有标准开放：规格写得很清楚，但没有可用的实现，等于白纸。

所以真正的【开放】要三条线都在——而这三条线各有各的推动者：接口靠云服务商自己公开，代码靠开源社区，标准靠行业组织（4-19 里点过的那几个）。

三、动手 Demo：算一笔可替换性的账

开放好不好，不用讨论理念，算一笔账就清楚了。

看到什么算成功：

==================================================================================================
【Demo 1】驱动云服务的技术：开放化的浪潮
==================================================================================================
  云服务能立起来，第一股推动力是【开放】。开放不是一种姿态，
  它有一个可以检验的判据：这个部件能不能被换掉，而不用动其他部件。

  【一】三条开放线：公开的东西不一样

  开放线            公开的是什么            换起来要动什么
  ----------------------------------------------------------------------------------------------
  开放 API          接口的调用方式          换实现，调用代码基本不动
  开源软件          源代码本身              换实现，必要时可自己改
  开放标准          规格文档                换厂商，多家实现彼此互通

  三条线不是一回事：接口开放不等于实现开放，实现开放也不等于别人能接。
  所以一个系统往往三条线都要有，才谈得上【换得动】。

  【二】算一笔可替换性的账
  一个系统拆成 5 个部件：计算、存储、网络、数据库、监控。

  方案          可替换部件数        被锁死那家涨价时          要付的代价
  ----------------------------------------------------------------------------------------------
  全专有        0 / 5               只能接受                  没有退路
  半开放        2 / 5               2 个部件能搬走            搬迁 + 重测
  全开放        4 / 5               4 个部件能搬走            搬迁 + 重测

  为什么是 4 / 5 而不是 5 / 5：数据与人的迁移永远最难。
  开放标准能解决【格式通不通】，解决不了【搬不搬得起】。

  【三】开放的代价（不是白拿的）
  ① 自己组装，得有人会装          → 人力成本
  ② 各家实现有差异，得试过才知道  → 磨合成本
  ③ 出问题没有单一责任方          → 定位成本

  一句话：开放换来的不是【便宜】，是【退路】。

读结果：

• 第二张表里那一列【可替换部件数】就是议价能力。0 / 5 的时候，对方涨价你只能接受；4 / 5 的时候，你可以坐下来谈——谈不拢就走。所以开放买的不是情怀，是谈判位置。
• 为什么永远到不了 5 / 5：计算、存储、网络、监控这四类都能换，只有【数据】和【人】换起来最贵。数据格式可以靠开放标准统一，但迁移窗口、停机时间、员工重新熟悉，这些是任何标准都省不掉的。这也是为什么云上的迁移永远是一笔【项目】，不是一次【切换】。

四、开放对云来说为什么格外重要

其他行业也有开放与封闭之争，但云的情况更极端一点，原因是云本身是拼出来的：

• 一层叠一层。你在云上跑的是一套系统，但这套系统底下至少压着三层别人的东西——虚拟化层、网络层、存储层。任何一层被锁死，上面全都被拖住（4-7 讲【同一份声明能在各家执行】时，说的就是这件事）。
• 客户天然怕被绑住。把核心系统搬上去容易，搬下来难——所以客户在选之前一定会问【我以后能不能走】。云服务商愿意开放接口，很大一部分原因是不开放就进不了这个门。
• 规模效应要求互通。一家云上的东西要能连到另一家云上的东西，数据要能互相流动——这只能靠标准，不能靠私下约定。

把这三条合起来看，就能理解教材为什么把【开放化的浪潮】放在本章第一条：它不是某一项技术，而是其他九项技术能够互相拼接的前提。

30 秒实验

打开任意一家云服务商的【开发者 / 开放平台】页面，做两件事：

1. 看它列了多少个产品有 API（多数会写成【全部产品均可通过 API 调用】），记下这个数字。
2. 随便点进一个产品的 API 文档，看它有没有提供多种语言的 SDK（Java、Python、Go 等）。

做完这个，你会对【开放】有具体的感受：一个产品的 API 越是写得完整、SDK 越多，被换掉的门槛就越低——而云服务商仍然愿意这么做，恰恰说明【开放】不只是客户的需求，也是它自己获客的手段。

常见误区

1. 错误：开放就是免费。——纠正：开放说的是【公开】，不是【不要钱】。开源的软件常常有商业支持服务（收费），公有云提供的托管开源服务也按用量收费。开放影响的是你能不能换掉它，不是它的价格。把开放理解成免费，会得出【用开源就一定省钱】的结论——而 2-12 里算过：OpenStack 的许可费是 0，但人力成本是商业方案的数倍。

2. 错误：只要用了开放标准，就不会被锁定。——纠正：标准解决的是【格式】，锁定往往发生在【周边】。比方说一个数据库的数据格式是标准的，导出没问题——但备份工具、监控集成、权限体系、运维习惯全都绑在原来那一家上，换起来一样费力。所以判断锁定要看整个使用链条，不能只看数据格式这一环。

3. 错误：开放只是理想主义的说法，商业上没意义。——纠正：开放恰恰是商业上非常清醒的选择。对客户来说，开放意味着议价能力和退路；对服务商来说，开放接口意味着别人更容易接入我、用我的东西。两边都有动机，这件事才会成为浪潮——如果只有一边得利，它不会普及到今天的程度。

4. 错误：既然开放更好，那就应该全都选开源的。——纠正：开放的代价是真实的（本节 Demo 第三段那三条）。自己组装要人力、各家实现要磨合、出了问题要自己定位责任。所以正确的做法是【算替换的价值】而不是【按理念选】：如果这个部件五年内不可能换（因为换的成本远大于收益），那被锁在商业方案里也没什么不好——关键是你要知道自己在哪一栏。

• ☐ 下一节（5-2 接入云服务的连接：VPN、专线）

相关笔记

• 构建技术的通用化和标准化 —— 上一篇：法定标准与事实标准的判据
• 云计算也在走向开源化 —— 开源解决了什么、没解决什么
• 实现多云计算的容器 —— 同一份声明能在各家执行，靠的就是开放
• ☁️ 云计算 · 索引 —— 全课路线图