# 全球领先的公有云aws近几日召开的reinvent大会给腾讯云带来了哪些启发？

说的我也挺有感触的，aws作为云计算行业的龙头，在发展多年之后仍然保持着极其旺盛的生命力，并通过事实和结果证明了aws这种云计算模式似乎代表了基础设施变革的正确之路。抛开本次reinvent具体发布的新功能，作为一名长期关注云计算业界和aws发展的云从业老兵，我认为aws的精神内核无非就是：认真做产品，坚持做产品。

“认真做产品，坚持做产品”，这句话我想了好几年，主要是觉得太土气而想用一句更有逼格的话来评价aws的整体设计原则，但始终找不到更贴切的。而实际上一直以来，aws本身也是这么一个土味十足的产品集合，从一开始它被硅谷技术更强的大公司嘲笑其产品能力低端并没有什么先进理念，到现在仍然不断在各种场合被不同的同行吊打它的某些能力，就连它的名字本身“Amazon Web Services”也一直没有改过，让人以为是国内三线城市的网站代理商。

而这正是我认为aws之所以成功的原因，aws只以最笨的方法解决现实存在的问题，并把这变成标准的产品能力。包括本次的reinvent，aws推出了一项Image Builder(https://aws.amazon.com/cn/blogs/china/automate-os-image-build-pipelines-with-ec2-image-builder/)的功能，操作复杂，解决的场景有限，预期客户也多不到哪里去，但是它就是在aws的产品体系中恰到好处的“有用”。

稍微展开一点开看，aws的“认真做产品，坚持做产品”大致可以分为这么几个核心原则：

1. 强调产品化大过定制化/项目化/服务化。

ToB产品本身的服务化属性非常强，而aws宁愿以在早期吃力不讨好的方式坚持产品化，甚至有很多用户的核心诉求，只要是产品化条件不满足，aws就不以任何形式提供。比如“ec2在线修改密码”，aws大约在被骂了十几年之后，才通过ec2之上的另一个产品ssm(https://docs.aws.amazon.com/zh_cn/systems-manager/latest/userguide/ssm-agent.html) 做了有限支持。

我觉得这个和我司说的“C2B”的理念有共通之处，产品化意味着标准化、生态化和边际成本较低的可复制，产品化的道路更加漫长和艰难，但是它每一次的进步都是可复制的进步。ZStack的创始人张鑫发表过ZStack的设计理念的文章，有一篇专门探讨“是做产品还是做项目”，在我看来也是一定程度上受到aws的启发，（然后就被阿里云收购了）。当然这里并不是否认针对性服务的重要性，对产品不完善性的服务不仅困难而且难以创造附加价值。

在现实世界中，即便是云计算已经发展了十几年，基础设施的能力和用户的需求之间还是存在很多鸿沟，并不能一刀切的认为产品化的原教旨主义总是唯一正确的，标准和定制总是会有所取舍，但是aws对产品化的坚持算得上是对革命理想乐观奋进的光辉。

我们团队有一个产品弹性伸缩as（https://cloud.tencent.com/product/as）近两年一直在优化产品本身的能力而从未做过推广，却得到了120倍的规模增长，我想这也是产品化完善之后，“桃李不言，下自成蹊”的效应。

2. 模块化程度高。

这也算得上是产品化理念在落地上的实践原则，aws的产品矩阵继承amazon的内部架构，产品之间和产品内部模块之间的调用都是高度抽象和模块化的，模块之间边界清晰低耦合，模块内部架构完整高内聚。比如aws sns（https://aws.amazon.com/cn/sns/?whats-new-cards.sort-by=item.additionalFields.postDateTime&whats-new-cards.sort-order=desc）只是一个简单的消息收发服务，除了发布和订阅以外其它的事都不做，既看不到技术的深度也带不来多少收入，但是它在持续优化，做好消息的收发管道（甚至具体消息处理都是依赖其它产品），现在几乎所有的基于aws的“积木搭建”的解决方案都需要集成sns产品。

Image Builder和ssm也是相同的思路，面对具体问题，aws大概把最多的时间花在了分层和建模上。Image Builder不在Image中实现，而是另起一个产品，给原有的镜像产品在产品设计上一分为二，一个专门做镜像的管理和跟ec2相关的生产，另外一个专门做镜像的标准化生成，aws的产品经理面对Image Builder这样一个新产品，他考虑的是如何实现最稳妥的模块划分，pipeline、recipe、component、image充分解耦而又相互配合形成一个小而完整的可扩展架构，并且引入的概念都是开发人员易于理解的，然后整个Image Builder再与License Manager、Organizations、Inspector、ssm等服务协同成为完整的资源管理生态体系。

同样的，ssm与ec2的关系在于，ssm从ec2中分化出devops层，让iaas与devops互相依赖而又互不影响。aws的产品发展和裂变大都遵循着相同的路径，一般在孵化初期会显得产品建模复杂和臃肿，但它通过这种方式来很好地应对了长时间需求变化的考验。当然了，我觉得有些产品比如batch(https://aws.amazon.com/cn/batch/)还是太过度设计了，它引入的概念过于繁琐，导致使用时很难与业务场景的真实问题匹配上。

ec2不去做devops，它所关注的在于ec2本身的优化，在ec2早就一骑绝尘的时候，ec2仍然在其核心能力——性能和稳定性上持续并深度优化，然后这变成了aws的核心之一：nitro。从产品上看，nitro并无任何巧思，它只是在长时间踏实的解决实际问题，类似于曾国藩的“结硬寨，打呆仗”，步步为营，让时间站在自己这一方。这也是我不太认同题主所说我们缺乏顶层设计的地方，云计算，尤其是iaas层和paas层，产品的核心能力本身就是大家都认同并且追求的。正如题主而言，aws有一种不怕被抄袭的自信，我觉得那是因为aws选择了hardest way, 坚持在走hardest way，并且相信自己是hardest。我云的情况也是类似，虚拟化领域已经连续三年登上kvm贡献排行榜，这就是坚持和时间的馈赠，而我相信未来这也会变成我云最具竞争力的能力之一。

除了模块内部建模的有板有眼和优化的迭代深入，模块化程度高还有另外一个体现在于aws的api体系极其工整，工整到让人觉得严肃而死板。cvm早期，我们曾嘲笑aws api的道貌岸然，我们在关机接口中用1表示软关机，2表示硬关机，3表示先软关机再硬关机，4表示一个和关机没有关系的逻辑，我们为这种“quick and dirty”的设计理念欢呼，但是这给产品间的配合和用户的api使用带来灾难，我曾在某个大客户的现场看到其开发人员贴在显示器旁边的“腾讯云API魔法数字速查表”……于是在2017年cvm重新设计api时，深度调研才发现，即使不管ec2 api的事实标准这一点，ec2 api仍然几乎是最完美的设计。

aws api的权限控制体系iam（https://aws.amazon.com/cn/iam/details/manage-users/）也曾经让我头疼不已，但是我花了很长时间仍然想不出一个能比它更好的标准化权限控制功能，我们可以为不同的场景定制化权限控制功能，但随着需求变化和场景变多，这些都将变成不可维护的技术负债。如今腾讯云已经完整支持了更好的api框架，即参照aws实现的api 3.0，并且可以在api 3.0上集成权限控制cam和资源标签功能，这会是接入产品标准化的一个很重要保证。

这很像是手工艺产品和工业化产品的区别，工业化产品看起来千篇一律，没有情怀，但是它可控、可复制、可集成，让智慧和巧思体现在更上层的组合设计上，aws的工业化坚持反倒有了一种“天下有道，丘不与易也”的逼格。

3. 做尊重用户的产品创新。

尊重用户不仅是要解决用户的实际问题，也要让用户能够感知和理解产品的设计思路。aws极少做pr型的产品功能，也从来不提供silver bullet欺诈用户。比如aws的竞价实例（https://aws.amazon.com/cn/ec2/spot/），aws给ec2实例提供了一个“可能被中断回收”的选项后，实例的价格可以大幅降低。用户很容易理解这些资源其实来自于aws的母机池碎片，当aws需要时可回收以供正常的实例使用，这样用户也就能理解竞价实例低价格的原因以及在哪种场景下适用。aws竞价实例的精巧还在于，你越是去逆向分析它，就越能感受到aws确实只用一条“可能被中断回收”的不承诺而做到了其它所有的承诺（https://zhuanlan.zhihu.com/p/27606489）

计划预留实例（https://docs.aws.amazon.com/zh_cn/AWSEC2/latest/UserGuide/ec2-scheduled-instances.html）是另外一个尊重用户的产品创新，它摆明了以一种类似于滴滴“拼车出行”的方式诱导用户之间做好资源复用以降低价格。用户只要愿意接受“拼车”就能享受到低价。

尊重用户才能获得用户的尊重和信任，这是一笔巨大的财富，这也许是每次aws出重大问题时，用户宁愿去从自己身上找原因的原因吧。

这次reinvent发布的local zones（https://aws.amazon.com/cn/about-aws/global-infrastructure/localzones/?hp=r），也是相同的产品思路。aws扩展了zone的概念，引入了local zone，用户就能理解这个zone是从属于某个region并且离他较近，而且也能猜测local zone应该是接入到其所在region的骨干网，于是在不需要更多文档解释的情况下，用户很容易设计出合理的容灾架构。

4. 计算能力自下而上的产品化。

“aws只以最笨的方法解决现实存在的问题，并把这变成标准的产品能力”，aws最早只提供ec2和s3两个最底层产品，而不像当时流行的app engine提供的是完善且贴近用户的服务框架，因此曾倍受质疑。现在来看，aws已经发展出了几百个产品，而高屋建瓴的革命性产品已经销声匿迹，我认为原因还是在于aws的产品发展和裂变是一种自下而上的产品化过程。所谓自下而上，即在解决实际问题的过程中发现新的问题，然后再解决，而不是一蹴而就给出颠覆性的解决方案，后者有点树个靶子再打的嫌疑，并耗费了大量的精力在解决可能本不应该有的问题。

原有的基础设施即使再不好，也有几十年的积累和存量业务，基础设施的变革对于用户来说，至少要具备可迁移、可回退、可追溯这几个特征，计算能力自下而上的产品化的好处在于，它很少强迫用户一定要接受新的东西，但是它靠产品本身的有序演进让越来越多的用户享受到了平滑迁移到新功能带来的利益。前面说的ssm, image builder, as, 竞价实例, iam等都是这样演化过来的。

这次reinvent，aws发布了一系列arm实例和Inf1实例，可以看做是自下而上产品化，aws在服务用户时遇到了相应场景的问题，然后通过严格模块化的思路去解决，最后变成实际可用的产品，经过多年这样迭代，aws的发展越来越壮大，解决的问题越来越多，适用的场景也就越来越丰富，逐渐就有了颠覆旧基础设施的样子（然而它还是叫web services）。甚至aws发布的量子计算产品braket，都马上能在jupyter notebook中调用来编写实际的代码。

计算能力自下而上的产品化其实就是模块化边界清晰之后逐渐深度优化的过程，我最近两次参加T通道评审惊讶的发现，已经有了很多的内部业务在使用腾讯云的cvm和tke来搭建，通过标准的文档、接口和对产品的直观理解，就可以将业务部署到云，这在过去几年是不敢期望的。越来越多自发使用云产品组合的架构，正是代表了产品化成熟的标志。

————————结尾—————————

认识aws这么多年，如果把aws人格化，我觉得aws就像是郭靖，他说的话并不多，但每一句都真诚而有份量，不论是对阵威震江湖的名门正派，还是杀伐决断的漠北天骄，他总是恭恭敬敬地唱一个诺，然后左边画个龙，右边画一道彩虹，大喝一声：

亢龙有悔