Skip to content

四火的唠叨

一个纯正程序员的啰嗦

Menu
  • 所有文章
  • About Me
  • 关于四火
  • 旅行映像
  • 独立游戏
  • 资源链接
Menu

为什么云计算服务是亚马逊先做出来?

Posted on 06/11/201810/02/2024 by 四火

Image result for aws google cloud azure最近看了一个知乎的帖子,大家讨论为什么是 Amazon 先把云计算服务做出来,而不是 Google。类似的问题我遇到过好几次了,之前还在亚马逊的时候,我觉得利益相关等等原因,自己不太适合回答这个问题;而现在,又看到各路人马大神已经把这个问题从各个角度分析得底朝天了,于是觉得似乎又没有太大必要了。不过现在,回头看到这个帖子的时候,我还想再从我的视角总结总结,不只是为什么 Amazon 先把云服务做出来,还有为什么现在它可以一路领先。虽然说 Google 也是云服务的三驾马车之一(另两驾是 Amazon 和微软),但如今许多方面它都和另两驾还有不少的差距。我记得刚加入 Oracle 的时候,但凡听说我从 Amazon 来,就理所当然地 assume 我来自 AWS,足见其在业界 AWS 的影响力之巨。而事实上,Amazon 的范畴远比 AWS 大,而且 AWS 也是这些年才火起来的。

首先,最本质的一点,是深入到公司 DNA 中务实的文化,而 DNA 的形成发展,来自于残酷的发展环境。简单而不准确地说,Google 是精英文化,而 Amazon 是实用文化。Google 的广告业务太赚钱了,搜索引擎的广告是互联网最著名的印钞机。多数情况下,这当然是好事,但是当一个业务太赚钱了以后,公司就没法体会到生存的压力,公司老大就没法在互联网泡沫的谷底时顶着巨大压力和骨干员工说 “我不在乎股价” 而成为美谈。国内的百度就是一个一定程度上非常糟糕的例子。

Amazon 的压力很大,而且传统零售业的利润率,是远远无法和 Google 的广告相比的。眼看着零售业的空间慢慢蚕食殆尽,Amazon 迫切需要新的业务增长点,因此从一定意义上说,这是残酷的环境逼出来的。如今,我们看到 Amazon 讲 frugal,Amazon 讲 deliver,甚至都有不少人抱怨在公司里洗脑了,过度强调 leadership 了,而这其实都是源于公司的 DNA。

扯远一点,讲到务实的文化,突然想起了我前一家公司——华为。从公司层面上说,它就如同是中国的亚马逊一般成功,而它的务实,我觉得可以用我在新员工培训的时候听到的这样一些话来概括,比如 “小改进,大奖励”,说的是,别给公司大的事情说三道四,着眼手头的小事情,改进了工作就有回报;还有一句是,“领先一小步是优势,领先一大步是烈士”,说的也是做实用的创新。事实上我并不认同这些说法,但是依然,它们是务实文化很好的佐证。

其次,有了文化的铺垫,依然不是所有人都可以玩云服务的,在最开始的时候,Amazon 搞得开,搞得快。需要有软硬资源上的前提:

疯狂的迭代和发布。Google 对于学术菁英以及工程艺术的追求,无其它公司可出其右。Amazon 就看起来 “土” 很多,比如说,代码质量如何?难说追求完美。但是其迭代的能力简直可以说 “令人发指”。Amazon 几乎不会花上漫长的时间做设计,做架构,我们看到的,都是大量不完美的,甚至存在着明显缺陷的产品,然后开始丧心病狂的迭代。哪怕到现在,打开 AWS console 上面的服务列表,我想多数人都难以说知道全部的 service 都是做什么的,我记得最快的时候,每几天就有新的 AWS service 发布。即便是非 AWS 的内部产品也是如此,我记得在 Amazon 工作的时候,内部的工具多而且新,花在这些东西上的学习成本着实可不低,而且,每年工程师都要投票淘汰那些不好用的工具。

