In Part I of this four-part series focused on people, namely developers who are the most important demographic in the technology-driven Globalization 2.0 that we are heading into.

In Globalization 2.0, developers drive innovation from the bottom up, and the companies new and old rely on them to “technologize” themselves in order to survive and thrive. This transformation happens both externally and internally. The one product concept that facilitates this future on a global scale is APIs (application programming interfaces).

That’s the focus of this Part II.

APIs are an effective abstraction that empowers developers to build quickly and safely. It is also a killer product delivery and consumption mechanism. The so-called “API Economy” is real. And APIs are “global by nature”.

Global Resource Access

There are many technical definitions of APIs you can find on the Internet. The plain-language working definition I use is: “a common way to get resources to build things.”

APIs can either be used by human developers or other APIs -- machines interacting with machines. What “resource” means in this lens is broad but tangible, because there are many kinds of resources an API can extract. Data is a resource. Specific tasks -- delivery tracking, navigation, paying bills -- are resources. Daily activities -- texting, calling, video conferencing -- are all resources.

To drill in on data (pun intended) for a moment, if the “data is oil” analogy holds up, then APIs are not only the rigs that help you extract the raw petroleum, but also process, refine, and package them into gas that people can pump into their cars.

APIs are global by nature, because most are excavating resources or enabling human needs that are region-agnostic, culture-agnostic, and language-agnostic. Human needs are messy, so having an API layer abstracting away the messiness is immensely valuable. Once that abstraction reaches some maturity, it’s quite natural for developers, who already have a global mindset (see Part I for why), to leverage those same APIs to serve a global audience quickly.

Interestingly, well-designed APIs can also abstract the differences between jurisdictions or regulatory regimes, making them powerful for developers to build global services faster but safely, without tripping over regulatory and compliance issues.

Take financial services for example. Each country, region, and even states within the United States have some differences in the way financial activities are conducted and regulated. Payment and financial services APIs, provided by companies like Stripe, abstract those differences away, so developers only need to learn and use that set of APIs to build applications with a financial component to serve users across multiple jurisdictions. This is possible on a technical level (though by no means easy), because an API is a contract-based system. An API typically encodes a set of rules describing what kind of resources can or cannot be accessed by whom and how often, plus some exceptions. This structure maps well to regulations, which is more or less also a set of rules about who can access or do what, with some exceptions.

This way of mapping rules and complexities into an abstraction is also increasingly common inside companies looking to “technologize” their internal organizations, which is typically governed by a set of corporate rules. The output of say the Tesla “internal application team”, which I referenced in Part I, would be a set of APIs designed to help Tesla developers access internal resources.

Of course, APIs are not the only form of common abstraction or pattern in technology development. What makes it different from an investment and opportunity perspective?

Sticky Product Standard

What separates APIs from other methods of abstraction is their potential to become a sticky product standard that developers gravitate to for a long time. When that’s achieved, value is disproportionately accrued to the company that designs, updates, and maintains that API.

This potential is not commonly recognized, even within the tech community. As RedMonk, the developer-focused analyst firm, wrote in early 2019 during a time when many commercial open source companies are re-licensing their codebase to fend off competition from large cloud platforms like AWS:

APIs are increasingly of greater importance than the code that instantiates them.

APIs are products, code is not. Thus, APIs possess more inherent value to developers than the code that built them. The underlying code that implements APIs are important, but not often relevant on a day-to-day basis. This phenomenon is most clearly observable in the cloud industry, where compatibility to already-popular APIs is a common strategy to gain developer buy-in and adoption for a different, often competing product. Some examples:

  • AWS DynamoDB and Azure CosmosDB’s compatibility with MongoDB API
  • AWS Aurora’s compatibility with MySQL and Postgres API
  • GCP Memorystore’s compatibility with Redis API

I only named a few examples by cloud giants. There are many more examples of smaller startups taking the same approach. These “compatibility targets” all have open source versions that could’ve been forked and replicated on the codebase level. But API compatibility is the preferred approach, because of the stickiness of APIs as a product standard.

While the “API Economy” is still young, we are seeing some category winners emerging. How can you find the winners? By looking at where the trend of standardization is happening toward or the “compatibility targets”. We already mentioned MongoDB above. Twilio is another one. Agora could be another. Not surprisingly, all these companies have a global presence, because APIs are global by nature. (See Part IV for deep dives on some of these companies.)

Delivery and Consumption, the API way

Two hallmarks of APIs make their delivery and consumption super developer-friendly: self-service and pay as you use. Because of these two characteristics, a set of APIs can spread like wildfire among developers everywhere.

Self-service: The best-designed APIs can become useful within a few minutes. By simply reading the documentation and self-setup a simple environment to make some API requests, a developer can get some resources out of these APIs right away. There’s no need to ask for someone else’s permission or wait for the environment to be provisioned by, say, another department in your company. This experience makes developer experimentation, adoption, and, eventually, standardization a natural trajectory.

