Managing APIs is like navigating unfamiliar terrain during a road trip: There’s an old way and a new way to do it, and the new way is just better in many cases. For API management, the old way of doing things involves practices like writing proprietary scripts, manual transaction monitoring and relying on individual employees to take charge of managing specific APIs – leading to more manual work, slower release processes, slower incident recovery and lower reliability. It’s akin to navigating a highway using a paper map, stopping at gas stations to ask for directions and crossing your fingers that you end up at your intended destination.
The new way of managing APIs looks like this: Using declarative configurations, automated processes and stateless APIs, teams scale and centralize the tasks of configuring, monitoring and updating APIs. They also deploy API changes several times a day, and they can instantly mitigate incidents in production.
It’s like navigating with a GPS: A simpler, faster and more flexible approach that gets you where you want to go with much less hassle and risk.
To prove the point, allow me to walk through the reasons why traditional API management strategies fall short for modern environments, then discuss what it takes to manage APIs better.
What is API Management?
Let me begin by defining what I mean by API management.
I’m referring to all of the practices, processes and tools that businesses use to support the APIs their workloads depend on. API management encompasses API design, development, monitoring, testing and security, as well as making updates to APIs after they are in production.
These tasks are important, of course, because APIs are everywhere today. They handle 83% of internet requests, according to Akamai, which means that keeping APIs documented, updated and monitored is a critical requirement for virtually any organization that deploys Internet-connected applications.
Without an efficient and scalable means of managing APIs, it becomes difficult not just to defend against challenges like security risks involving APIs but also to guarantee a positive developer experience. The more time and toil your developers have to invest in API management, the less time they have to do the things they want to do and that matter most to the business – like developing cool apps and bringing them to market.
The Pitfalls of Traditional API Management
APIs are not new, and most teams that support them have long had API management practices in place. However, in many cases, those practices were conceived in the era when monolithic application architectures and bare-metal servers or virtual machines dominated the IT landscape. They weren’t designed for today’s cloud-native, software-defined, distributed-everything world.
As a result, traditional API management falls short in modern environments in several key respects:
● Slow change management: When you are continuously pushing out updates to apps and APIs, you need an API management strategy that can handle continuous change. Traditional approaches can’t do this. They are too human-intensive to keep pace with rapid change.
● Lack of reliability: If you manage API configurations manually, you face a higher risk of introducing changes that accidentally break something. And if that happens, fixing the issue is slow because you have to reconfigure everything by hand.
● Slow recovery speed: When you experience an incident related to an API – such as a latency increase due to a misconfigured API – recovery is slower because it’s difficult to trace the surface-level problem back to its root cause, given the lack of a central source of truth for tracking the API’s status and revisions.
● Lack of scalability: Traditional API management uses imperative configurations that are stored in stateful databases, which have to be provisioned for each API you want to deploy. That works if you have just a handful of APIs to manage, but it’s impossible to scale if you need to scale to support dozens or hundreds. It also creates particular challenges if you have geo-distributed teams and infrastructure.
● Lack of modularity: Conventional API management architectures are not modular or composable, making it difficult to reuse configuration components between APIs. Instead, engineers are forced to “reinvent the wheel” every time they need to configure a new API or move an existing one from dev/test to production.
● Lack of standardization: Traditional APIs typically depend on proprietary technologies. As a result, they’re difficult to integrate with modern stacks that are based on widely used tools like Kubernetes, OpenTelemetry and Git.
● Poor collaboration: Documenting APIs and sharing monitoring insights between teams is also challenging when configurations are imperative and there is no single source of truth that all stakeholders can refer to when tracking the status of an API.
These challenges lead to a nightmare for teams tasked with Day 2 operations, meaning those that support APIs after they are in production. Slow, inefficient and unscalable management processes lead to struggles in detecting and fixing problems with API performance or security, as well as in updating APIs. And again, they hamper the developer experience by forcing developers to devote time and energy to deciphering APIs and versions to use, finding up-to-date documentation, and so on. As a result, developers whose main job is to write software, not manage APIs, become burdened by API management requirements.
A Better Way to Manage APIs
The good news is that a better world is possible – at least when it comes to API management. For modern apps and environments, API management should be rooted in the following principles:
● Composability: Your API management stack should be composable so that you can pick and choose from different ingress controllers, monitoring and analytics tools, load-testing solutions and so on. You shouldn’t be bound to a rigid, inflexible “stack.”
● Statelessness: Stateless API management, which frees APIs from dependency on stored configurations, enables scalability, simple rollbacks and consistency across environments because you can deploy APIs anywhere with minimal provisioning.
● Automation: The more you automate the processes involved in API management, the faster you can implement changes and the lower your risk of mistakes and inconsistencies due to manual management.
● Immutability: The underlying infrastructure that powers your API management stack should be immutable so you can replicate it easily and quickly – a benefit during processes like troubleshooting following a rollback.
● Auditability: You should be able to maintain a timestamped log of every change to your API that documents when changes are made, who made them, why they happened and what the potential implications are.
● Open and standards-based: The ability to monitor and manage APIs using open, standardized tools and frameworks – such as OpenTelemetry and kubectl – also leads to consistency and simplifies collaboration between teams. In addition, API contracts should be standardized using specifications like OAS.
● Efficient incident response: When you discover a performance problem or failure linked to an API, you should be able to troubleshoot and resolve the issue quickly without having to chase down documentation or find the one person at your company who understands how the API works.
When you manage APIs according to these principles, you escape the tedium and inefficiency of traditional API management. By extension, you can easily support the many APIs that tie your cloud-native environments together.
The Role of GitOps
Going a step further, a declarative, stateless, automated approach to API management also enables GitOps, meaning that you can manage APIs via declarative configurations that you store in Git repositories.
This practice also leads to greater reliability (thanks to consistent, repeatable and scalable configurations), collaboration (because Git serves as a shared, central source of truth for API configurations and workflows) and efficiency (due to the ability to automate and customize deployments using Git-based triggers and actions).
Conclusion: API Management at Cloud-Native Speed
In a world where more than half of existing applications are cloud-native and a majority of new apps will leverage cloud-native principles, traditional API management just doesn’t work for these new platforms. It leads to change management processes that are slow and unreliable – exactly the opposite of what businesses need to thrive in a dynamic, cloud-native world. It also slows down recovery, leading to lower levels of reliability and higher risk for the organization. On top of this, it’s tedious, inefficient and unscalable. So yes, cloud-native API management is currently broken.
We need a radical new approach to API management with one goal in mind: Automate Day 2 API operations with a modern approach. Modern solutions should be rooted in stateless, declarative configurations, open standards and Git-based automation. They must enable change management with high reliability and instant recovery, so you don’t have to worry about API management becoming the weakest link in your ability to innovate quickly and with minimal risk.
We envision a new world where managing APIs is no longer a burden that developers and platform teams must bear but instead a process that helps teams innovate as quickly as possible, no matter how complex the API architectures they are working with. We also want to help businesses bring products to market faster, as well as troubleshoot incidents more quickly and with less effort.
Ultimately, we want to empower organizations to take full advantage of cloud-native technologies and paradigms by adopting a cloud-native approach to API management.
