Marcelo Mendoza

API Gateways have become ubiquitous in modern architectures, but what exactly are they? More importantly, are they primarily security components that have accumulated features over time, or architectural necessities with security as a side benefit? Let’s explore what API Gateways truly are, their evolution, and the emerging trend toward disaggregation.

What Makes an API Gateway?

An API Gateway is a traffic manager and mediator that sits between clients and backend services, acting as a reverse proxy. However, it’s more than just a simple proxy or load balancer. The defining characteristics include:

Core Characteristics

Characteristic	What It Does	What It’s NOT
Single Entry Point	Acts as the main entry point for all client requests, providing a unified interface to multiple backend services	NOT just a load balancer or simple reverse proxy
Request Routing	Routes requests to appropriate backend services with dynamic routing based on various criteria	NOT just a static routing table
Protocol Translation	Translates between different protocols (HTTP to gRPC), handles API versioning	NOT limited to simple HTTP forwarding
Request/Response Transformation	Modifies requests and responses, aggregates responses from multiple services	NOT just a pass-through proxy

The Single Entry Point Principle

In theory, the API Gateway should be the “single entry point” for all external traffic. But does this mean there’s literally no other way to access backend services?

The answer is nuanced:

For External Traffic: Yes, the API Gateway must be the only entry point. It acts as the “front door” for all external API consumers.

For Internal Traffic: There are legitimate exceptions:

Service-to-Service Communication: Microservices often communicate directly with each other using service mesh
Internal Tools: Admin interfaces, monitoring systems, and debugging tools may bypass the gateway
DevOps Operations: Health checks, metrics collection, and deployment operations typically have direct access

The key is network segmentation:

├── Public Zone (Internet)
├── DMZ (API Gateway)
└── Private Zone (Backend Services)
    ├── Internal Network A
    ├── Internal Network B
    └── Management Network

Security Core vs. Convenience Features

Here’s a provocative thesis: An API Gateway is fundamentally a security boundary component, and its other responsibilities are there for convenience.

Let’s analyze this:

Security-Core Features

├── Authentication/Authorization (CORE)
├── Rate Limiting (CORE)
├── SSL Termination (CORE)
└── IP Filtering (CORE)

These features align with traditional network security principles: controlling the perimeter, managing access, and reducing the attack surface.

Convenience-Added Features

├── Request/Response Transformation
├── API Documentation
├── Analytics/Monitoring
├── Protocol Translation
├── Response Caching
└── Service Discovery

These features accumulated over time because it made economic sense. Instead of implementing rate limiting, authentication, and authorization in every service:

# Instead of this in every service:
class ServiceA:
    def handle_request(self):
        if not self.rate_limit_check():
            return 429
        if not self.authenticate():
            return 401
        if not self.authorize():
            return 403
        # ... actual business logic ...

# We get it "for free" at the gateway:
class APIGateway:
    def process_request(self):
        if not self.rate_limit_check():
            return 429
        if not self.authenticate():
            return 401
        if not self.authorize():
            return 403
        return self.route_to_service()

Why Features Consolidated

The consolidation happened due to:

Single point of implementation - Write once, apply everywhere
Consistent application - Same security policies across all services
Reduced duplication - No need to copy-paste code
Centralized management - One place to update configurations
Economy of scale - Better performance when optimized once

Market Forces Impact

API Gateway products evolved through market dynamics:

Basic Security Gateway
Companies want more features
Vendors add conveniences
Features become "standard"
New gateways must have these features to compete

The Disaggregation Trend

Despite this consolidation, we’re now seeing a reversal: disaggregation into specialized components.

The Evolution

Monolithic Gateway Era	Disaggregated Modern Architecture
All-in-one solution	Edge Gateway (security focus)
Single vendor lock-in	Service Mesh (internal traffic)
Feature bloat	Developer Portal (API management)
Performance overhead	Observability Platform (monitoring)
Single point of failure	Identity Provider (authentication)

Specialized Components

Edge Gateway (Security Focus)

Primary Responsibilities:
  - SSL Termination
  - Basic Routing
  - Rate Limiting
  - DDoS Protection
Examples:
  - AWS CloudFront + WAF
  - Cloudflare
  - Akamai Edge

