私有云是如何产生的？
为了预见未来，必须了解历史。
话说，自从 2006 年 AWS 发布第一个服务 S3 和 EC2 之后，这种 Web Services 的方式交付 IT 基础设施资源的模式被人称为公有云，随后 AWS 接近以平均每年接近 100% 的速度持续增长了 14 年。谁也没有想到，当时一家以卖书为主的电商公司的 IT 业务竟然打败了 IBM，思科，戴尔，微软等一众历史悠久的 IT 巨头。
这个世界最常见的一个规律就是二元对立，有“公”必有“私”，公有云既然已经成形，而且一骑绝尘，发展太快，跟不上步伐，那必须得另辟蹊径。于是私有云的概念顺理成章出来了。
私有云有着非常强烈的现实需求，即使是 AWS 从发布至今 14 年之后，公有云厂家竞争看上去已经白热化的今天，公有云的总支出只占到总 IT 支出 3%（ 见下图）。也就是说直到今天，全世界每生产 100 台服务器设备，有 97 台将会被各企业放在自己管理的私有机房里运行着。值得注意的事，这还是在以 AWS 为代表的公有云出现 14 年之后的今天，公有云消费仍然占比如此小，也就是说在 10 年前，公有云市场几乎微不足道。
图：AWS 2019 re:Invent Keynote by AWS CEO Andy Jessy
由公有云爆发式增长引发了市场对“私有云”巨大的想像空间，在这么大的市场诱惑下，人们开始想像，如果有一套私有云软件，能够把这些分散在企业自管的数据中心的服务器等硬件资源整合起来，那将是个多么大的生意。
私有云简史
于是，除 AWS 之外几乎所有主流的 IT 公司都投入了建设私有云这场大跃进运动中，都希望能在未来这个大市场中占据一席之地。私有云世界也经历了三波发展：
第一波，是从 2008 年开始的一批私有云软件，其中以 Eucalyptus 和 CloudStack 为代表，后来因为单体架构和不够开放等原因，没有打开市场，市场注意力很快转向 OpenStack。
第二波，是从 2010 年，以 OpenStack 为代表的开源社区及生态公司，开源基金会的治理方式解决了不够开放问题，分而治之的面向服务的架构也解决了单体架构不够灵活的问题，为了保证成功，OpenStack 服务的设计一直在模仿 AWS，早期甚至直接使用 AWS 原生的 API。OpenStack 早期不论是从顶层设计上还是在声势上来看，是最有成功的模样，聚集了开源史上仅次于 Linux 生态的公司和开发者，也汇聚了无数私有云创业公司的梦想。但在 2016 年之后，市场迟迟没有打开局面，生态公司也几乎没有一家在商业化上取得像样的成功，其影响力日渐式微。私有云复兴重任交给了Kubernetes。
第三波，是从 2014 年开始 Kubernetes 为代表的开源社区及生态公司。同样的以开源基金会的治理方式，同样是分而治之的面向服务的架构，只是这会充分吸取了前任的教训，不再以 AWS 为原型来发展，因为活在巨人的阴影下总是很憋屈的。Kubernetes 并不学 AWS 以虚拟机为中心来构建服务群，而是借助容器技术，解决应用开发者最关心的应用部署、运维、服务化等问题。无疑这个策略到目前为止，算是成功的。许多坚持不上公有云的公司，在自有数据中心运行业务时，会首选 Kubernetes 来构建技术底层平台。其实 K8S 与平台无关，部署在哪里都可以，部署在你自己的机房，你可以叫它私有云，也可以部署在任何一个主流的公有云，而且各公有云还支持方便地接入 K8S 服务。
几乎与公有云的发展时间同步的 10 多年过程中，还伴随着一众自研的、或基于开源系统的商业公司，此起彼伏。但整个市场似乎一直止步不前，10 年前和 10 年后，客户负责的数据中心的软硬件变化不大，一样的配方，一样的味道，只是整个市场多了不少焦虑。
私有云走着走着迷失了方向。
私有云的反思
在私有云经历了这些波折，我们再回来看这个时候有公有云的现状：
图：AWS 公有云全球网络骨干拓扑 @ AWS 2019 re:Invent Keynote by Peter DeSantis
AWS 经过 14 年的建设全球一张网，覆盖全球主要城市和地区。这只是网络，更不用说已经发布的几百个独立服务，满足几乎所有行业、所有应用的需求。
AWS 14 年的优势是累积效应，14 年来 AWS 只是在建设一个云，服务几百万企业客户，一年产生 300 亿美金的收入，如此大体量仍然还能保持每年 2 位数的增长速度。
而同样发展了 10 几年的私有云，一般由几台、几十台或更多机器组成的一个一个分散的、隔离的小云，不断地在重复造轮子，几乎无法累积优势。过去十几年，市场上重复造了成百上千个私有云，但每一个私有云的建设几乎都是咨询式、定制化的，都需要经历从需求调研、硬件选型、网络设施、架构设计、实施部署等环节，每一个环节几乎都不可能自动化，因为要上门，要进机房，要搬箱子，每一个环节不靠谱都可能导致项目失败。
因此，到目前为止，没有一家私有云公司获得了累积效应，都是在低水平线上不断地重复。
发展到这里，终于意识到，以公有云为标的来构建私有云梦想根本不可能。虽然都被叫做云，但是 2 个完全不同的世界和不同的物种。
Ok，私有云的故事发展到这里，似乎应该终结了。
AWS 的突袭
在私有云起起伏伏十几年的发展过程中，AWS 也一直拒绝承认私有云是云，甚至在自己的市场规范手册中，不能提及私有云、混合云等关键词。引导客户上公有云是 AWS 的使命。
然而，在 2018 年 re:Invent 大会发布 AWS 的私有云产品 Outposts 预览产品，到今年短短一年时间 Outposts 正式商用发布[2]，相关的技术细节也一同发布，当看到里面的细节设计时，我是无比震惊的。
图：AWS Outposts 机柜实物照片
从官方页面来看，这是一个机柜式一体机，据多位现场技术人员反馈，Outposts里面使用的硬件平台和软件平台跟 AWS 公有云是完全一致的，包含了 AWS 最新的 Nitro 硬件平台架构。整体打包出租而不是一台机器一台机器的卖。更多细节介绍参考官网或特大妹的文章。
这里重点总结一下 Outposts 在设计上的“与众不同”，也是被吐槽最多的地方：
不支持出售，仅支持以整机柜租赁模式。也就是说，机器的所有权属于 AWS，不属于用户。
不支持自带硬件，只能使用全 AWS 定制的硬件，包含服务器、网络设备、电源等等；
不支持本地硬件运维管理。也就是机器有坏的，或者机器里面的硬盘、CPU 等部件有问题，只能提申请整台机器更换，不能本地开机维修、更换。每台机器上插有专用的加密芯片，防止任何部件被更换或者单独读取数据。
不支持本地软件和云资源管理。AWS 公有云上的 Outposts 服务是用户管理本地云资源的唯一入口，其他方式一律不支持。比如，每台机器的SSH，或者带外管理不对用户开放，用户也完全没有办法访问；
不支持软件定制。Outposts 运行的所有软件，统一接受 AWS 软件推送，不支持定制，比如，改个 instance type 啥的，肯定不行的，当然你可以向你的客户经理提需求。
不支持离线部署和运行。必须至少 1 Gpbs 以上专线与 AWS 最近的 Region 互联，从 AWS 公有云 Console 中启动和部署 Outposts。业务常规运行期间不能长时间中断专线，这是强要求，在 re:Invent 真机演示现场与技术人员确认，如果与 AWS 公有云的专线连接中断超过 4 个小时，所有服务将不可用，业务会受影响。
传统 IT 公司都能给你的，AWS 就不给！
看到这里，有人开始失望了，友商也开始嘲笑了，这些都是客户的核心需求啊，而我家的私有云产品全都支持，我才是真正做到客户至上，满足客户几乎所有的需求。
阉割了客户的“核心需求”，改变了二三十来年企业 IT 产品最基本的游戏规则，AWS Outposts 到底能不能被市场接受？这款产品会是像 Amazon Fire Phone 一样彻底的失败 [4]，还是会像 AWS 一样，成为亚马逊下一个千亿美金的产品？
AWS 为什么要改变游戏规则？
我们继续来深挖一下，AWS 如果需要满足以上需求，结果会怎么样？
如果以出售的方式，客户会说，这是我的私有资产，行，那客户就有责任对他的上线、运行、维修、下线、淘汰等硬件的完整使用周期负责，硬件里的软件也需要自行安装和维护。那么，AWS 需要把自己的私有软硬件技术拆开然后封装好，每一个产品有 2 大文档体系，一个是面向最终用户，像 AWS 公有云上的文档体系，另一个是面向 IT 管理员，还要一个一个地培训客户客户，教客户或服务商如何安装、部署、维修，然后构建总代、经销商、服务商等等一系列体系，用户最终用上，面对这样一个复杂的私有云体系，用户可能要再等 3 - 5 年之后了。
如果支持自带硬件，虽然给予了客户硬件采购的灵活选择权，但用户体验的牺牲更大。因为，那 AWS 为了满足客户需求，会推出一个硬件兼容性清单，协调各大硬件产商，自研的 Nitro 硬件体系顿时失效，多年的硬件经验立马失效。AWS 开发软件时，只能基于市场主流硬件的平均特性来设计软件，无法利用硬件方面最新的创新。这是 OpenStack 等开源或商业私有云软件最痛苦的地方，只能在软件上下功夫，还要满足几乎无限的硬件差异化需求，性能却受限于硬件的平均性能。
如果支持用户在本地管理软硬件，那 AWS Support 的难度增加百千倍，这个时候 AWS 就得培训现场工程师，或者建立私有云硬件的分销和服务支持体系。中间成本大幅增加，最后都由客户来承担这个成本。
如果把管理和控制平面放在本地，重复资源建设不说企业私有云存储哪个好，会出现双头管理的问题。对资源的合理调度、如何判断机器故障，等责任也会由用户承担。
如果支持软件定制，那么 AWS 就无法实现所有客户一套代码，AWS 全球的统一创新无法快速地应用到这里来。定制越多，离主流越远，必须内部维护无数个软件版本，最后奔溃。
如果支持离线部署，AWS 的 TAM 们就必须长期在客户现场驻场了。要么用户付出高额的成本企业私有云存储哪个好，要么没有优秀的人才往你这用派驻。
每一个“需求”的满足，背后都是无数原厂商、代理商、服务商的多年的噩梦。也是曾经所有开源的、商业的私有云产品失败的根本原因。
从系统可靠性角度来分析，以上 6 条核心的“不支持”，都直指一个事情：减少系统的输入参数的变量个数，简化系统设计，关注核心需求，提升系统安全和稳定性。
一套分布式软件系统的内部状态的管理就已经够复杂了，再加上外部几乎无限的多样性的变量输入，会让系统存在大量不可知的状态。比如，支持自带硬件，世界上的硬件厂商虽然有一些共同遵守的标准，但这么多年来，每家企业为了赢得市场竞争，都会特意做些差异化的功能，每一款硬件的差异化，对追求统一管理的分布式软件来说，都是一个新的变量输入，需要优雅地处理这些异常。更何况，还有很多差异化的硬件根本没有见过，容易引入未知的变量，做过程序设计的人都知道，一旦一个系统处于不可知状态，这个系统离奔溃就不远了。
最关键的问题是，这真的是客户的需求吗？还是客户 IT 部门的需求？亦或是客户多年来被传统 IT 公司培养的习惯性动作？
服务过百万云上企业客户的 AWS 太懂客户了，客户真正想要的是，麻烦事别找我，我只想支持好业务应用和业务创新，这才是企业的核心价值。
亚马逊 CTO Werner 大叔在 2017 年的 AWS re:Invent Keynote 中，就指出过未来企业数字化是一个什么状态：
图：AWS 2017 re:Invent Keynote by Amazon CTO Werner Vogels
未来的企业只需要关注自己的核心业务逻辑（所有的代码都将只是业务逻辑代码），剩下的东西并不是公司的核心竞争力，则可以使用云提供的共享服务，降低业务创新成本，提高业务迭代速度。
AWS 试图告诉我们的真相是，AWS 真正服务的对象是企业的决策层、业务创新开发人员、数据分析师等等为企业创造核心价值的人员。而不是传统 IT 市场所定义的 IT 人员。
在坚信谁是自己真正的客户之后，AWS 抛开了传统 IT 行业所有的历史包袱，和惯性传统，做出了历史上最大胆的取舍，在此之前没有哪家科技公司敢做得这么彻底。
回到用户，前面提到 AWS Outposts 的奇葩设定，也分析了 AWS 为什么这么做，那么，站在客户视角，客户最终能获得什么，为什么需要。
AWS Outposts 给客户带来什么
而“牺牲”所有这些权限，就为了获得一项体验——与 AWS 公有云一致的体验。这可是私有云发展的终极目标，AWS 第一次做私有云，还是 v1 版本时就已经做到了。
这个说法好像曾经也有不少其他厂商的私有云 / 混合云产品这么说过，来看看这个“一致的体验”具体到了什么程度。
AWS 有一个经典的网络布局方式，即 Region / AZ 模式，可以实现数据中心级别的高可用，即时一个 AZ 出问题，部署了 Multi-AZ 模式的服务不会受到影响。也这成为了所有公有云平台的标配。客户本地 Outposts 是以一个 AZ 的方式加入 AWS Region：
图：AWS Outposts 接入 AWS 网络之后变成一个 AZ
如上图，一个 Region 的一个 VPC，可以即包含公有云 AZ 上的 Subnet，也包含 Outposts 中的 Subnet，本地 Outposts 使用起来跟 AWS 的一个 AZ 没有区别。
另外，有些控制层面的服务是运行在 Region 层面，尤其是涉及需要高可用的服务，比如VPC，EBS，S3，EKS等等服务的控制层面不属于任何一个 AZ，而是在 Region 级别。这就意味着，这些 Region 级别的服务，本地 Outposts 不需要重复创建资源来承诺控制层面的负载，直接利用公有云的控制平台即可，比如 ECS 服务：
图：ECS 的管理控制平台在 AWS Region [3]
注意到， ECS 的控制平台是在 AWS Region 中的，而具体的ECS Cluster，则是在 AWS 或 Outposts 中的 AZ。也就是说，你不需要为 ECS 控制节点付费，即可享受 ECS 服务。还有一众的管理和编排类的服务都有类似的特点，如：AWS CloudFormation, Amazon CloudWatch, AWS CloudTrail, Elastic BeanStalk, Cloud 9 等等。
这种级别的“一致性体验”，是以前任何私有云/混合云产品形态中，从来没有过的创新。
更多的，订购了 Outposts 的客户，你还将获得：
AWS 过去及未来云服务所有创新，AWS 的创新能力有目共睹，只要本地 Outposts 有条件承载，都会推动到你自己数据中心的 Outposts 中来。比如有合适的新服务、新功能时会自动给推送，这一点与 Tesla 电动汽车的 OTA 更新机制类似。比 Tesla 更极致的是，Outposts 硬件有升级换代时，也会免费上门更换。事实上，从 2018 年到今天，我们能看到 Outposts 上支持的服务也越来越多；
极高的可靠性和稳定性。本地 Outposts 的 SLA 是与公有云的 AZ 一致的。
彻底的免运维。你本地不用顾任何人专门照顾 Outposts 环境，根据文档，客户本地只要保证网络是通的，电源是开的，其他一切都不用管。AWS 全球统一运维和服务团队，加上 AWS 多年来的自动化监控和运维工具，7/24 小时实时保驾护航；
0 等待交付。完全不需要漫长的传统企业项目的流程，什么需求分析、 PoC等环节通通不用。下单机器到货后，当天即可投入生产。本地只要准备好空间、电源和网络环境即可。经确认，如果服务到期用户取消订单，AWS 会上门把设备拖走。完全不用担心设备利旧、报废处理等问题。
上百万企业抛弃自己的数据中心，把业务全部迁移到公有云。公有云能够做到，忽略我的存在，只需要关注你的业务逻辑。那为什么不直接上公有云呢？什么情况下需要本地部署 AWS Outposts?
Outposts 解决哪些市场需求
是的，大部分情况下直接使用公有云就能很好解决业务问题，AWS Outposts 主要设计满足以下需求：
极低延迟的本地化计算和存储需求。有很多场景，比如，医疗图像处理、工业设备控制、运营商 NFV 等边缘计算的需求，5G 出来之后运营商类似需求会大爆发；
把计算能力搬到离海量数据更近的地方。本地短时间产出海量数据需要处理，而这些数据大太无法有效地传到公有云上处理，比如电视台、工厂等场景。
Outposts 不能用来解决以下需求：
因为对公有云不信任，而使用私有云的需求。因为 AWS Outposts 使用的安全是基于与公有云一致的安全体系，如果无法信任公有云的安全体系，也无法接受私有云的安全。AWS 从不会做没有业务价值而投其所好的事情，比如，为了让你感到安全，通过把物理设备在你家里，让你能够亲眼看到，亲手摸到，让你获得一种虚幻控制感，而是希望你能从客观的安全体系和技术原理来自己判断是否安全；
想通过买一个私有云，希望从硬件到软件自己也能学会，进而达到“自主可控”的需求。AWS 坚持把实现的所有细节以技术文档、白皮书、博客、re:Invent视频等方式向公共开放，直接去学习这些材料，自己来开发和设计，可能更直接、效率更高。
理解了 Outposts，这次 re:Invent 发现另外 2 个逆天的服务就可以很好理解了，分别是AWS Local Zones和AWS Wavelength。
AWS Local Zones 的背景是，AWS Region 虽然分布全球，但一个国家或地区只有 1 个 Region，中国有北京和宁夏 2 个 Region，已经是除美国之外 Region 最多的了。因为 AWS 建设一个 Region 的标准和成本相当高，但有了 Outposts 之后，可以很快组建一个 Outposts 集群，形成一个区域性、小规模的 AWS Zone，覆盖一个城市或一个省的需求。
图：AWS 2019 re:Invent Keynote by AWS CEO Andy Jessy
AWS Wavelength 则是专门为运营商设计的，大致对应在 ICT 圈已经讲了多少的 NFV 边缘计算概念，国内大致基于 OpenStack 做了比较多年，到目前为止，还没有一个广泛被采纳的方案，基本上都处于高度定制化阶段，而这次 AWS 给出的是一个高度产品化的方案，当然不用猜测都知道，也是基于 Outposts 构建的解决方案。如 Verison 在这次 re:Invent 上列举的如下需求：
图：AWS 2019 re:Invent Keynote by Verizon CEO Hans Vestberg
当我看到基于 Outposts 的 Local Zones 和 Wavelength 发布时，我就知道，Outposts 模式已经被证明是成功的了。AWS 自己已经先开始找场景大规模用起来了。
这三者什么关系：
所有的节点都是互相强连接的，这是一张巨大的网络，像人体的血管网络一样，即有主动脉，又有毛细血管，AWS 把自己及其合作伙伴的最新科技创新通过这个网络输送到各行各业。
AWSOutposts 给世界带来的意义和启发
我们很幸运，亲眼见证了自己熟悉的行业面临的巨变，AWS 通过一款产品有可能改变私有云市场 10 多年的混乱与低效。
其意义不亚于 iPhone 对于手机行业重塑与规整，iPhone 抛弃实体键盘和触控笔，和 Outposts 抛弃私有云的离线模式，有异曲同工之妙，都是通过一个小小的杆杠撬动了一个行业巨大的改变。
特斯拉通过电动汽车正在优化 100 多年未曾变化的汽车市场，特斯拉通过 OTA 让汽车变成一辆活的，可以演变升级的汽车。Outposts 也通过统一私有云控制平面、统一推送更新升级，也有着相似之处。
伟大的创新都经历了开头被无数人鄙视，然后继续坚持改进默默地改变世界。
Outposts 这个案例非常值得中国 2B 企业服务市场的从业人员思考，不管是创业者还是高管。
按照博弈论的理论，中国 2B 企业服务市场是一个典型的囚徒困境，即通过多次博弈共同选择导致了一个多方共同利益受损的局面。
我们可以看到，一方面，在企业服务市场上太多的乙方们苦得一逼，另一方面甲方也过得很不舒服，甲方长期以来也找不到合适的供应商，反正就将就着，凑合凑合就行，苦一点累一点。有实力的公司经常还找不到合适服务提供商，最后迫不得已，干脆逃离社会协作分工网络，纷纷选择投入巨资进入非主营、非核心业务，比如，做自己做私有云，行业云等 IT 基础平台，或者开始自研各种中台。导致整体社会创新成本居高不下。
只有通过有实力公司的创新改变游戏规则，才能最终打破这个囚徒困境，减少博弈多方的无效损耗，实现社会利益最大化。在 re:Invent 上见过很多的欧美专业服务类公司，同样是当乙方，同样是卖服务，哪怕是自由职业者，都能生活得很体面、有尊严，而国内同行们大多活得“苦大仇深”的样子。
AWS Outposts 的出现有助于打破国内私有云，甚至更广义的 2B 企业服务类市场囚徒困境这个局面。只希望 Outposts 早日突破障碍，进入中国市场。
参考资料：
%20Outpost%20Solution%20Brief_v7%20Final.pdf