To be sure, delivering this type of experience is the nirvana that takes years to refine. Many API products never get there. It’s a multi-functional effort that not only requires good technology choices and product designs, but also effective human-to-human communication via documentations, tutorials, and other educational resources. There are initiatives like OpenAPI to facilitate common specifications and best practices, but the entire space is still complex and fragmented, thus full of challenges and opportunities.

Pay as you use: The API way to consume a product is pay as you use, giving developers both the flexibility and affordability to experiment, prototype, and build their ideas. This low barrier to entry is critical. In the pre-developer-driven, pre-API-driven days, such experimentation would require a top-down, bureaucratic budget allocation process, multiple layers of sign-offs from managers, along with a hefty procurement burden. All this could take months if not more than a year to complete. Now it’s easy for a small development team to put the initial cost of a few self-service APIs on a credit card, with a small price tag that won’t be hard for most managers to reimburse later. The smart managers in a fully “technologized” company would have a small budget set aside dedicated to encouraging these experiments. Most API-driven products also offer a free tier consumption limit that’s generous enough to build a functioning prototype. A good example is Agora’s free 10,000 minutes of video or audio processing each month. These limits are not arbitrary -- API companies know full well how much “free” is needed to demonstrate value, in order to hook a developer onto the path towards becoming “sticky product standard.”

The pricing of API products are almost all consumption based, using units that make the most sense for the use cases they enable. A SMS communications API would price per text. A data analysis API would price per amount of data retrieved. A real-time audio and video API would price per minute. A serverless compute API, like AWS Lambda, can even price per millisecond!

This pay as you use consumption pattern also renders pirating meaningless. Gone are the days of big upfront licensing costs that would price out developers and hackers from poor countries, forcing them to use bootlegged software. APIs can help a developer from anywhere get a job done quickly, affordably, and legally.

ICYMI: please give the other three parts of the "Global by Nature" series a read: developers, open source, public companies to watch.

If you like what you've read, please SUBSCRIBE to the Interconnected email list. To read all previous posts, please check out the Archive section. New content will be delivered to your inbox (twice per week). Follow and interact with me on: Twitter, LinkedIn.

生来全球化（第二篇）: APIs

“生来全球化” 四部系列的第一篇的关注点是人，即开发者。他们是我们正在步入的科技驱动的“全球化2.0”中最重要的人群。

在全球化2.0中，开发者自下而上地推动创新，新老企业都依靠他们来把自己 "科技化"，以求得生存和发展。这种转变既发生在公司外部，也发生在内部。一个最能促进和帮助这些“生来全球化”的开发者打造全球化创新的产品概念就是API（application programming interfaces，应用编程接口）。

这就是第二篇的重点。

API是一种技术的抽象，它赋予开发者快速又安全地做事情的能力。它也是一种极好的产品交付和应用模式。所谓 "API经济"是绝对存在的，也是 "生来全球化"的。

全球化资源访问

在网上可以找到很多API的技术定义，我自己的定义更通俗易懂些："一种获取资源来构建事物的通用方式"。

API可以被开发者使用，也可以是其他的API -- 机器与机器之间的交流。从这个角度看，"资源 "的含义很广，但也反映了事实，因为能被API“提取”的资源种类很多。数据是一种资源；需要做的具体事物是资源，如送货跟踪、导航、支付账单；日常做的事情也是资源，如发短信、打电话、视频会议。

拿数据这种资源做个更深入的比较，如果 "数据是新的石油 "这个比喻成立的话，那么API不仅是帮助您开采原始石油的钻机，还是对它们进行加工、提炼和包装，最终变成人可以泵入汽车的汽油的每一层步骤的工具。

API本质上的覆盖是全球化的，因为大多数的API都是在挖掘任何人都需要做的事情或组员，是不分区域、文化、或语言的。人的需求杂乱无章，所以能有一个抽象的东西把复杂而琐碎的细节简单化、系统化是非常有价值的。一旦这种抽象达到一定的成熟度，对于已经有全球化视角的开发者来说（原因请看第一篇），利用同样的一套API来快速扩展服务全球受众是非常自然的。

更有意思的是，一套设计良好的API还可以抽象各个司法管辖区或监管制度之间的差异，使其成为开发者既快又安全地构建全球服务的有力工具，同时减低被监管和合规问题绊倒的风险。

以金融服务为例。每个国家、地区，甚至美国境内的每个州的监管方式都有些不同。由Stripe等类似公司提供的支付和金融服务API，将这些差异抽象化了，因此开发者只需要搞懂这套API，就可以搭建支持金融服务的应用程序，来为多个管辖制度不同的区域的用户提供服务。这种体验从技术角度层面可以实现（但绝非易事）是因为API本身是个基于合同的系统。一个API通常会用代码来形容一套规则，比如什么人可以或不可以访问什么样的资源，多久可以访问多少次，附加一些例外。这种结构可以很好地呈现监管的规章制度，因为规章制度或多或少也是一套关于谁可以访问或做什么的规则，附加一些例外。

