The API gateway is the center of our universe when it comes to APIs. This is a reality operationally because when shit works or does not work, this is where the joy and pain is found. This is a reality because 99% of the stories we read on the tech blogosphere, hear from tech startups and analysts all tell us that the gateway matters. The modern API gateway was a carefully planned shift in power from your central database deep within your enterprise in the 1990s, externally via a service oriented architecture, and then via the modern API sprawl that keeps the landscape glowing at night across an apocalyptic urban techno landscape today. The real question is, was this your carefully planned shift in power, or was it someone else’s? To understand the modern API gateway, as well as the myriad of other tools and services that support APIs across operations, you need to understand the power dynamics and stories that exist, and who scoops up power and tells these stories. All of this is very entertaining, but sadly rarely ever about APIs.
If you live in the API dimension where doing the right thing matters, you are likely heavily investing in API design and governance, and the specifications, standards, tools, and services that help you in your righteous mission. If you live in the API dimension where you are interested in accumulating power and extracting value wherever it lies, then you are extremely focused on the gateway run-time. I remember meeting these sheeps in wolves clothing in the early days of API management, as Apigee, Mashery, SOA Software, and others were shaping the new API gateway centered narrative. These people were like that Steve Buscemi old guy skateboard meme-—on this new API scene using the new words, but very much acting and approaching things like the old guard SOA power grabbers who had been snatching power from the previous database power grabbers (ie. Oracle). Amidst all of this power grab there were a handful of righteous startups like 3Scale, Apiary, and others who believed in doing APIs right, and were on a mission, began shifting things left in the API lifecycle, demonstrating the value of a contract-driven and API-first approach to the API lifecycle—-something that still holds true into today’s flaming API sprawl beginning to explode from throwing AI fuel on it.
The API gateway still dominates the narrative because of the stories spun by the last decade of power grabbing occurring at the run-time as it shifted from the enterprise database, first externally, but then massively internally by all of the tribal factions employing micro services. If you really don’t understand how the API lifecycle actually works within an enterprise and you are just grabbing for power-—you focus on the API gateway. If you understand, or are interested in understanding how all of this works and want to contribute to a strategic vision for the business, you really see the benefit of OpenAPI, AsyncAPI, JSON Schema, Spectral rules to map and govern the sprawling landscape, and the importance of planning, design, mocking, documenting, testing, and the other essential aspects of the API lifecycle in concert. Over the last decade you’ve seen specifications gain traction, and API tooling and service providers break free of the API management narrative surrounding the API gateway, and gain traction all on their own. However, power does as power does, and the run-time is where the power primarily lies, and as much as we all believe distributed is the way to go, power likes things centralized—-it is just easier to extract maximum value that way, while also controlling the narrative. However, these value extractors don’t always realize this view also makes them more vulnerable over the long run, but that is another story.
This run-time versus design-time struggle for the soul of the enterprise has multiple dimensions of power you have to understand to be successful—-whatever the hell success means. Is it power within the enterprise, or external within an industry, or across industries? Because the OG shift from database to gateway that has occurred at the turn of century was more about external forces obtaining and extruding value of internal enterprise forces. Salesforce, eBay, Amazon, Facebook, and Google realize they use APIs to extract value from existing enterprise leaders, and change the conversation across many industries. Venture capitalists realized the same thing along the way, and maximized their investment in every wave of API service, specification, and tooling providers along the way, whether you were peddling your warez in sync with the older API management and gateway as a power center narrative, or the emerging and expanding version that shifts left with planning and design-first, a contract-driven approach, rich documentation and portals, and every other aspect of delivering APIs. It is power that makes the design-time vs run-time discussions within the enterprise so difficult. It isn’t just the internal power struggles that exist within any enterprise, it is the external power dynamics at play to extract value from the enterprise and distribute it in new ways.
API concepts like design and contract first matter. These concepts help us make sense of the sprawling digital landscape that is so crucial to operating our businesses. Of course planning, standards, and design matter to delivering the most useful APIs possible. However in the power struggle that exists within the enterprise, shifting from the database to the API gateway, as well as the shift of value from inside the enterprise externally, these concepts are easily lost in the shuffle, noise, and desperation involved in the delivery / extraction of value that occurs at the gateway. Internal power brokers scramble to produce value at the API gateway layer, and internal power brokers scramble to produce value there as well via integrations and applications-—something now brokered by API platform teams hoping to accumulate power. However, in the same motion, external power brokers are also looking to extract value at this layer as well by selling you the next tool, service, and AI. APIs are all about value, producing and consuming value, but if you live by API you will die by API, because while you are busy producing value for your consumers to apply, you are also having value extracted by your cloud provider, infrastructure, and software as a service providers, and their investors. It really is a beautiful and sprawling fiery landscape-—I really do enjoy watching it burn.
While planning, designing, and standardizing matter, I’d say what matters most in this environment is that your teams learn to plan, design, standardize, and then build—training, developing skills, and learning to work together so they can move in any direction as needed. In the run-time frenzy all you learn to do is respond to what is needed in the moment, fashioning the cyber gears needed to keep the machine in motion, and respond to fires that pop up along the way (inevitable with velocity). You can never really be sure whether the design for the gear or the machine around it was designed by your dear business leadership, product managers, or by your infrastructure, service providers, competitors, or their investors. Moving fast and breaking things has long been showcased as how you gain the edge over your competitors, while accumulating massive amounts of technical debt does not seem to carry the same label of slowing you down and giving your competitors an edge. Which makes you wonder, who designed this narrative? Where does it fit in with the power dynamics at play? Is moving fast and living a runtime centered life where you get ahead? Or would it maybe be a balance of design-time and run-time. Right now I’d say the API landscape across enterprise organizations is 90% run-time and 10% design-time, at best. Most enterprises are just blindly powering forward, unsure if the design for their digital resources, capabilities, and experience are their own, provided by infrastructure and service providers, or even their competitors in the form of the next generation of digital Trojan horse. This is by design.