大众工程师基础。这是很少人提及的一点,似乎凡是说到 IT 企业,都谈效率,谈自动化,谈机器替代人力。当然正确,可是要做到这些事情,实在不是——至少当今这个阶段不是——几个或者几十个呼风唤雨的工程师可以搞得定的。而众所周知电商的原因,Amazon 工程师资源明显比较富足。许多方面 Amazon 的面试 bar 没有 Google 高,薪酬和工作环境通常也会和 Google 有一些差距,但是,无论是招人还是晋升,都接近实战。我把这些工程师叫做 “大众工程师”,不是所谓的菁英,但也绝不是庸才,他们是真正是生力军。在疯狂扩张的时期,Amazon 也可以保持招聘的效率和强度。直到现在,很多人都知道的一件事情,是 Amazon 薪资中的 base,有着明确的上限,因此报酬要靠股票来弥补,而且股票都是按照年份递增发放,最大限度地把员工和公司的利益绑在一起。

丰富的硬件资源。这一点很多人也提到过,做电商的,而且做那么大的电商,哪个国家没有个疯狂的消费季呢?如同中国国内的双十一,美国的圣诞-元旦期间,以及后来大力经营的 prime day,都需要大量的计算资源。而消费季以外,这些资源放着又是浪费,因此云服务的催生是自然而然的过程。

再回过头来看这三点,可见虽然说互联网公司那么多,甚至还有不少已经触及了云服务的边界,比如网格计算,比如私有大规模计算或者存储集群,却都没有真正发展起来,也不足为奇了。第二、三点把几乎所有中小公司全部过滤掉了,而第一点又把许多大公司都过滤掉了。

最后,我想强调一点,在云服务萌芽以后,需要保持亲民才能持续发展。

我想这与许多公司的策略是不同的,大公司当然是云服务的大客户,比如 Microsoft 有非常广泛的和不同潜在大客户合作的背景和建立起来的关系,在我来到 Oracle 以后我又见识到了极度 aggressive 的销售团队。但是 Amazon 的商业策略是完全不同的,这和他们的电商背景有关,小客户一直在它们的核心目标客户群之中。因为 Amazon 做零售,卖十几块甚至几块钱的东西,因此云服务的定位,特别是定价,就是从低端路线开始的。我在 Amazon 上面买东西,退款,这方面的体验,起码在北美完全无人能及。

我有个朋友,在国内做云服务,他和我讲过,他们比较过成本和定价的关系,发现如果他们采用和 Amazon 类似的定价策略,实在是没法赚钱。我不知道在最开始的时候 Amazon 云服务在美国的开始阶段是不是赚钱,但是我知道在 Amazon 进军中国的开始阶段,被中国的付费习惯和 fraud 折腾得非常痛苦。既然提到此,在这里扯一句题外话,北美的很多商业模式照搬到中国国内,是很难成功的,我们已经见过太多这样失败的例子,虽说似乎所有人都觊觎中国这样一条大肥鱼,Amazon 自己的电商,收购卓越网以后,建库房、做物流,刚开始还可以称之为 “眼光长远”,但终究也抵不过利润上的冷清,在国内如今不断走低,网站却慢慢地、悄悄地 “淘宝化”,这方面也许我以后可以另开篇幅专门谈谈。

文末,我想思考和预测一下如今的云服务三驾马车的未来。我不觉得 Google 有能力去和微软以及 Amazon 竞争。Google 依然会很成功,依然是小众和精尖的代名词,但是对于将如此遍及生活的云服务——我只能说 DNA 层面的东西是很难改变的,它很难做到像微软和 Amazon 那样再多条战线上面如此亲民。起码在北美,你可以不断地骂微软的东西臃肿而没有品位,可以不住地抗议 Amazon 对传统零售劳动力岗位的摧残,但是你还是不断地,不断地,不断地使用微软和 Amazon 的各种产品和服务……

文章未经特殊标明皆为本人原创,未经许可不得用于任何商业用途,转载请保持完整性并注明来源链接 《四火的唠叨》

×Scan to share with WeChat

你可能也喜欢看:

  1. 实际技术选型的考虑因素
  2. 职业生涯下一站
  3. 写在 Gmail 被墙后
  4. 从“Google 地图八位版” 看国内的抄袭
  5. 常见分布式应用系统设计图解(九):协同编辑系统

4 thoughts on “为什么云计算服务是亚马逊先做出来?”

  1. 游客 says:
    10/09/2023 at 1:44 AM

    还不错

    Reply
  2. 游客 says:
    10/09/2023 at 1:41 AM

    路过

    Reply
  3. Mia says:
    08/29/2018 at 5:01 PM

    看您的文章可以学习到很多东西,谢谢前辈。

    Reply
  4. laixintao says:
    06/11/2018 at 4:13 PM

    Amazon 中国网站的设计和可用性也是电商中的一股清流,其他电商的网站上充满了死链……

    Reply

