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。







  • 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驱动的产品都提供一个免费使用层,使用上限一般足够搭建一个可用、可展现的产品原型。一个很好的例子是声网每月免费提供10000分钟的视频或音频处理。这些上限也不是随意定的,API公司很清楚需要多少 "免费" 来证明价值,以便把开发者“勾引”到自己的生态里,步上"粘性产品标准" 的道路。

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