OpenStack：为什么一个被所有大厂支持的开源云平台，最后连发起方都慢慢不用了？

# 商业复盘备忘录：OpenStack

> 为什么一个被所有大厂支持的开源云平台，最后连发起方都慢慢不用了？
> 周期: 2010 - 2020 | 行业: 企服与SaaS
> 巅峰: 由大型互联网公司与托管服务商共同发起的开源云计算平台，一度被视为企业私有云的标准方案，几乎所有主流 IT 厂商都推出了发行版
> 终局: 部署与运维的复杂度远超企业承受能力，客户纷纷转向公有云与轻量编排方案，多家厂商退出相关业务，基金会最终改名并转向更宽泛的开放基础设施

## 核心概览
把几十个独立组件组装成一套云，组装和维护的成本被留给了客户。巅峰期由大型互联网公司与托管服务商共同发起的开源云计算平台，一度被视为企业私有云的标准方案，几乎所有主流 IT 厂商都推出了发行版；终局是部署与运维的复杂度远超企业承受能力，客户纷纷转向公有云与轻量编排方案，多家厂商退出相关业务，基金会最终改名并转向更宽泛的开放基础设施。

## 社区公投头号死因
1. [产品技术] 平台由大量独立组件拼装而成 (1,622 票)
2. [战略决策] 把组装与运维成本转移给客户 (1,362 票)
3. [战略决策] 公有云提供了成本更低的替代方案 (1,103 票)

## 可执行教训
### 开源项目的商业成功取决于客户的运维成本，而不是厂商数量
> 生态越热闹，越要问客户维护它要花多少人。

- ✅ 推荐做 (DOs):
  - 把部署与升级的复杂度作为核心产品指标
  - 明确客户需要承担的人力与技能门槛
- ❌ 绝不能做 (DON'Ts):
  - 不要把厂商背书当作产品成熟度
  - 不要在客户运维成本高企时继续扩大组件数量

## 救亡方案
### 把平台收敛成可交付的整体，而不是组件的集合 — 良略编辑部
干预时点: 2016 年前后企业客户普遍反映运维成本过高时
- 必须断腕:
  - 停止继续扩大核心组件数量
  - 停止由厂商各自定义互不兼容的发行版
  - 停止把集成与升级工作默认交给客户
- 破局动作:
  - 收敛核心组件并提供整体升级路径
  - 以托管式交付降低客户的人力门槛
  - 明确平台与公有云的差异化场景，聚焦合规与本地化需求
- 预期结果: 平台在需要本地部署与数据合规的场景中保持位置，客户以可承受的人力成本长期使用，而不是在运维压力下整体迁往公有云。

## 社区见解
### 企业自己组一套云，真正付的钱不是软件，是养一支运维团队。 — 良略编辑部 (工程师)
这个平台的技术方向没有错，错的是它的交付形态：几十个组件各自迭代，版本和接口需要客户自己对齐，升级一次就是一次内部项目。在大厂手里这不是问题，因为大厂本来就有这样的团队；但对企业 IT 部门来说，这是一项长期的人力承诺。当公有云把同样的能力做成一键开通的服务，自建的理由就只剩下合规与成本两个，而这两个理由往往也算不过账。
- 如果重来一次的纠偏招式 判断基础设施产品，先看客户要投入多少人才用得起来。

---
来源: 良略 · https://www.lianglue.com/c/openstack