One of the things I love and hate about the API universe is that if you live by APIs, you will often times die by APIs, unless you can perpetually dial in just the right balance across how much value you generate, keep for yourself, or make accessible to others. I’ve fictionally written about how APIs are just the Sentinels from the Matrix, in that they first began as construction bots helping humanity, and then once the Matrix took control of humanity, their roles changed. Of course, this is fiction, but in reality (not the simulation) APIs can be both assistive, value creating resources for both producers and consumers, but their polarities can also be reversed, rapidly turning them into invasive value extracting sentries.
Twitter, Facebook, Google Maps, and other popular APIs have employed the old API playbook where they offer up an API for free early on, generate the content, data, and network effect they desire, then slowly lock things down and get to work extracting the value out of consumers who are dependent on your platform. When APIs are wielded by platform in this way it can completely change the dynamics of the platforms as we are seeing across the social media space right now. However, you can see APIs being used to consume and turn platforms and open-source solutions from the outside-in using their APIs, resulting in ever expanding universes of services and tooling emerging because of the APIs. You saw this happen over the last 7+ years with the API management space as it has been commodified, spinning off documentation, portal, analytics, and other satellite universes that used to be part of the core offering. I also just finished reading a piece on how a similar phenomenon is happening in the Kubernetes universe as the year of the platform is getting going.
As the Kubernetes world continues to grow and expand, some of the essential building blocks of the platform, which are also represented as APIs, are being spun up as external open-source solutions or standalone startup services. The Kubernetes API powers and incentivizes this. The Kubernetes is an “open API”, which also happens to be exposed as an OpenAPI. This means anyone can use to integrate, automate, and orchestrate any Kubernetes instance, but also develop Kubernetes compliant services and tooling that use the same API. Using the Kubernetes API to expand, grow, and even live-on longer than Kubernetes, or any part of Kubernetes will. I love this about APIs. Now, as a platform there are plenty of business and political controls you can twist and turn to slow this process down, but ultimately it is better for Kubernetes and the community if you let the ecosystem (not markets) work things out. Kubernetes is federated, and unlike Twitter and Facebook, there are a different set of challenges involved with shaping API ecosystem behavior.
For me, APIs are the leveler. Granted there are plenty of ways you can game the system, but if you want to grow, scale, and build an ecosystem around your centralized or federated platform, you are going to need APIs. Sure, you can do like Facebook, Twitter, and others have done and open the firehose for the first few years and tighten it down to a drip…drip…drip garden hose after a while, but eventually it will bite you in the ass. You must be API-first these days, otherwise people will build and operate elsewhere. The future of APIs will be defined less by technological shifts, and more by the business and political shifts that will come with new ways to generate revenue, and regulation emerging in the EU and US. I am going to continue exploring what the concept of the future holds for the Kubernetes ecosystem because of its API, while also weighing in on the federated API opportunities that exist within the enterprise ecosystem because of the Kubernetes API.
