Six Signs You’ve Got an API Sprawl Problem
The average enterprise today has over 15,000 APIs in place, according to industry analyst 451 Group. Obviously, that’s a few more APIs than the average Platform Ops team can track in a spreadsheet. Even if you delegate responsibility for API tracking to individual business units, the task is still overwhelming given the staggering growth in the number of APIs.
In 2021, F5 engineer and technologist Rajesh Narayanan coined a new term for the problem: API sprawl. API sprawl is just what it sounds like — the accelerating proliferation of APIs at organizations around the world and the resulting challenge of managing and securing them. How big is the problem? Narayan estimates that by 2030, there will be over 1 billion APIs deployed and operating around the world.
Changes to the way modern apps are developed are helping accelerate API sprawl. The rise of microservices, the growing use of APIs for intrasystem communication and the rapid increase in multicloud and hybrid cloud architectures have all increased the use of APIs for communication among apps. For example, Kubernetes, the de facto standard for container orchestration, uses APIs for all internal communications. New infrastructure types, such as serverless, also mean APIs can run in almost any environment. At the same time, there are more types of API technologies to manage — REST, GraphQL, and gRPC are already commonly used, and more API-query protocols are appearing on the horizon.
To make matters worse, cybercriminals absolutely love API sprawl. They’re increasingly aiming their attacks at APIs precisely because they’re often not carefully managed and configured with relatively open access permissions by default.
To mitigate the resulting chaos, the challenge of managing, discovering, and securing APIs must be addressed programmatically and at scale. But before you can deal with API sprawl effectively, you need to know just how bad the problem is at your organization. Here are six clear signs that you have an API sprawl problem.
You Don’t Have an Up-to-Date Inventory of All APIs
The classic symptom of API sprawl is not knowing what APIs are running across all your environments. This often results from a loose API management policy that allows teams not to register APIs they use only for internal purposes (so-called “shadow APIs”).
Your first task is to take an accurate inventory. But API additions and deprecations tend to be so frequent that an accurate inventory is a constantly moving target. The logical solution is programmatic inventory and ongoing API discovery, much like you use for network scanning and asset discovery.
In theory, a structured API approval process can also help, but in practice organizations that are shifting left need to scale back on heavy-handed approval processes for tasks like API creation and versioning. For these organizations, running an inventory as part of CI/CD and build processes is often a good approach, particularly if the APIs are used for microservices and other more modern application architectures.
You Don’t Know Where Each API Is Running
In the modern infrastructure landscape, just knowing an API exists is not enough – you need a map to its location. Endpoints might be mirrored across containers in different infrastructural form factors — across clouds, in hybrid clouds, and in various services such as serverless.
Security teams need location information to properly configure policies and protection and to run security tests against APIs. If you need to run APIs in multiple environments, that also influences your choice of API gateway and other API traffic-management options. Ideally, you want a global API gateway solution that can consistently manage and secure API traffic independent of environment.
You Can’t Easily Identify API Owners
If you don’t know who owns an API, you don’t know where to turn when there’s a problem with it. It might sound silly, but all too often, APIs that are integral to smooth operations are left running as “orphans” when the person or team that built them moves on to another role or leaves the company. Sometimes ownership is transferred explicitly, but more often, that process is skipped or done with an informal handshake.
As part of the inventory process, it is critical to assign ownership to every API in order to establish accountability and to help owners properly manage and secure their APIs.
Multiple APIs Are Doing Similar or Overlapping Tasks
Overlap often happens when multiple teams have similar but not identical requirements and someone says, “Let’s just build our own API to do exactly what we want, and then we can control our own destiny!” Alas, having multiple similar APIs increases tech debt, often unnecessarily. Therefore, it is important to measure how many applications or services use an API as one of your key performance indicators (KPIs). Tracking these metrics can help maximize the reusability of each API. Another way to consolidate APIs is by switching to more flexible formats like GraphQL.
Documentation Is More Than 2 Versions Out of Date
Documentation is critical for institutional memory, onboarding new employees, and organizational resilience. Unfortunately, writing and maintaining it is generally the thing engineers hate the most. Out-of-date API documentation often signals API sprawl is underway, because teams are creating and updating APIs so quickly, they don’t have time to update the docs — or can reasonably claim that. In the worst case, old documentation is a sign the API is an orphan that no one is maintaining.
Fortunately, APIs tend to have a clearly defined structure that makes them easy to understand. Good API management solutions usually include a tool to help your developers auto-generate documentation from an API specification. One of the most common examples is the OpenAPI Specification. It uses a standard format to describe APIs so humans and computers can discover and understand the capabilities of an API without access to the source code or additional documentation.
Projects Are Delayed Due to API Security
The good news? Your security team is checking all APIs before they go out the door. The bad news? The checks fail and the code is sent back for rework because API owners have not followed best practices for API security during development or don’t do adequate testing. The better news? It’s not that hard to lay out a coherent set of general rules and best practices to get your developers 95% of the way there — basics like imposing rate limits, encrypting external traffic, and requiring reauthorization with key regeneration. Most organizations can also implement additional protections at the API gateway using an advanced web application firewall (WAF) or other tools to defend against the most common API attacks listed in the OWASP API Top 10.
More advanced organizations with mature SecDevOps chops can build a threat model for each API and potentially create different security levels for different APIs depending on what kind of data or service they can access.
Conclusion: Avoiding Sprawl Is a Never-Ending Battle
These six signs are just some of the signals of API sprawl. And let’s be clear — API sprawl is a natural outgrowth of developer autonomy and the DIY mentality of microservices. With modern development tools and code automation capabilities like GitHub Copilot, it’s becoming easy to build new APIs.
The job of fighting sprawl is never done. Deploying an API management solution and an API gateway can help by acting as a forcing function — developers who don’t use the APIM solution for their APIs might risk having the gateway turn the APIs off (harsh but necessary for security).
Fortunately, the steps you take to combat sprawl mostly align with common-sense API management. They can, over time, even increase development velocity by removing technical debt and avoiding the need to fix APIs with bolted-on security late in the development process or after launch.
If APIs are the lifeblood of organizations, sprawl is one of the biggest threats to their health. Vigilant and proactive sprawl mitigation pays huge dividends down the road and ultimately makes for happier developers.
