Long Live the API Stack: Full-Life-Cycle API Management Is Dead
Tell a developer that you have a full life cycle API management solution to make their life easier, and you will likely get a dark stare. That’s because developers don’t like to be told how to live their lives, and monolithic, all-in-one API platforms are among the most heavy-handed and disliked tools around. More often than not they are used to enforce cumbersome, top-down policies, inadvertently encouraging development teams to seek easier pathways.
But it makes sense that full-life-cycle API management was once a popular solution, as there didn’t used to be so many specific tools for managing distinct aspects of APIs. Now, you can find a tool for almost anything, from documentation, discovery, cataloging and proxying to routing, security, logging and monetization.
What’s going on? Nothing less than a major transition in the way we define, develop, deploy, manage and secure APIs. It has happened quietly but is gathering steam. The full-life-cycle API management monolith is quickly dying. Emerging in its place is the API stack.
The History of API Solutions
For most of API history, enterprises wishing to manage and control APIs deployed a large technology called a full life cycle API management platform (and yes, we went down the path of building one at F5 NGINX in 2018, guilty as charged). These monolithic tools were intended to perform all the critical jobs during an API’s life cycle, from defining schema and publication to documentation, cataloging and discovery; from deployment, security, usage monitoring and analytics to versioning and deprecation. It was an excellent solution for API software vendors and top-down, command-and-control software development organizations.
But things have changed. In a shift-left world, developers wield more power in choosing their tooling. APIs have become the established way to build applications — a mélange of first-party and third-party code and services, loosely coupled and constantly evolving. Whereas full life cycle API management platforms were originally developed to service smaller catalogs of APIs primarily serving north-south traffic, Kubernetes and microservices have exploded this paradigm.
APIs are now everywhere, doing everything: north-south, east-west, cloud-to-cloud and more. Perhaps most importantly, the need for speed in application development and bringing new features to market has made monolithic API management systems increasingly less tenable.
The API Stack Emerges from Cloud Native
Not surprisingly, over the past five years, the API tooling landscape has followed the evolutionary path of cloud native technologies. The ascendant view of how to develop, manage and govern APIs has moved from “Send in the monolith!” to “What’s in my tool belt?” Developers prefer to choose. This shift has led us to a world of point solutions that are easy to connect and customize.
This new trend also follows a historical path. In the dot-com era, monolithic, tightly coupled application stacks evolved into loosely coupled and wildly diverse LAMP stacks (Linux, Apache, MySQL, PHP/Perl/Python). Then, there was an explosion in options for backend products, as literally dozens of open source databases hived off from the SQL mothership, giving developers countless options for documents, graphs, key values and time series. As containers gathered steam and cloud native took shape, there was another explosion of choice in almost every facet of application development: runtime, message queues, middleware, frontend frameworks and, of course, new language options.
Similarly, the emergence of entirely new disciplines that blend development and operations in novel ways has accelerated the disintegration of monolithic API management. Site reliability engineers (SREs), DevOps, and now platform engineering practitioners view the world through the lens of “jobs to be done” rather than “product for the job.” They want the right tool at the right time. Above all, the API stack operates with the ethos of “different strokes for different folks.” The solutions for different jobs might be proprietary (bought), open source (borrowed) or in-house (built).
Four Core Principles of the API Stack
When viewed through the lens of “jobs to be done,” the API stack becomes less of an all-in-one product and more of a choose-your-own-adventure game. The adventure has three stages: design and test, deploy and operate, and monitor and monetize. The thread linking these stages is a set of four core principles:
- Built by platform teams to enable developers. Each organization can arrive at its own decisions on what must be included in its API development and operations process. That’s the role of platform teams, working in collaboration with developers, DevOps and security teams. The developers are first-class citizens in this design process because if they can’t (or don’t want to) use the tools in the API stack, then things will go badly.
- A 100% API-first approach. Far too often, API tools aren’t API-first themselves. You have to commit to a fully API-first approach to make your API stack work. With API-first tools, you can achieve the benefits of your APIs having a clear purpose, direction and simplicity in their execution. This is why Amazon CEO Jeff Bezos decreed all services must be consumable via API, and many organizations may be transitioning to this point. Newer organizations can build from inception as API-first. Regardless of when your organization becomes API-first, the entire point of an API stack is to build a business that runs on and benefits from APIs.
- Loosely coupled while using open source and vendor tools. This is a corollary to API-first, but still an important nuance. Your API stack will likely evolve over time; tools useful for one stage of company development or one set of technology may no longer be useful in the future. Platform teams may need to integrate additional capabilities and tools. And if APIs are your business, then downtime (or even slow time) is not an option.
- Must cover all APIs, including internal, partner, third-party and external. An API stack that only covers select API types increases operational load and security risk. It also means developers will need to take on more work. Often, organizations make the mistake of not extending the same stack to APIs outside of their control. Even if you are not designing and maintaining the APIs, your product behavior, security and customer experience can all be impacted by every API in use. So, designing the API stack for full coverage is critical.
Conclusion: There’s an API Stack for Everyone
There are many options for integrating an API stack into your organization. If you are currently using a full life cycle API management tool, it is often possible to build an API stack that cherry-picks the best parts of your monolith. If you are just getting started switching your monoliths over to APIs, then you can build an API stack and slowly migrate over services as you refactor your code. If you are working from a clean slate, your API stack can be tightly tailored to your application needs beyond what a monolithic full life cycle API management tool could accomplish.
The beauty of this approach is that the API adventure is truly yours to choose, without the trade-offs inherent in one-size-fits-all solutions. The entire principle of APIs is to make applications more modular and easier to manage and build, and an API stack is the tool belt your developers have been looking for.