Leave a Reply to Mia Cancel reply

Your email address will not be published. Required fields are marked *

订阅·联系

四火,啰嗦的程序员一枚,现居西雅图

Amazon Google Groovy Hadoop Haskell Java JavaScript LeetCode Oracle Python Spark 互联网 前端 华为 历史 同步 团队 图解笔记 基础设施 工作 工作流 工具 工程师 应用系统 异步 微博 思考 技术 数据库 曼联 测试 生活 程序员 管理 系统设计 缓存 编码 编程范型 英语 西雅图 设计 评审 问题 面试 项目

分类

  • Algorithm and Data Structure (30)
  • Concurrency and Asynchronization (6)
  • System Architecture and Design (43)
  • Distributed System (18)
  • Tools Frameworks and Libs (13)
  • Storage and Data Access (8)
  • Front-end Development (33)
  • Programming Languages and Paradigms (55)
  • Testing and Quality Assurance (4)
  • Network and Communication (6)
  • Authentication and Authorization (6)
  • Automation and Operation Excellence (13)
  • Big Data and Machine Learning (5)
  • Product Design (7)
  • Hiring and Interviews (14)
  • Project and Team Management (14)
  • Engineering Culture (17)
  • Critical Thinking (25)
  • Career Growth (57)
  • Life Experience and Thoughts (45)

推荐文章

  • 谈谈分布式锁
  • 常见分布式系统设计图解(汇总)
  • 系统设计中的快速估算技巧
  • 从链表存在环的问题说起
  • 技术面试中,什么样的问题才是好问题?
  • 从物理时钟到逻辑时钟
  • 近期面试观摩的一些思考
  • RSA 背后的算法
  • 谈谈 Ops(汇总 + 最终篇):工具和实践
  • 不要让业务牵着鼻子走
  • 倔强的程序员
  • 谈谈微信的信息流
  • 评审的艺术——谈谈现实中的代码评审
  • Blog 安全问题小记
  • 求第 K 个数的问题
  • 一些前端框架的比较(下)——Ember.js 和 React
  • 一些前端框架的比较(上)——GWT、AngularJS 和 Backbone.js
  • 工作流系统的设计
  • Spark 的性能调优
  • “残酷” 的事实
  • 七年工作,几个故事
  • 从 Java 和 JavaScript 来学习 Haskell 和 Groovy(汇总)
  • 一道随机数题目的求解
  • 层次
  • Dynamo 的实现技术和去中心化
  • 也谈谈全栈工程师
  • 多重继承的演变
  • 编程范型:工具的选择
  • GWT 初体验
  • java.util.concurrent 并发包诸类概览
  • 从 DCL 的对象安全发布谈起
  • 不同团队的困惑
  • 不适合 Hadoop 解决的问题
  • 留心那些潜在的系统设计问题
  • 再谈大楼扔鸡蛋的问题
  • 几种华丽无比的开发方式
  • 我眼中的工程师文化
  • 观点的碰撞
  • 谈谈盗版软件问题
  • 对几个软件开发传统观点的质疑和反驳
  • MVC 框架的映射和解耦
  • 编程的未来
  • DAO 的演进
  • 致那些自嘲码农的苦逼程序员
  • Java 多线程发展简史
  • 珍爱生命,远离微博
  • 网站性能优化的三重境界
  • OSCache 框架源码解析
  • “ 你不适合做程序员”
  • 画圆画方的故事

近期评论

  • + 1.943624 BTC.NEXT - https://graph.org/Ticket--58146-05-02?hs=9a9c6f8dfe3cdbe0074006e3e640b19b& on 所有文章
  • Anonymous on 闲聊投资:亲自体验和护城河
  • 四火 on 关于近期求职的近况和思考
  • YC on 关于近期求职的近况和思考
  • mafulong on 常见分布式基础设施系统设计图解(四):分布式工作流系统
  • 四火 on 常见分布式基础设施系统设计图解(八):分布式键值存储系统
  • Anonymous on 我裸辞了
  • https://umlcn.com on 资源链接
  • Anonymous on 我裸辞了
  • Dylan on 我裸辞了
© 2025 四火的唠叨 | Powered by Minimalist Blog WordPress Theme