API Management Should Not Just Limit Me, It Should Allow Me To Scale

I do a lot of thinking about API management. After almost a decade of contemplating how we manage our API infrastructure, I feel it is still the most important stop along the API lifecycle. I don’t care how well designed, deployed, documented, and supported your APIs are, if you aren’t tuned in using API management, you aren’t going to be successful. API management provides you with the tools to you need to define and understand how your consumers will put your API resources to work. After almost 15 years of evolution, API management hasn’t changed too much, but there is one core capability I’d like to see evolve, expanding upon the often go to feature of API rate limiting.

API rate limiting has been a staple of API management since the beginning, allowing you to limit how much fo any resource a group or individual consumer can get access to—limiting the rate at which they can make API calls. The reason for rate limiting will vary from provider to provider, but the most common reason is to conserve compute resources so that an API remains usable by all consumers. Next, I’d say that pricing is the second most common reason for rate limiting, carving up API resources by access tier, and limiting the number of calls each API consumer can make per second, minute, day, or other time frame. While these concepts are still applicable to the business of APIs in 2019, I’d like to see the concept evolve to keep up with how we deploy infrastructure in a containerized, Kubernetes, serverless cloudy landscape.

Instead of capping what I can consume of your API, why not allow me to pay for more access, as well as more performance for a short period of time, or whatever duration I desire. You can still impose rate limits to measure everything I’m consuming, but allow me to also give the OK and turn on the firehose. If I need to do some batch processing, get at a volume of data I need for some application, why get in the way? API management shouldn’t just limit, it should empower me to scale and get what I need in any time period I need it. Let me pass in a header, or use an alternative DNS location to scale up my consumption of your API resources, leveraging API management to not just measure the amount of direct API resources I’m consuming, but also the underlying API infrastructure resources I am putting to work. In today’s cloud infrastructure landscape, it isn’t be too difficult to more closely couple the API management and underlying database and compute layers, to automate the scaling of API resources.

This concept wouldn’t probably work for those API providers who use API rate limits to make digital resources seem more scarce, and leveraging API management to shift perceptions around pricing. However, the concept of using API rate limiting to manage the compute resources behind an API seems pretty outdated. We shouldn’t be limiting access just because we can’t afford more compute power behind. We should be offloading this to the consumers. If they want to scale the AWS Azure, and Google infrastructure behind our APIs, then let them. They just have to be responsible for the bill. It seems like modern API management infrastructure should help us broker this deal, empowering our consumers, while also allowing us to derive new sources of revenue from our existing API infrastructure. Which is one of the main purposes of employing API management in the first place, to help us define plans around how are API resources will be put to work in a way that fits with our wider API monetization strategy.