【译文】如何与云巨头 AWS 竞争

本文经 Stephen 先生许可翻译，转载请注明作者

“在战争中，获胜之道是避其锋芒，攻其弱点。”—— 孙子

Photo courtesy Wikipedia user 663highland, used under the CC By 2.5 license

1969 年 1 月，离人类首次登月的阿波罗11号任务还有7个月时间。尽管IBM在此项任务中扮演了举足轻重的角色，美国司法部仍对它提起了反垄断诉讼。诉讼内容包括IBM垄断了“跨州贸易和商业活动的通用电子计算机”。这个案子拖了13年，直到1982年被撤销。

毫无疑问在 1969 年，主宰了市场的IBM被认为是无懈可击的。据统计，它在企业硬件领域的市场份额超过了 70%。但就在10年多一点后，即使是竞争对手也承认这个诉讼“几乎只剩一点历史的猎奇心”，因为这个行业正在快速从IBM 主导的大型机转向个人电脑。

讽刺的是，这一切都是 IBM 自己促成的。

• 第一步是该公司在 1969 年 6 月 23 日决定将软件与硬件分离——该决定部分是受到上述 1969 年 1 月诉讼案的影响。IBM决定减少其反垄断案的攻击面，其副作用就是诞生了我们今天所谓的软件产业。
• 其次是IBM作为个人电脑业务的后来者（译者：苹果于1977年发布了深受好评的Apple II），在1980年决定将大部分业务外包出去，最显著的是操作系统。为此他们求助于一家名为微软的鲜为人知的公司，开发后来被称为 PC-DOS 的软件，而该软件又是从另一家鲜为人知的公司（Seattle Computer Products）授权而来。在这笔交易中，微软跟 IBM 的合同不是排他的，它可以将操作系统卖给第三方。

很显然，微软意识到了专注于硬件的 IBM 没想到的：软件可以比它所运行的硬件更有价值。微软由此实现了一家科技公司前所未有的财务成功。

但Redmond的软件巨头，随着时间流逝，也丢掉了自己的市场。首先是互联网，尽管盖茨的全力尝试。然后是移动互联网，让位给了另一个重要玩家苹果。甚至在云最开始的那些年，微软似乎也错失了机会，但后来有所恢复并且找到了很好的定位，稍后将对此进行讨论。

从这些例子中至少可以学到两个经验教训：

• 首先，那些看起来无可匹敌并且被期望永远主宰市场的科技公司从没做到这点。
• 其次，市场竞争从不正面到来：微软在大型机市场上并没有超过 IBM，就像苹果在桌面和服务器操作系统市场上并没有超过微软一样。

所有这些都把我们带回到亚马逊和此文的标题。

在亚马逊 11 月份的年度 re：Invent 大会上，一位竞争对手的高管提出了一个问题，这个问题以前也被其他主要供应商问过：AWS会无限期地主宰市场吗？事实上，有谁能与 AWS 的市场势头竞争？

历史对这个问题的回答掷地有声：正如太阳会升起与落下，帝国也有兴衰轮回。

但这听起来很抽象。更具体地说，此时此地，如何才能最好地与AWS竞争？我们想到了本文开头的来自《孙子兵法》的格言。这本军事战略手册，由中国汉朝早期的将军孙子撰写，几十年来在商业到体育等各种各样的背景下都广受欢迎，其中提到的内容已经接近陈词滥调。但出于同样的原因，孙子的格言对于想要跟AWS竞争的公司也许是最好的建议，被大多数人依然忽略的建议。

在 IBM 和微软统治周期的顶峰时期，有许多潜在的竞争者试图在两家公司最强大的领域与它们竞争。这要么是赌某个竞争对手能够生产出明显更好的替代品（例如 Amdahl），要么是通过提供大致相当的产品，通过更低的价格或其他机制加以区分（例如 http://OpenOffice.org）。这种方法的困难在于，消费者的惰性非常难以克服。具有竞争力的产品不能只是稍微好一点或者更便宜，它们必须格外好。即使在这种情况下，也很难实质性地改变购买行为，这受到外部因素的影响，如捆绑销售、企业许可协议、员工经验和培训等。

值得注意的是，那些被颠覆掉的曾占统治地位的技术公司中，没有一家是败于在它们几乎垄断或者垄断的市场中与它们竞争的对手的。

所有这些都表明，AWS 真正的竞争对手不会是那些只提供与亚马逊相同服务的企业，而是那些更好、更便宜或两者兼而有之的企业。然而，尽管 AWS 的业务范围很广，考虑到新服务出现的速度，什么领域可以合理地被认为不属于公司目前的能力范围？

换句话说，AWS 的优势在哪里？它们的弱点在哪里？

历史上 AWS 的大多数竞争对手，当然还有那些仍然留在这个领域的公司，尽管有上面的教训，都试图遵循AWS的基础设施组件策略。虽然没有一家能与亚马逊提供的服务量相提并论，但是由于客户需要诸如计算、存储、管理数据库服务等基础服务，谷歌、微软和其他公司已经加快了提供这些服务的步伐。

认识到客户的惯性已让先行者得利，AWS的追赶者们谈论更多的是补充而不是替代。无论是帮不希望受制于单一技术供应商的客户提防AWS，还是为了可靠性目的实现基础设施的多样化，非 AWS 云供应商正在推动一个多云供应商共存的世界。这就解释了为什么多云抢走了混合云的风头，后者至今仍被视为一个定义不清、被误解的包罗万象的概念。这也是为什么 AWS 营销仅仅提到了多云。

尽管成为 AWS 的可靠替代供应商本身就是一项可观的大生意，但从定义上讲，它不会产生 IBM、微软和其他公司在此之前就已经实现的巨大回报—— 即使云计算基础设施这一混合概念允许超级规模的供应商打开硬件和软件收入的阀门，这即便在大型机捆绑销售的日子里也是很难实现的。

