Global by Nature (Part II): APIs

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.

• Part I: Developers
• Part III: Open Source
• Part IV: Public Companies to Watch (Agora, JFrog, MongoDB)

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.