Rate Limiting at the Edge
I’m sure many of you have heard of the “Death Star Security” model — the hardening of the perimeter, without much attention paid to the inner core — and while this is generally considered bad form in the current cloud native landscape, there is still many things that do need to be implemented at edge in order to provide both operational and business logic support. One of these things is rate limiting.
Rate Limiting for Business and Operational Requirements
Modern applications and APIs can experience a burst of traffic over a short time period, for both good and bad reasons, but this needs to be managed well if your business model relies upon the successful completion of requests by paying customers. Using rate limiting allows the prioritisation of requests.
Modern cloud native applications typically rely on third-party external services to provide end-user functionality, for example, a payment provider or storage services. If these services experience issues (or your own internal dependencies experience issues) techniques like load shedding can reduce pressure on upstream services, or prevent a simple service degradation becoming a full-scale cascading outage.
Centralised versus Decentralised Rate Limiting Configuration
Implementing rate limiting has typically been the responsibility of the centralised operations or sysadmin team. This was fine when applications were deployed (and exposed) as monolithic systems, and when APIs and services were not changing rapidly. However, many cloud native applications are typically distributed and microservice-based, and the ability to react quickly to changing user requirements and market demands is a competitive advantage. This drives the need to provide a mix of centralised (typically operational) and decentralised (mostly app development team driven) configuration at the edge.
When we designed Ambassador, these requirements were built in from the ground up. Our latest rate limiting documentation demonstrates how you can apply these principles when implementing rate limiting at the edge, and we provide approaches to meet the needs of both operational and business requirements.
Getting Started with Rate Limiting in Ambassador
If you’re familiar with the Ambassador approach to defining mappings as Kubernetes annotations that are placed on Service definitions, then you should be able to implement global or service- (API-) based rate limiting in no time at all. We’ve recently created two tutorials: one for implementing an open source approach to rate limiting that uses a simple demonstration limiter we have created; and a second that is part of our Ambassador Pro offering which offers an easily installed and feature rich implementation of rate limiting.
Please do try out the rate limiting services with Ambassador, and let us know what you think of the documentation. We’re always keen to encourage open source code contributions, examples, and documentation, and so please do get in touch if you are keen to help out.