Service Mesh (Internal Traffic)

Primary Responsibilities:
  - Service Discovery
  - Load Balancing
  - Circuit Breaking
  - Service-to-Service Auth
Examples:
  - Istio
  - Linkerd
  - AWS App Mesh

Developer Portal (API Management)

Primary Responsibilities:
  - API Documentation
  - Key Management
  - Usage Analytics
  - Sandbox Environment
Examples:
  - SwaggerHub
  - Postman
  - Azure API Management Portal

Observability Platform

Primary Responsibilities:
  - Distributed Tracing
  - Metrics Collection
  - Log Aggregation
  - Performance Analytics
Examples:
  - Datadog
  - New Relic
  - Grafana + Prometheus

Identity Provider

Primary Responsibilities:
  - Authentication
  - Authorization
  - Token Management
  - User Management
Examples:
  - Okta
  - Auth0
  - Keycloak

Why Disaggregate?

Specialization Benefits:

Better feature depth per component
Optimized performance for specific use cases
Specialized expertise from vendors
Independent scaling of components

Operational Advantages:

Easier updates and maintenance
Better fault isolation
Flexible vendor selection
Cost optimization (pay for what you need)

Technical Benefits:

Reduced complexity per component
Better performance tuning
Easier testing and debugging
Independent evolution of features

Real-World Example

A modern stack might look like:

edge:
  provider: Cloudflare
  purpose: DDoS protection, SSL, Basic routing

service_mesh:
  provider: Istio
  purpose: Internal service communication

identity:
  provider: Auth0
  purpose: Authentication & authorization

observability:
  metrics: Prometheus + Grafana
  tracing: Jaeger
  logs: ELK Stack

developer_portal:
  provider: Custom Portal + SwaggerHub
  purpose: API documentation and testing

Products in Transition

Several monolithic API Gateway products are experiencing this transition:

Kong Gateway

Was: All-in-one API Gateway with plugins
Now:
- Kong Gateway (core routing & security)
- Kong Mesh (service mesh)
- Kong Enterprise Portal (developer portal)
- Konnect (cloud control plane)

AWS API Gateway

Was: Complete API management platform
Now:
- API Gateway (edge routing)
- App Mesh (service mesh)
- Cognito (authentication)
- CloudWatch (monitoring)

Apigee

Was: Full platform with gateway, portal, analytics, monetization
Now:
- Apigee X (core gateway)
- Apigee Sense (threat detection)
- Integration with Cloud Monitoring, Cloud Trace, Cloud Armor

Transition Challenges

Moving from monolithic to disaggregated architectures isn’t without challenges:

Integration Complexity:

More moving parts to coordinate
Multiple vendors to manage
Configuration management across systems
Maintaining consistent policies

Cost Considerations:

Multiple licenses potentially needed
Training requirements for different systems
Integration and operational overhead

Organizational Impact:

Team specialization requirements
Increased knowledge distribution
Communication overhead
Ownership boundary decisions

When to Use (and Not Use) an API Gateway

Given this understanding, when should you use an API Gateway?

Use an API Gateway When:

You have multiple backend services exposed externally
You need centralized authentication and authorization
Rate limiting and throttling are requirements
You want a single point for security policies
You need to support multiple API versions
Protocol translation is necessary

Consider Alternatives When:

You have a simple, single-service application
All consumers are internal and trusted
You need maximum performance (every hop adds latency)
You want to avoid a single point of failure
Your team lacks expertise to manage it properly

Conclusion

API Gateways are fundamentally security boundary components that have evolved into feature-rich platforms. The convenience features made sense when centralized, but we’re now seeing disaggregation as specialized tools emerge that do specific jobs better.

The key insight: Understand what you actually need. Do you need a security perimeter with basic routing? Start simple. Do you need the full suite of features? Consider whether a monolithic gateway or a set of specialized components makes more sense for your architecture, team, and use case.

The future likely isn’t one or the other, but a thoughtful combination: lightweight edge gateways for security, service meshes for internal communication, and specialized tools for observability and management. Choose based on your actual requirements, not on what’s trendy or what vendors are selling.

API Gateways: Security Boundary or Feature Hub?