We spend enormous energy thinking about how to empower builders, inside and outside of our company. We characterize builders as people who like to invent. They like to dissect a customer experience, assess what’s wrong with it, and reinvent it. Builders tend not to be satisfied until the customer experience is perfect. This doesn’t hinder them from delivering improvements along the way, but it drives them to keep tinkering and iterating continually. While unafraid to invent from scratch, they have no hesitation about using high-quality, scalable, cost-effective components from others. What matters to builders is having the right tools to keep rapidly improving customer experiences.
我们投入大量精力思考如何赋能公司内外的建设者。我们将建设者定义为喜欢创新的人。他们喜欢剖析客户体验,评估其中的问题,并重新设计。建设者往往在客户体验达到完美之前不会满足。这并不会妨碍他们在过程中持续提供改进,但会驱使他们不断地调整和迭代。虽然他们不惧怕从零开始创新,但也毫不犹豫地使用来自他人的高质量、可扩展且经济高效的组件。对建设者而言,重要的是拥有合适的工具,以持续快速地改善客户体验。
The best way we know how to do this is by building primitive services. Think of them as discrete, foundational building blocks that builders can weave together in whatever combination they desire. Here’s how we described primitives in our 2003 AWS Vision document:
我们所知的最佳方法是构建原始服务。可以将它们视为独立的、基础的构建模块,开发人员可以根据自己的需求任意组合。这是我们在 2003 年 AWS 愿景文档中对原始服务的描述:
“Primitives are the raw parts or the most foundational-level building blocks for software developers. They’re indivisible (if they can be functionally split into two they must) and they do one thing really well. They’re meant to be used together rather than as solutions in and of themselves. And, we’ll build them for maximum developer flexibility. We won’t put a bunch of constraints on primitives to guard against developers hurting themselves. Rather, we’ll optimize for developer freedom and innovation.”
Primitives是软件开发人员使用的原始组件或最基础级别的构建模块。它们是不可分割的(如果能在功能上拆分成两个,就必须拆分),并且专注于做好一件事。它们旨在相互配合使用,而不是单独作为解决方案。此外,我们将构建它们以实现开发人员的最大灵活性。我们不会对Primitives施加大量限制来防止开发人员犯错,而是会优化开发人员的自由度和创新空间。
Of course, this concept of primitives can be applied to more than software development, but they’re especially relevant in technology. And, over the last 20 years, primitives have been at the heart of how we’ve innovated quickly.
当然,这种Primitives的概念不仅适用于软件开发领域,但在技术领域尤为重要。在过去的 20 年里,Primitives一直是我们快速创新的核心。
One of the many advantages to thinking in primitives is speed. Let me give you two counter examples that illustrate this point. First, we built a successful owned-inventory retail business in the early years at Amazon where we bought all our products from publishers, manufacturers, and distributors, stored them in our warehouses, and shipped them ourselves. Over time, we realized we could add broader selection and lower prices by allowing third-party sellers to list their offerings next to our own on our highly trafficked search and product detail pages. We’d built several core retail services (e.g. payments, search, ordering, browse, item management) that made trying different marketplace concepts simpler than if we didn’t have those components. A good set of primitives? Not really.
以基础元素的方式思考的众多优势之一是速度。我举两个反例来说明这一点。首先,在亚马逊的早期阶段,我们建立了一个成功的自营库存零售业务,我们从出版商、制造商和分销商那里购买所有产品,将其存储在自己的仓库中,并自行发货。随着时间推移,我们意识到,通过允许第三方卖家在我们流量巨大的搜索和产品详情页面上与我们自己的商品并列展示,我们可以提供更广泛的选择和更低的价格。我们已经构建了几个核心零售服务(例如支付、搜索、订购、浏览、商品管理),这些服务使我们尝试不同的市场模式变得比没有这些组件时更简单。但这算是一套好的基础元素吗?并不是。
It turns out that these core components were too jumbled together and not partitioned right. We learned this the hard way when we partnered with companies like Target in our Merchant.com business in the early 2000s. The concept was that target.com would use Amazon’s ecommerce components as the backbone of its website, and then customize however they wished. To enable this arrangement, we had to deliver those components as separable capabilities through application programming interfaces (“APIs”). This decoupling was far more difficult than anticipated because we’d built so many dependencies between these services as Amazon grew so quickly the first few years.
事实证明,这些核心组件过于混杂,没有正确地进行分割。我们是在 2000 年代初与 Target 等公司合作开展 Merchant.com 业务时,才艰难地意识到这一点。当时的设想是,target.com 将使用亚马逊的电子商务组件作为其网站的基础架构,然后根据自身需求进行定制。为了实现这一安排,我们必须通过应用程序接口(API)将这些组件作为可分离的功能提供出去。然而,这种解耦的难度远超预期,因为在亚马逊最初几年快速增长过程中,我们在这些服务之间建立了太多的依赖关系。
This coupling was further highlighted by a heavyweight mechanism we used to operate called “NPI.” Any new initiative requiring work from multiple internal teams had to be reviewed by this NPI cabal where each team would communicate how many people-weeks their work would take. This bottleneck constrained what we accomplished, frustrated the heck out of us, and inspired us to eradicate it by refactoring these ecommerce components into true primitive services with well-documented, stable APIs that enabled our builders to use each other’s services without any coordination tax.
这种耦合关系在我们过去使用的一种名为“NPI”的繁重机制中尤为突出。任何需要多个内部团队协作的新项目,都必须经过这个 NPI 小组的审查,每个团队都要说明他们的工作需要多少人周。这种瓶颈限制了我们的成就,让我们极为沮丧,并促使我们通过将这些电子商务组件重构为真正的基础服务,配备文档完善、稳定的 API,使开发人员能够在无需额外协调成本的情况下使用彼此的服务,从而彻底消除这种瓶颈。
In the middle of the Target and NPI challenges, we were contemplating building a new set of infrastructure technology services that would allow both Amazon to move more quickly and external developers to build anything they imagined. This set of services became known as AWS, and the above experiences convinced us that we should build a set of primitive services that could be composed together how anybody saw fit. At that time, most technology offerings were very feature-rich, and tried to solve multiple jobs simultaneously. As a result, they often didn’t do any one job that well.
在应对 Target 和 NPI 挑战的过程中,我们曾考虑构建一套新的基础设施技术服务,以便亚马逊能够更快地行动,同时也让外部开发者能够构建他们所设想的任何东西。这套服务后来被称为 AWS,上述经验使我们确信,我们应该构建一系列基础服务,让任何人都可以根据自己的需求自由组合。当时,大多数技术产品都功能繁多,试图同时解决多个问题,因此往往无法很好地完成任何单一任务。
Our AWS primitive services were designed from the start to be different. They offered important, highly flexible, but focused functionality. For instance, our first major primitive was Amazon Simple Storage Service (“S3”) in March 2006 that aimed to provide highly secure object storage, at very high durability and availability, at Internet scale, and very low cost. In other words, be stellar at object storage. When we launched S3, developers were excited, and a bit mystified. It was a very useful primitive service, but they wondered, why just object storage? When we launched Amazon Elastic Compute Cloud (“EC2”) in August 2006 and Amazon SimpleDB in 2007, people realized we were building a set of primitive infrastructure services that would allow them to build anything they could imagine, much faster, more cost-effectively, and without having to manage or lay out capital upfront for the datacenter or hardware. As AWS unveiled these building blocks over time (we now have over 240 at builders’ disposal—meaningfully more than any other provider), whole companies sprang up quickly on top of AWS (e.g. Airbnb, Dropbox, Instagram, Pinterest, Stripe, etc.), industries reinvented themselves on AWS (e.g. streaming with Netflix, Disney+, Hulu, Max, Fox, Paramount), and even critical government agencies switched to AWS (e.g. CIA, along with several other U.S. Intelligence agencies). But, one of the lesser-recognized beneficiaries was Amazon’s own consumer businesses, which innovated at dramatic speed across retail, advertising, devices (e.g. Alexa and Fire TV), Prime Video and Music, Amazon Go, Drones, and many other endeavors by leveraging the speed with which AWS let them build. Primitives, done well, rapidly accelerate builders’ ability to innovate.
我们的 AWS 基础服务从一开始就被设计成与众不同。它们提供了重要、高度灵活但专注的功能。例如,我们的第一个主要基础服务是 2006 年 3 月推出的亚马逊简单存储服务(“S3”),旨在以互联网规模、极低的成本提供高度安全的对象存储,具有极高的耐用性和可用性。换句话说,就是在对象存储方面做到卓越。当我们推出 S3 时,开发人员感到兴奋,也有些困惑。这是一个非常有用的基础服务,但他们疑惑,为什么只提供对象存储?当我们在 2006 年 8 月推出亚马逊弹性计算云(“EC2”)以及 2007 年推出亚马逊 SimpleDB 时,人们意识到我们正在构建一系列基础设施服务,使他们能够更快、更经济地构建任何他们能想象的东西,而无需提前管理或投入资金建设数据中心或硬件。 随着 AWS 逐步推出这些构建模块(目前我们已为开发者提供超过 240 个模块,远超其他任何供应商),许多公司迅速在 AWS 之上建立起来(例如 Airbnb、Dropbox、Instagram、Pinterest、Stripe 等),一些行业在 AWS 上实现了自我重塑(例如 Netflix、Disney+、Hulu、Max、Fox、Paramount 等流媒体服务),甚至一些关键的政府机构也转向了 AWS(例如 CIA 以及其他几个美国情报机构)。但较少被注意到的受益者之一是亚马逊自身的消费者业务,它们通过利用 AWS 提供的快速构建能力,在零售、广告、设备(例如 Alexa 和 Fire TV)、Prime 视频和音乐、Amazon Go、无人机以及许多其他领域实现了高速创新。基础模块若设计得当,将极大地加速开发者的创新能力。
So, how do you build the right set of primitives?
那么,你该如何构建合适的primitives集合呢?
Pursuing primitives is not a guarantee of success. There are many you could build, and even more ways to combine them. But, a good compass is to pick real customer problems you’re trying to solve.
追求基础元素并不能保证成功。你可以构建许多基础元素,也有更多方式将它们组合起来。但一个好的指南针是选择你试图解决的真实客户问题。
Our logistics primitives are an instructive example. In Amazon’s early years, we built core capabilities around warehousing items, and then picking, packing, and shipping them quickly and reliably to customers. As we added third-party sellers to our marketplace, they frequently requested being able to use these same logistics capabilities. Because we’d built this initial set of logistics primitives, we were able to introduce Fulfillment by Amazon (“FBA”) in 2006, allowing sellers to use Amazon’s Fulfillment Network to store items, and then have us pick, pack, and ship them to customers, with the bonus of these products being available for fast, Prime delivery. This service has saved sellers substantial time and money (typically about 70% less expensive than doing themselves), and remains one of our most popular services. As more merchants began to operate their own direct-to-consumer (“DTC”) websites, many yearned to still use our fulfillment capabilities, while also accessing our payments and identity primitives to drive higher order conversion on their own websites (as Prime members have already shared this payment and identity information with Amazon). A couple years ago, we launched Buy with Prime to address this customer need. Prime members can check out quickly on DTC websites like they do on Amazon, and receive fast Prime shipping speeds on Buy with Prime items—increasing order conversion for merchants by ~25% vs. their default experience.
我们的物流基础模块就是一个很有启发性的例子。在亚马逊成立初期,我们围绕商品仓储建立了核心能力,然后快速可靠地完成拣货、包装和配送给客户。当我们向市场引入第三方卖家时,他们经常要求使用这些相同的物流能力。正因为我们已经建立了这一套初始的物流基础模块,我们才能在 2006 年推出“亚马逊物流(FBA)”,允许卖家使用亚马逊的物流网络存储商品,然后由我们负责拣货、包装并配送给客户,同时这些商品还能享受快速的 Prime 配送服务。这项服务为卖家节省了大量的时间和成本(通常比他们自己操作便宜约 70%),并且至今仍是我们最受欢迎的服务之一。随着越来越多的商家开始运营自己的直面消费者(DTC)网站,许多商家仍然希望使用我们的物流能力,同时也希望利用我们的支付和身份基础模块,以提高他们自己网站上的订单转化率(因为 Prime 会员已经与亚马逊共享了这些支付和身份信息)。 几年前,我们推出了 Buy with Prime,以满足客户的这一需求。Prime 会员可以像在亚马逊上一样,在 DTC 网站上快速结账,并在购买 Buy with Prime 商品时享受 Prime 的快速配送服务,这使商家的订单转化率比默认体验提高了约 25%。
As our Stores business has grown substantially, and our supply chain become more complex, we’ve had to develop a slew of capabilities in order to offer customers unmatched selection, at low prices, and with very fast delivery times. We’ve become adept at getting products from other countries to the U.S., clearing customs, and then shipping to storage facilities. Because we don’t have enough space in our shipping fulfillment centers to store all the inventory needed to maintain our desired in-stock levels, we’ve built a set of lower-cost, upstream warehouses solely optimized for storage (without sophisticated end-user, pick, pack, and ship functions). Having these two pools of inventory has prompted us to build algorithms predicting when we’ll run out of inventory in our shipping fulfillment centers and automatically replenishing from these upstream warehouses. And, in the last few years, our scale and available alternatives have forced us to build our own last mile delivery capability (roughly the size of UPS) to affordably serve the number of consumers and sellers wanting to use Amazon.
随着我们的门店业务大幅增长,供应链也变得更加复杂,我们不得不开发大量能力,以便为客户提供无与伦比的选择、低廉的价格和极快的配送速度。我们已熟练掌握了将产品从其他国家运往美国、清关并运送至仓储设施的流程。由于我们的配送履约中心没有足够空间存放所有库存以维持理想的库存水平,我们建立了一系列成本较低的上游仓库,专门用于存储(不具备复杂的终端用户拣货、包装和配送功能)。拥有这两类库存促使我们开发算法,预测配送履约中心何时会缺货,并自动从这些上游仓库补货。此外,过去几年中,我们的规模和可用的替代方案迫使我们建立了自己的最后一公里配送能力(规模大致相当于 UPS),以经济高效地服务于希望使用亚马逊的众多消费者和卖家。
We’ve solved these customer needs by building additional fulfillment primitives that both serve Amazon consumers better and address external sellers’ increasingly complex ecommerce activities. For instance, for sellers needing help importing products, we offer a Global Mile service that leverages our expertise here. To ship inventory from the border (or anywhere domestically) to our storage facilities, we enable sellers to use either our first-party Amazon Freight service or third-party freight partners via our Partnered Carrier Program. To store more inventory at lower cost to ensure higher in-stock rates and shorter delivery times, we’ve opened our upstream Amazon Warehousing and Distribution facilities to sellers (along with automated replenishment to our shipping fulfillment centers when needed). For those wanting to manage their own shipping, we’ve started allowing customers to use our last mile delivery network to deliver packages to their end-customers in a service called Amazon Shipping. And, for sellers who wish to use our fulfillment network as a central place to store inventory and ship items to customers regardless of where they ordered, we have a Multi-Channel Fulfillment service. These are all primitives that we’ve exposed to sellers.
我们通过构建额外的履约基础设施,既更好地服务亚马逊消费者,也满足外部卖家日益复杂的电子商务活动,从而解决了这些客户需求。例如,对于需要帮助进口产品的卖家,我们提供了利用我们专业知识的 Global Mile 服务。为了将库存从边境(或国内任何地方)运送到我们的仓储设施,我们允许卖家通过我们的合作承运商计划,使用亚马逊自营货运服务或第三方货运合作伙伴。为了以更低成本存储更多库存,确保更高的库存率和更短的交货时间,我们向卖家开放了上游的亚马逊仓储和配送设施(并在需要时自动补货到我们的配送中心)。对于希望自行管理运输的客户,我们开始允许他们使用我们的末端配送网络,将包裹送达终端客户,这项服务称为 Amazon Shipping。 此外,对于希望使用我们的配送网络作为集中存储库存并向客户发货(无论客户从何处下单)的卖家,我们提供了多渠道配送服务。这些都是我们向卖家开放的基础服务。
Building in primitives meaningfully expands your degrees of freedom. You can keep your primitives to yourself and build compelling features and capabilities on top of them to allow your customers and business to reap the benefits of rapid innovation. You can offer primitives to external customers as paid services (as we have with AWS and our more recent logistics offerings). Or, you can compose these primitives into external, paid applications as we have with FBA, Buy with Prime, or Supply Chain by Amazon (a recently released logistics service that integrates several of our logistics primitives). But, you’ve got options. You’re only constrained by the primitives you’ve built and your imagination.
有意义地构建基础组件能够极大地拓展你的自由度。你可以将这些基础组件保留在内部,并在其基础上开发出引人注目的功能和能力,让你的客户和业务从快速创新中获益。你也可以将基础组件作为付费服务提供给外部客户(例如我们推出的 AWS 和近期的物流服务)。或者,你可以将这些基础组件组合成面向外部的付费应用程序,就像我们推出的 FBA、“Buy with Prime”或亚马逊供应链(最近发布的一项物流服务,整合了我们多个物流基础组件)。总之,你拥有多种选择,唯一的限制是你所构建的基础组件和你的想象力。
Take the new, same-day fulfillment facilities in our Stores business. They’re located in the largest metro areas around the U.S. (we currently have 58), house our top-moving 100,000 SKUs (but also cover millions of other SKUs that can be injected from nearby fulfillment centers into these same-day facilities), and streamline the time required to go from picking a customer’s order to being ready to ship to as little as 11 minutes. These facilities also constitute our lowest cost to serve in the network. The experience has been so positive for customers that we’re planning to double the number of these facilities.
以我们门店业务中新建的当日配送设施为例,它们位于美国各大都市区(目前共有 58 个),存放着我们销量最高的 10 万个库存单位(SKU),同时还能从附近的配送中心调入数百万个其他 SKU 到这些当日配送设施中。这些设施将从拣选客户订单到准备发货的时间缩短至最快仅需 11 分钟。此外,这些设施也是我们网络中服务成本最低的部分。由于客户体验非常积极,我们计划将这些设施的数量增加一倍。
But, how else might we use this capability if we think of it as a core building block? We have a very large and growing grocery business in organic grocery (with Whole Foods Market) and non-perishable goods (e.g. consumables, canned goods, health and beauty products, etc.). We’ve been working hard on building a mass, physical store offering (Amazon Fresh) that offers a great perishable experience; however, what if we used our same-day facilities to enable customers to easily add milk, eggs, or other perishable items to any Amazon order and get same day? It might change how people think of splitting up their weekly grocery shopping, and make perishable shopping as convenient as non-perishable shopping already is.
但是,如果我们将这种能力视为一个核心基础模块,我们还能如何利用它呢?我们在有机食品杂货(通过 Whole Foods Market)和非易腐商品(例如日用品、罐头食品、健康和美容产品等)领域拥有规模庞大且不断增长的业务。我们一直在努力打造大规模的实体店(Amazon Fresh),提供出色的生鲜购物体验;然而,如果我们利用当天配送设施,让顾客能够轻松地在任何亚马逊订单中添加牛奶、鸡蛋或其他易腐商品,并实现当天送达,会怎样呢?这可能会改变人们对每周杂货购物分配方式的看法,使购买易腐商品变得像购买非易腐商品一样方便。
Or, take a service that some people have questioned, but that’s making substantial progress and we think of as a very valuable future primitive capability—our delivery drones (called Prime Air). Drones will eventually allow us to deliver packages to customers in less than an hour. It won’t start off being available for all sizes of packages and in all locations, but we believe it’ll be pervasive over time. Think about how the experience of ordering perishable items changes with sub-one-hour delivery?
或者,以一项曾被一些人质疑但正取得重大进展、并被我们视为极具价值的未来基础能力的服务为例——我们的无人机送货服务(称为 Prime Air)。无人机最终将使我们能够在不到一小时内将包裹送达客户手中。虽然最初并非所有尺寸的包裹和所有地点都能享受此服务,但我们相信随着时间推移,它将变得普及。试想一下,不到一小时的送货速度将如何改变订购易腐商品的体验?
The same is true for Amazon Pharmacy. Need throat lozenges, Advil, an antibiotic, or some other medication? Same-day facilities already deliver many of these items within hours, and that will only get shorter as we launch Prime Air more expansively. Highly flexible building blocks can be composed across businesses and in new combinations that change what’s possible for customers.
亚马逊药房也是如此。需要喉糖、布洛芬、抗生素或其他药物吗?当天送达服务已经能在数小时内配送许多此类商品,随着我们更广泛地推出 Prime Air,这一时间还会进一步缩短。高度灵活的基础模块可以跨业务组合,并以新的方式组合,改变客户的可能性。
Being intentional about building primitives requires patience. Releasing the first couple primitive services can sometimes feel random to customers (or the public at large) before we’ve unveiled how these building blocks come together. I’ve mentioned AWS and S3 as an example, but our Health offering is another. In the last 10 years, we’ve tried several Health experiments across various teams—but they were not driven by our primitives approach. This changed in 2022 when we applied our primitives thinking to the enormous global healthcare problem and opportunity. We’ve now created several important building blocks to help transform the customer health experience: Acute Care (via Amazon Clinic), Primary Care (via One Medical), and a Pharmacy service to buy whatever medication a patient may need. Because of our growing success, Amazon customers are now asking us to help them with all kinds of wellness and nutrition opportunities—which can be partially unlocked with some of our existing grocery building blocks, including Whole Foods Market or Amazon Fresh.
有意识地构建基础模块需要耐心。在我们尚未展示这些基础模块如何组合之前,向客户(或广大公众)发布最初几个基础服务,有时可能会显得随意。我之前提到过 AWS 和 S3 作为例子,但我们的健康服务也是如此。在过去 10 年里,我们在不同团队中尝试了几次健康领域的实验,但这些尝试并未遵循我们的基础模块方法。这种情况在 2022 年发生了改变,我们将基础模块思维应用于全球医疗保健领域的巨大问题和机遇。现在,我们已经创建了几个重要的基础模块,以帮助改善客户的健康体验:急性护理(通过 Amazon Clinic)、初级护理(通过 One Medical)以及药房服务,以便患者购买所需的任何药物。由于我们日益增长的成功,亚马逊的客户现在要求我们帮助他们探索各种健康和营养方面的机会,而这些机会可以部分通过我们现有的一些食品杂货基础模块来实现,包括 Whole Foods Market 或 Amazon Fresh。