如果竞争对手已经在紧追 AWS 的脚步，这家公司还有哪里可以走呢？哪里找到机会去攻击它的弱点，或者至少是相对弱点？

从产品组合的宽度看，无论是创新速度和规模化能力，AWS在这个爆炸的行业里，毫无敌手。但从经验来看，AWS也肯定有瑕疵的。

1. 它的开发者体验从来都不是一流的；它的成功是因为它领先的服务和先发优势。
2. 与此同时，它的重心明显在 Post-deployment （后部署）。尽管已经进入了开发流程和版本控制等市场多年，AWS依然被当做部署环境的首选。它的开发者工具则相差很远，除了极少数AI相关的工具。
3. 反常识的，AWS 产品组合的优势在某些情况下也是一种劣势。服务蔓延如此严峻，以至于一些重点的AWS客户也经常不知道有哪些现有和新的服务。
4. 自从十年前推出 RDS 服务以来，虽然 AWS 敏锐地预见到人们对完全托管服务的需求不断上升，但迄今为止，AWS 在很大程度上仅限于提供单独的服务或集合。
5. 无论是从开发还是市场营销的角度来看，组织结构都是为自主和完全独立的服务高度优化的。它不太适合广泛的、多领域的综合解决方案。

当然，AWS 的自身背景只是问题的一部分。市场条件又怎样？AWS 是在怎样的环境下运营和提供体验的？

这里最重要的就是碎片化。在过去十年创造的过程中，新技术一个接一个加速到来，更头痛的，一个新类别接着另一个新类别，已经开始超越企业消化它们的能力。甚至开发者也开始面对日益增长的财富带来的尴尬。

用 AWS 的术语来说，加速的碎片化是否会带来独特的挑战。亚马逊吸引人的关键在于，每个人都被训练成期待并喜欢基础组件（Primitives）。如果这个不再成立了呢？当组件数量还少的时候，通过基础组件的DIY方式完全合理。但如果每年11月都有数以百计新服务被添加到已经非常庞大的业务组合中，DIY方法还能扩张吗？期望买家、开发者或者双方不仅要管理AWS 目录日益增长的复杂性，还要管理构建、测试和向亚马逊平台交付安全软件所必需的大量零件，这合理吗？

在许多情况下，答案是肯定的。开发者和与他们合作的企业已经花费了太多的时间获得基础构件块，以至于不能轻易放弃它们，这意味着 DIY 风格的产品市场仍将保持强劲。

但似乎不太可能的是，这种做法会作为唯一可规模化的方式永远保持下去。很明显，当下很少有理由自己管理一个电子邮件服务器或者数据库基础设施。曾经关注速度的各方，会开始关注维护这些越来越复杂的，由多个单独服务构成的系统有啥好处。这反过来会为“整合式创新（Integrated Innovation）”创造机会，这个早被遗弃的概念或许过几个季度会再次流行起来。

有趣的是，创造这个术语的公司（译者：微软在04年提出整合式创新概念）可能是利用这个机会窗口的最佳人选。想想看：

1. 无论其产品有什么局限性，微软——就像亚马逊——是一家一直关注开发者需求的公司。与亚马逊不同，微软在开发工具方面的历史非常优秀。
2. 为了改进开发者体验并减少碎片化，必须从项目开始一直延伸到部署和运营。AWS 在部署后的覆盖范围无与伦比，其部署前的覆盖面则非常有限。相比之下，微软拥有 GitHub，该公司近年来通过 Actions 等产品和 Semmle 等收购交易大幅拓展了业务范围。
3. 亚马逊实际上无限的野心给合作伙伴关系带来了挑战，并且使得像我的同事提出的“除亚马逊之外的任何人”的联盟更有可能。

至关重要的是，为了提供一个完全集成的体验，你需要拥有软件的起源和目的地，并在两者之间架起一座桥梁。AWS 拥有大部分（如果不是全部）所需的服务，但是着重在目的侧。在 GitHub、GitHub Actions 和 Azure 中，微软拥有三个必要的基本构件，它们的成功和可见性比 AWS 更成比例。

因此有没有可能设想这样一个世界——微软与亚马逊之间的竞争不是通过向市场推出更广泛、更快或更廉价的基础设施部件，而是通过从开发初期到推广再到生产的更完整的开发体验？有 75 亿个理由相信这个问题的答案是肯定的。

无论是微软还是其他竞争者，当他们试图寻找AWS的弱点而不是强项去竞争时，他们都应该听取孙子的另一条建议。

“难知如阴，动如雷震。”

如果说AWS 自成立以来证明了一件事，那就是他们可以非常快速地行动。一旦他们开始把缺乏更高层次的抽象看作是一种缺陷，不要期望他们长期保持这种状态，无论他们的组织结构限制是什么。

申明：亚马逊，GitHub，IBM 和微软都是 RedMonk 的客户。谷歌目前还不是客户。

关于作者

Stephen O’Grady 是知名专注于开发者行业的分析公司RedMonk 的联合创始人，在RedMonk， Stephen 和诸如 IBM、DELL、VMWare、RedHat 等IT公司合作解决各种问题。有超过十多年的丰富经验，他写过两本很著名的书籍：《软件悖论:商业软件的崛起与陨落》和 《The new kingmaker》，文章经常被各大财经媒体引用，如纽约时报、NPR、波士顿全球、华尔街日报等，他也是各种会议的主持人和受欢迎的演讲者。

关于译者

陈哲,英文名 Peter ，晨兴资本副总裁，曾就职于Google，BlackBerry，担任高级工程师。专注智能制造、人工智能及黑科技领域。