这种将规则和复杂事物抽象化的能力，使API在公司内部，尤其是在那些需要“科技化”的公司里，越来越常见，因为每个公司内部也有很多规章制度和资源管理。我在第一篇中提到的特斯拉 "内部应用开发团队"，其很多的产出是辅助特斯拉其他开发团队使用内部资源的API。

当然，API并不是科技开发中唯一的抽象模式。那从投资和机遇的角度来看，它有什么不同呢?

粘性产品标准

API与其他抽象方法不同之处在于，它们有潜力成为一种极有粘性的产品标准，吸引开发者长期使用。能够设计出，并更新和维护这种级别的API的公司也会大比例的积累到许多价值。

这种潜力还并没有被普遍认知，包括在科技行业里。正如以开发者为中心的分析公司RedMonk在2019年初的一篇分析中写到的：

API的重要性越来越大于实例化它们的代码。

文章分析的事件是当时许多的开源公司在更改自己代码库的许可制度，来抵御AWS等大型云平台的竞争。但API是产品，代码不是。对于开发者来说，API本身比构建它们的代码更有价值的多。实现API的代码虽然重要，但往往与日常工作无关。这种现象的体现在云行业中最明显，兼容已经流行的API是一种常见的产品扩张策略，以获得开发者对不同的、也通常是竞品的采用。举些例子：

  • AWS DynamoDB和Azure CosmosDB与MongoDB API的兼容
  • AWS Aurora与MySQL和Postgres API的兼容
  • GCP Memorystore与Redis API的兼容

我只举了几个云大厂的例子，还有更多的小型创业公司也采取了同样的方法。这些 "兼容目标 "都有开源版本，本来可以从代码层面完全进行分叉和复制，但API兼容是更有效的方法，因为API本身的产品价值和标准化粘性。

虽然 "API经济" 还很新颖，但我们已经开始看到一些赢家出现。如何识别赢家？通过观察兼容标准化的趋势的方向或谁是"兼容目标"。我们刚已经提到了MongoDB，Twilio是另一个，声网（Agora）可能也是另一个。不足为奇的是，所有这些公司都在全球范围有业务，因为API的本质是全球性的。(关于其中一些赢家公司的深度分析，请看第四篇。)

API的交付和应用模式

API的两大特点是其交付和应用的方式对开发者极为友好：自助服务和随用随付。因为这两个特点，一套API可以像野火一样在世界各地的开发者群体中燃烧和传播。

自助服务。一套设计优质的API在几分钟内就可以体现价值。通过阅读文档，自己搭建一个简单的环境来测试API的一些指令，开发者应该可以很快从API中获取一些资源。不需要其他同事或老板的同意，也不需要等公司其他部门提供测试环境，这种体验会自然而然地促使开发者做更多的实验、采用，最终把技术和产品在某些API上标准化。

能达到这种体验的API还很少，需要数年的产品打磨和完善。很多API可能永远都达不到这个水平，因为这是一种多方面的努力，不仅需要良好的技术选择和产品设计，还需要通过文档、教程、和其他教育资料来进行高效的人与人之间的传播交流。虽然有像OpenAPI这样的项目来促进API领域的规范化，促进其采用更多的最佳实践，但整个空间仍然很复杂和分散，因此也充满挑战和机遇。

随用随付。API模式的产品使用方式就是随用随付，给开发者提供足够的灵活性，同时降低实验的成本。这种“低门槛”至关重要。在前几年，还不是开发者驱动、不是API驱动的时候，这种实验需要通过许多官僚步骤，预算安排和分配，各个大小经理们的签字，可能还需要通过复杂的采购过程。有时需要几个月，有时长达一年多。现在，一个小开发团队可以很容易的把实验几个API的成本放在信用卡上，价钱不高，大多数经理也不难报销。在一个完全 "科技化"的公司里，聪明的经理会留出一小笔预算，专门用于鼓励这类实验。大多数以API驱动的产品都提供一个免费使用层，使用上限一般足够搭建一个可用、可展现的产品原型。一个很好的例子是声网每月免费提供10000分钟的视频或音频处理。这些上限也不是随意定的，API公司很清楚需要多少 "免费" 来证明价值，以便把开发者“勾引”到自己的生态里，步上"粘性产品标准" 的道路。

一个API产品的定价一般都是随用随付，其使用的单元由用例来定。一个短信通信API会按每条短信来定价，一个数据分析API会按搜索的数据量来定价，一个实时音频和视频API会按分钟来定价。像AWS Lambda这样的无服务器计算的API，甚至可以按每毫秒来计价。

这种随用随付的消费模式也让盗版失去了意义。以前要用正版软件要先花钱买授权，成本很高，穷国家的开发者和黑客根本付不起，迫使他们使用盗版。那个时代已经过去了。API可以帮助来自任何地方的开发者快速、经济、又合法地做事情。

ICYMI：请看“生来全球化”的其他三篇：开发者，开源，值得关注的上市公司。

如果您喜欢所读的内容，请用email订阅加入“互联”。要想读以前的文章，请查阅《互联档案》。每周两次，新的文章将会直接送达您的邮箱。请在Twitter、LinkedIn上给个follow，和我交流互动！