This is an automated email from the ASF dual-hosted git repository. moonming pushed a commit to branch feat/seo-comparison-articles in repository https://gitbox.apache.org/repos/asf/apisix-website.git
commit ab9eb1d9e9de498703b4a4310263f3f0e0cf9dff Author: Ming Wen <[email protected]> AuthorDate: Wed Jun 24 20:12:57 2026 +0800 feat(seo): add 5 head-to-head API gateway comparison articles Comparison content was the biggest gap for the goal of ranking on 'API gateway' queries: only apisix-vs-kong + the open-source roundup existed. Add five balanced, credible comparisons (matching the apisix-vs-kong tone, no fabricated benchmarks): - apisix-vs-aws-api-gateway (self-hosted vs managed, cost at scale, lock-in) - apisix-vs-nginx (APISIX is built on NGINX; vs raw NGINX and NGINX Plus) - apisix-vs-envoy (turnkey gateway vs a proxy needing a control plane) - apisix-vs-traefik (throughput + plugins vs container auto-discovery) - apisix-vs-apigee (open-source gateway vs enterprise API management platform) Each has an FAQ section + matching faq front matter, so they pick up the Article/FAQPage/BreadcrumbList structured data from the BlogPostPage wrapper. Also backfill faq front matter on apisix-vs-kong (its '## FAQ' heading was missed by the earlier grep), wire all into the /comparisons/ hub (4 -> 9 cards), and add them to llms.txt. Verified against the production SSR build: all six emit Article + BreadcrumbList + FAQPage (4 Q&A each), FAQ answers match the visible body, hub links resolve. --- website/learning-center/apisix-vs-apigee.md | 100 +++++++++++++++++++ .../learning-center/apisix-vs-aws-api-gateway.md | 106 +++++++++++++++++++++ website/learning-center/apisix-vs-envoy.md | 95 ++++++++++++++++++ website/learning-center/apisix-vs-kong.md | 13 +++ website/learning-center/apisix-vs-nginx.md | 91 ++++++++++++++++++ website/learning-center/apisix-vs-traefik.md | 95 ++++++++++++++++++ website/src/pages/comparisons.tsx | 30 ++++++ website/static/llms.txt | 5 + 8 files changed, 535 insertions(+) diff --git a/website/learning-center/apisix-vs-apigee.md b/website/learning-center/apisix-vs-apigee.md new file mode 100644 index 00000000000..ac3caa269e0 --- /dev/null +++ b/website/learning-center/apisix-vs-apigee.md @@ -0,0 +1,100 @@ +--- +title: "Apache APISIX vs Apigee: Open-Source Gateway vs API Management Platform" +description: "Compare Apache APISIX and Google Cloud Apigee. APISIX is a high-performance open-source gateway; Apigee is a full enterprise API management platform. Covers scope, cost, developer portal, analytics, and when to choose each." +slug: apisix-vs-apigee +date: 2026-06-24 +tags: [comparison, apisix, apigee, api-gateway] +hide_table_of_contents: false +faq: + - q: "Is Apache APISIX a full API management platform like Apigee?" + a: >- + Not on its own. APISIX is a high-performance API gateway focused on the runtime: routing, authentication, rate limiting, traffic management, observability, and AI gateway features. Apigee is a broader API management platform that also includes a developer portal, deep API analytics, monetization, and lifecycle governance. To build a full API management program around APISIX, you pair it with complementary tooling for those higher-level functions. + - q: "How do the costs of Apache APISIX and Apigee compare?" + a: >- + APISIX is free and open source under the Apache 2.0 license; your cost is the infrastructure you run it on. Apigee is a commercial enterprise platform with pricing based on API calls and capabilities, which can be substantial at scale. Organizations focused primarily on gateway functionality often find APISIX far more cost-effective, while those needing Apigee's full management suite weigh that against its platform cost. + - q: "Does Apache APISIX offer a developer portal and analytics like Apigee?" + a: >- + APISIX provides strong runtime observability through integrations with Prometheus, OpenTelemetry, Datadog, SkyWalking, and others, but the open-source project does not bundle a polished developer portal, business-level API analytics, or monetization the way Apigee does. Teams that need those capabilities integrate additional tools alongside APISIX, whereas Apigee delivers them as part of one platform. + - q: "How do I migrate from Apigee to Apache APISIX?" + a: >- + Migration usually starts with the gateway runtime: map Apigee API proxies to APISIX routes and upstreams, and translate Apigee policies (for authentication, quotas, spike arrest, and transformation) to the equivalent APISIX plugins. Higher-level Apigee features such as the developer portal and monetization are addressed separately with complementary tooling. Running both in parallel and shifting traffic incrementally allows a controlled, low-risk migration. +--- + +Apache APISIX and Apigee are often compared, but they sit at different layers. APISIX is a high-performance, open-source API gateway focused on moving and governing traffic. Apigee is a comprehensive, commercial API management platform that includes a gateway plus the surrounding business and lifecycle tooling. Understanding this scope difference is the key to choosing correctly. + +## Overview + +Apigee is Google Cloud's enterprise API management platform. Beyond the gateway runtime, it provides a developer portal, detailed API analytics, monetization, and full API lifecycle management, with policies configured through a console and an XML-based policy model. It is offered as Apigee X (fully managed on Google Cloud) and Apigee hybrid (runtime in your own Kubernetes, management plane in Google Cloud). It targets large organizations running formal API programs. + +Apache APISIX is an Apache Software Foundation top-level project: a gateway built on NGINX and LuaJIT, with etcd-backed dynamic configuration and 100+ plugins. It is free, self-hosted, and focused on the data plane, prioritizing performance, flexibility, and low cost. + +## Scope: Gateway vs Platform + +The most important distinction is scope. + +APISIX is a **gateway**. It excels at routing, authentication, rate limiting, traffic shaping, protocol support, observability, and AI proxying. It is the runtime layer that sits in front of your services. + +Apigee is a **platform**. It includes a gateway, but its value proposition extends to the full API business: onboarding external developers through a portal, analyzing API usage for product decisions, monetizing APIs, and governing them across their lifecycle. + +This means the comparison is rarely feature-for-feature. The real question is whether you need a focused, high-performance gateway you can run anywhere, or an end-to-end managed API management suite, and whether you are willing to trade cost and portability for that breadth. + +## Architecture and Deployment + +### Apache APISIX + +APISIX is self-hosted on any cloud, on-premises, or in Kubernetes. The data plane and control plane (Admin API plus etcd) deploy together, configuration changes propagate in real time, and you retain full control over where traffic flows and what it costs. There is no dependency on a specific cloud provider. + +### Apigee + +Apigee X is fully managed within Google Cloud, removing operational burden but coupling you to that environment. Apigee hybrid lets you run the runtime in your own Kubernetes clusters while the management plane remains in Google Cloud, offering more deployment flexibility while retaining the platform's management capabilities and its commercial model. + +## Cost + +Cost is frequently decisive. APISIX has no license fee; you pay only for the compute it runs on, and a single node sustains very high throughput, so cost per request stays low as traffic grows. Apigee is priced as an enterprise platform, typically based on API call volume and the capabilities you enable, which can become a major line item at scale. For teams whose primary need is a capable gateway, APISIX delivers that at a fraction of the platform cost. + +## Feature Comparison + +| Feature | Apache APISIX | Apigee | +|---------|--------------|--------| +| Category | Open-source API gateway | Enterprise API management platform | +| Deployment | Self-hosted anywhere | Apigee X (managed) or hybrid on Google Cloud | +| Cost | Free + infrastructure | Commercial, volume-based | +| Gateway runtime | NGINX + LuaJIT, 100+ plugins | Managed runtime, XML policies | +| Developer portal | Via complementary tooling | Built in | +| API analytics | Runtime observability (Prometheus, OTel, etc.) | Built-in business analytics | +| Monetization | Not built in | Built in | +| AI gateway capabilities | ai-proxy plugin, multi-LLM routing | Via platform features | +| Portability | Runs anywhere, no lock-in | Coupled to Google Cloud | +| Governance / lifecycle | Gateway-level | Full lifecycle management | + +## When to Choose Apache APISIX + +- **You need a high-performance gateway**, not a full management platform. +- **Cost efficiency** matters and per-call platform pricing is unattractive. +- **Multi-cloud, hybrid, or on-premises** deployment and no vendor lock-in. +- **Flexibility** to assemble your own management tooling around a focused, open-source core. + +## When to Choose Apigee + +- **You need a complete API management program**: developer portal, analytics, monetization, and lifecycle governance in one product. +- **A fully managed platform** is preferred and Google Cloud is your environment. +- **Enterprise governance** and a polished external developer experience are priorities. +- **Budget exists** for an enterprise platform in exchange for that breadth. + +## FAQ + +### Is Apache APISIX a full API management platform like Apigee? + +Not on its own. APISIX is a high-performance API gateway focused on the runtime: routing, authentication, rate limiting, traffic management, observability, and AI gateway features. Apigee is a broader API management platform that also includes a developer portal, deep API analytics, monetization, and lifecycle governance. To build a full API management program around APISIX, you pair it with complementary tooling for those higher-level functions. + +### How do the costs of Apache APISIX and Apigee compare? + +APISIX is free and open source under the Apache 2.0 license; your cost is the infrastructure you run it on. Apigee is a commercial enterprise platform with pricing based on API calls and capabilities, which can be substantial at scale. Organizations focused primarily on gateway functionality often find APISIX far more cost-effective, while those needing Apigee's full management suite weigh that against its platform cost. + +### Does Apache APISIX offer a developer portal and analytics like Apigee? + +APISIX provides strong runtime observability through integrations with Prometheus, OpenTelemetry, Datadog, SkyWalking, and others, but the open-source project does not bundle a polished developer portal, business-level API analytics, or monetization the way Apigee does. Teams that need those capabilities integrate additional tools alongside APISIX, whereas Apigee delivers them as part of one platform. + +### How do I migrate from Apigee to Apache APISIX? + +Migration usually starts with the gateway runtime: map Apigee API proxies to APISIX routes and upstreams, and translate Apigee policies (for authentication, quotas, spike arrest, and transformation) to the equivalent APISIX plugins. Higher-level Apigee features such as the developer portal and monetization are addressed separately with complementary tooling. Running both in parallel and shifting traffic incrementally allows a controlled, low-risk migration. diff --git a/website/learning-center/apisix-vs-aws-api-gateway.md b/website/learning-center/apisix-vs-aws-api-gateway.md new file mode 100644 index 00000000000..c3367f76a81 --- /dev/null +++ b/website/learning-center/apisix-vs-aws-api-gateway.md @@ -0,0 +1,106 @@ +--- +title: "Apache APISIX vs AWS API Gateway: Self-Hosted vs Managed" +description: "Compare Apache APISIX and Amazon AWS API Gateway: architecture, pricing at scale, vendor lock-in, performance, and when to choose a self-hosted open-source gateway over a managed cloud service." +slug: apisix-vs-aws-api-gateway +date: 2026-06-24 +tags: [comparison, apisix, aws-api-gateway, api-gateway] +hide_table_of_contents: false +faq: + - q: "Is Apache APISIX cheaper than AWS API Gateway?" + a: >- + It depends on traffic volume. AWS API Gateway charges per request plus data transfer, so cost scales linearly with traffic and becomes significant at high volumes. Apache APISIX is free and open source; you pay only for the compute you run it on, which is a largely fixed cost regardless of request count. For low or spiky traffic, the managed convenience of AWS API Gateway often outweighs its per-request cost. For sustained high-volume APIs, self-hosting APISIX is typically far chea [...] + - q: "Can I run Apache APISIX on AWS?" + a: >- + Yes. APISIX runs anywhere you can run a container or a Linux host, including EC2, EKS, and ECS. Many teams run APISIX on AWS to keep traffic inside their VPC while avoiding per-request gateway fees and retaining the ability to move to another cloud or on-premises later without rewriting their gateway configuration. + - q: "How do I migrate from AWS API Gateway to Apache APISIX?" + a: >- + The common approach is to stand up APISIX behind the same DNS or load balancer and shift routes incrementally. Map each API Gateway stage and resource to an APISIX route and upstream, translate authorizers to APISIX authentication plugins, and replace VTL mapping templates with request and response transformation plugins. Shifting traffic route by route with health checks allows a zero-downtime migration. + - q: "Does AWS API Gateway or Apache APISIX add more latency?" + a: >- + A self-hosted APISIX deployment running close to your backends typically adds sub-millisecond proxy overhead and avoids extra network hops. AWS API Gateway is a managed regional service, so requests traverse AWS infrastructure and are subject to service limits such as integration timeouts. For latency-sensitive workloads where you control the network path, a self-hosted gateway gives you more control over the latency floor. +--- + +Apache APISIX and AWS API Gateway solve the same problem from opposite directions. APISIX is a self-hosted, open-source gateway you run on any infrastructure, while AWS API Gateway is a fully managed, serverless service tightly integrated with the AWS ecosystem. The choice comes down to control and cost versus managed convenience and lock-in. + +## Overview + +AWS API Gateway is a managed service that handles API traffic without any servers for you to operate. It offers REST APIs, lower-cost HTTP APIs, and WebSocket APIs, and integrates natively with AWS Lambda, IAM, Cognito, CloudWatch, and WAF. You configure it through the AWS console, CloudFormation, or Terraform, and AWS operates and scales the underlying infrastructure. + +Apache APISIX is a top-level Apache Software Foundation project: a high-performance gateway built on NGINX and LuaJIT, with configuration stored in etcd and pushed to all nodes in real time. You deploy and operate it yourself, on any cloud, on-premises, or in Kubernetes, with no per-request platform fees. + +## Architecture Comparison + +### Apache APISIX Architecture + +APISIX runs as a self-hosted data plane with a built-in control plane: an Admin API, etcd-backed configuration, an optional dashboard, and a 100+ plugin ecosystem. Because configuration lives in etcd and propagates instantly, routes and policies change without restarts. You own the full request path, which means you can deploy APISIX next to your services in any environment and tune it to your hardware. + +### AWS API Gateway Architecture + +AWS API Gateway is serverless. There is no instance to size, patch, or scale, and high availability is handled by AWS within a region. Backends are typically Lambda functions, HTTP endpoints, or other AWS services, wired through integrations. The tradeoff is that the data plane is a black box: you configure behavior through AWS abstractions (stages, resources, authorizers, mapping templates) rather than operating the proxy directly, and behavior is bounded by AWS service limits. + +## Pricing and Cost at Scale + +The pricing models are fundamentally different, and this is often the deciding factor. + +AWS API Gateway charges **per request**, plus data transfer and optional caching. This is attractive at low volume because you pay nothing when idle, but cost grows linearly with traffic. At high, sustained request volumes the per-request fee can dominate the total cost of an API platform. + +Apache APISIX has **no per-request fee**. The cost is the compute you run it on, which is largely fixed regardless of how many requests flow through. A single modest node handles very high throughput, so cost per request falls as traffic grows. + +A useful rule of thumb: managed per-request pricing favors low or unpredictable traffic, while self-hosting favors sustained high volume where fixed infrastructure cost is amortized across many requests. + +## Performance and Limits + +AWS API Gateway is designed for elasticity rather than minimal latency, and it enforces hard service limits such as integration timeouts and per-region request quotas (some of which are soft limits you can request increases for). These rarely matter for typical workloads but can constrain long-running, high-throughput, or large-payload APIs. + +APISIX is optimized for low, predictable per-request overhead using NGINX's event-driven model and radix-tree route matching. Running it close to your backends removes extra network hops. Because you control the deployment, you can benchmark and tune for your own latency and throughput targets rather than working within a managed service's quotas. + +## Feature Comparison + +| Feature | Apache APISIX | AWS API Gateway | +|---------|--------------|-----------------| +| Deployment model | Self-hosted (any cloud, on-prem, hybrid, Kubernetes) | Fully managed, AWS-only | +| Pricing | Free + infrastructure cost | Per request + data transfer | +| Configuration | etcd, real-time, fully dynamic | AWS console / CloudFormation / Terraform | +| Extensibility | 100+ plugins, multi-language (Go, Java, Python, Wasm, Lua) | Lambda authorizers, VTL mapping templates | +| Protocol support | HTTP/1.1, HTTP/2, HTTP/3, gRPC, WebSocket, TCP/UDP, MQTT, Dubbo | REST, HTTP, WebSocket | +| AI gateway capabilities | ai-proxy plugin, multi-LLM routing | Via Lambda / Bedrock integrations | +| Auth | Key, JWT, OAuth 2.0, OIDC, LDAP, mTLS | IAM, Cognito, Lambda authorizers | +| Observability | Prometheus, OpenTelemetry, Datadog, SkyWalking, Zipkin | CloudWatch, X-Ray | +| Portability | Runs anywhere, no lock-in | Coupled to AWS | + +## Vendor Lock-in and Portability + +The strongest argument for a self-hosted gateway is portability. AWS API Gateway configuration, authorizers, and VTL templates are specific to AWS; moving to another cloud or on-premises means rebuilding the gateway layer. APISIX configuration is portable: the same routes, plugins, and upstreams run identically on any cloud, in your own data center, or across a hybrid deployment. For organizations pursuing multi-cloud strategies, data-residency requirements, or simply avoiding lock-in, t [...] + +## When to Choose Apache APISIX + +- **Sustained high traffic** where per-request pricing would dominate cost. +- **Multi-cloud, hybrid, or on-premises** deployments and data-residency requirements. +- **Full control** over the data plane, custom plugins, and the latency floor. +- **Rich gateway features** (advanced traffic management, multi-protocol, AI proxy) without a managed service's constraints. +- **Avoiding vendor lock-in** with a portable, open-source configuration. + +## When to Choose AWS API Gateway + +- **All-in on AWS** with Lambda or other AWS services as backends. +- **Low or spiky traffic** where paying per request beats running infrastructure. +- **No operational appetite** for running and scaling a gateway yourself. +- **Tight AWS-native integration** with IAM, Cognito, and CloudWatch as a priority. + +## FAQ + +### Is Apache APISIX cheaper than AWS API Gateway? + +It depends on traffic volume. AWS API Gateway charges per request plus data transfer, so cost scales linearly with traffic and becomes significant at high volumes. Apache APISIX is free and open source; you pay only for the compute you run it on, which is a largely fixed cost regardless of request count. For low or spiky traffic, the managed convenience of AWS API Gateway often outweighs its per-request cost. For sustained high-volume APIs, self-hosting APISIX is typically far cheaper pe [...] + +### Can I run Apache APISIX on AWS? + +Yes. APISIX runs anywhere you can run a container or a Linux host, including EC2, EKS, and ECS. Many teams run APISIX on AWS to keep traffic inside their VPC while avoiding per-request gateway fees and retaining the ability to move to another cloud or on-premises later without rewriting their gateway configuration. + +### How do I migrate from AWS API Gateway to Apache APISIX? + +The common approach is to stand up APISIX behind the same DNS or load balancer and shift routes incrementally. Map each API Gateway stage and resource to an APISIX route and upstream, translate authorizers to APISIX authentication plugins, and replace VTL mapping templates with request and response transformation plugins. Shifting traffic route by route with health checks allows a zero-downtime migration. + +### Does AWS API Gateway or Apache APISIX add more latency? + +A self-hosted APISIX deployment running close to your backends typically adds sub-millisecond proxy overhead and avoids extra network hops. AWS API Gateway is a managed regional service, so requests traverse AWS infrastructure and are subject to service limits such as integration timeouts. For latency-sensitive workloads where you control the network path, a self-hosted gateway gives you more control over the latency floor. diff --git a/website/learning-center/apisix-vs-envoy.md b/website/learning-center/apisix-vs-envoy.md new file mode 100644 index 00000000000..801a422c3a7 --- /dev/null +++ b/website/learning-center/apisix-vs-envoy.md @@ -0,0 +1,95 @@ +--- +title: "Apache APISIX vs Envoy: API Gateway vs Service Proxy" +description: "Compare Apache APISIX and Envoy. APISIX is a turnkey API gateway with a built-in control plane; Envoy is a high-performance proxy that needs a separate control plane. Covers architecture, service mesh, and when to choose each." +slug: apisix-vs-envoy +date: 2026-06-24 +tags: [comparison, apisix, envoy, api-gateway] +hide_table_of_contents: false +faq: + - q: "Are Apache APISIX and Envoy competitors or complementary?" + a: >- + They overlap but often complement each other. APISIX is most commonly used as a north-south API gateway for traffic entering your platform from clients, while Envoy is most commonly used as the east-west data plane inside a service mesh for service-to-service traffic. Many organizations run APISIX at the edge and Envoy inside the mesh. They compete directly only when you evaluate one of them for the edge gateway role. + - q: "Is Envoy faster than Apache APISIX?" + a: >- + Both are high-performance proxies and both are fast enough that raw proxy speed is rarely the deciding factor. Envoy is written in C++ and APISIX is built on NGINX and LuaJIT; real-world throughput depends heavily on your configuration, plugin or filter chain, and hardware. The more meaningful difference is operational: APISIX gives you a complete gateway out of the box, whereas Envoy's performance comes with a more complex configuration model. + - q: "Does Apache APISIX need a separate control plane like Envoy does?" + a: >- + No. APISIX ships with its own control plane: an Admin API, etcd-backed configuration, and an optional dashboard. You can run a working gateway immediately. Envoy is a data plane only; to configure it dynamically you must run a separate control plane that speaks the xDS protocol, such as Istio, Gloo, or Contour. That control plane is additional software to operate. + - q: "Should I use Apache APISIX or Envoy for a service mesh?" + a: >- + For a full service mesh with sidecar proxies and service-to-service mTLS, Envoy (typically through Istio) is the established choice; it was designed for that role. For an API gateway handling north-south traffic at the edge, with authentication, rate limiting, and a plugin ecosystem ready to use, APISIX is the more direct fit. The two roles are different, and many platforms use both. +--- + +Apache APISIX and Envoy are both high-performance proxies, but they occupy different roles. APISIX is a complete API gateway you can run immediately, with a built-in control plane and plugin ecosystem. Envoy is a powerful, programmable data plane designed to be driven by a separate control plane, and it is most at home inside a service mesh. + +## Overview + +Envoy is a CNCF graduated project, a high-performance L7 and L4 proxy written in C++. It was created as a universal data plane and is best known as the sidecar proxy in service meshes such as Istio, as well as a building block for edge gateways like Gloo and Contour. Envoy is configured statically through a bootstrap file or dynamically through the xDS family of APIs, which requires a control plane to supply that configuration. + +Apache APISIX is an Apache Software Foundation top-level project: a gateway built on NGINX and LuaJIT, with configuration in etcd and a 100+ plugin ecosystem. It includes its own control plane, so a single deployment gives you a fully functional API gateway without assembling additional components. + +## Architecture Comparison + +### Apache APISIX Architecture + +APISIX bundles the data plane and control plane together. The Admin API writes configuration into etcd, which pushes changes to all proxy nodes in real time. Gateway features are delivered as plugins that run in the request lifecycle, and an optional dashboard provides a UI. Because the control plane is built in, getting from zero to a working, dynamically configurable gateway is fast. + +### Envoy Architecture + +Envoy is intentionally just the data plane. Its power comes from the xDS APIs (LDS, RDS, CDS, EDS, and others), which let an external control plane reconfigure listeners, routes, clusters, and endpoints at runtime. This separation is excellent for large platforms that want to build their own control logic, and it is the foundation of service meshes. The cost is that Envoy alone is not a turnkey gateway: you either hand-write verbose bootstrap configuration or adopt a control plane such a [...] + +## Extensibility + +APISIX extends through plugins. It ships with 100+ built-in plugins and supports custom plugins in Lua, plus Go, Java, and Python through external plugin runners and Wasm for sandboxed extensions. Adding a capability is usually a matter of enabling and configuring a plugin. + +Envoy extends through native C++ filters and Wasm filters, and increasingly through control-plane abstractions. This is extremely powerful and is how advanced mesh features are built, but it generally demands deeper engineering investment than enabling a plugin. + +## Feature Comparison + +| Feature | Apache APISIX | Envoy | +|---------|--------------|-------| +| Primary role | North-south API gateway | Service proxy / mesh data plane | +| Control plane | Built in (Admin API + etcd) | External required (Istio, Gloo, etc.) | +| Configuration | etcd, dynamic, plugin-based | Static bootstrap or xDS | +| Out-of-the-box gateway | Yes | No (needs a control plane) | +| Extensibility | 100+ plugins, multi-language, Wasm | C++ and Wasm filters | +| Implementation | NGINX + LuaJIT | C++ | +| Authentication | Key, JWT, OAuth 2.0, OIDC, LDAP, mTLS | Via filters / control plane | +| AI gateway capabilities | ai-proxy plugin, multi-LLM routing | Via custom filters | +| Learning curve | Moderate, gateway concepts | Steeper, proxy and xDS concepts | + +## When to Choose Apache APISIX + +- **You need a complete API gateway** for north-south traffic without assembling a control plane. +- **Faster time to a working gateway**, with authentication, rate limiting, and routing ready to enable. +- **A plugin ecosystem** and AI gateway features available immediately. +- **Lower operational complexity** for edge and ingress use cases. + +## When to Choose Envoy + +- **A service mesh** with sidecar proxies and service-to-service mTLS, typically via Istio. +- **A custom platform** where you want to build your own control plane on xDS. +- **Deep, low-level programmability** through native C++ filters. +- **Standardizing one data plane** across both edge and in-mesh traffic with your own tooling. + +## Working Together + +These projects are not mutually exclusive. A common pattern places APISIX at the edge as the API gateway, handling authentication, rate limiting, and routing for incoming traffic, while Envoy operates inside the cluster as the service mesh data plane for service-to-service communication. Choosing APISIX for the gateway role does not preclude using Envoy where it excels. + +## FAQ + +### Are Apache APISIX and Envoy competitors or complementary? + +They overlap but often complement each other. APISIX is most commonly used as a north-south API gateway for traffic entering your platform from clients, while Envoy is most commonly used as the east-west data plane inside a service mesh for service-to-service traffic. Many organizations run APISIX at the edge and Envoy inside the mesh. They compete directly only when you evaluate one of them for the edge gateway role. + +### Is Envoy faster than Apache APISIX? + +Both are high-performance proxies and both are fast enough that raw proxy speed is rarely the deciding factor. Envoy is written in C++ and APISIX is built on NGINX and LuaJIT; real-world throughput depends heavily on your configuration, plugin or filter chain, and hardware. The more meaningful difference is operational: APISIX gives you a complete gateway out of the box, whereas Envoy's performance comes with a more complex configuration model. + +### Does Apache APISIX need a separate control plane like Envoy does? + +No. APISIX ships with its own control plane: an Admin API, etcd-backed configuration, and an optional dashboard. You can run a working gateway immediately. Envoy is a data plane only; to configure it dynamically you must run a separate control plane that speaks the xDS protocol, such as Istio, Gloo, or Contour. That control plane is additional software to operate. + +### Should I use Apache APISIX or Envoy for a service mesh? + +For a full service mesh with sidecar proxies and service-to-service mTLS, Envoy (typically through Istio) is the established choice; it was designed for that role. For an API gateway handling north-south traffic at the edge, with authentication, rate limiting, and a plugin ecosystem ready to use, APISIX is the more direct fit. The two roles are different, and many platforms use both. diff --git a/website/learning-center/apisix-vs-kong.md b/website/learning-center/apisix-vs-kong.md index cea0502eef8..31d19a27788 100644 --- a/website/learning-center/apisix-vs-kong.md +++ b/website/learning-center/apisix-vs-kong.md @@ -5,6 +5,19 @@ slug: apisix-vs-kong date: 2026-04-14 tags: [comparison, apisix, kong, api-gateway] hide_table_of_contents: false +faq: + - q: "Can APISIX and Kong run side by side during a migration?" + a: >- + Yes. Both gateways can operate in parallel by splitting traffic at the load balancer level. A common migration strategy routes new services through APISIX while existing services continue running through Kong. Gradual traffic shifting with health checks ensures zero-downtime migration. The timeline depends on the number of routes, custom plugins, and testing requirements. + - q: "Is APISIX harder to operate because it requires etcd?" + a: >- + etcd adds a dependency compared to Kong's DB-less mode, but in practice, etcd is a well-understood, battle-tested component already present in most Kubernetes clusters (it is the backing store for Kubernetes itself). Operating etcd requires standard distributed systems practices: run an odd number of nodes (3 or 5), monitor disk latency, and maintain regular snapshots. For teams already running Kubernetes, etcd operational knowledge is typically already available. The operational c [...] + - q: "Which gateway has better AI and LLM support?" + a: >- + Both gateways are investing in AI gateway capabilities, but they approach it differently. APISIX provides the ai-proxy plugin in its open-source edition, supporting multi-model routing, token-based rate limiting, and prompt transformation for major LLM providers. Kong offers AI Gateway plugins primarily through its enterprise edition and Konnect platform. For teams building AI-powered applications on an open-source budget, APISIX currently provides more built-in AI functionality wi [...] + - q: "How do the two gateways compare on gRPC and streaming support?" + a: >- + APISIX provides native gRPC proxying, gRPC-Web transcoding, and HTTP-to-gRPC transformation out of the box, along with support for HTTP/3 (QUIC), Dubbo, and MQTT protocols. Kong supports gRPC proxying and gRPC-Web through plugins, with HTTP/2 support on both client and upstream connections. For teams heavily invested in gRPC or multi-protocol architectures, APISIX's broader built-in protocol support reduces the need for custom plugins or sidecars. --- Apache APISIX and Kong are the two most widely adopted open-source API gateways, both built on NGINX and Lua. APISIX differentiates itself with a fully dynamic architecture powered by etcd, higher single-core throughput, and a broader protocol support matrix, while Kong offers a mature enterprise ecosystem with extensive third-party integrations and a large plugin marketplace. diff --git a/website/learning-center/apisix-vs-nginx.md b/website/learning-center/apisix-vs-nginx.md new file mode 100644 index 00000000000..35c6ef35679 --- /dev/null +++ b/website/learning-center/apisix-vs-nginx.md @@ -0,0 +1,91 @@ +--- +title: "Apache APISIX vs NGINX: API Gateway vs Reverse Proxy" +description: "Compare Apache APISIX and NGINX as API gateways. APISIX is built on NGINX but adds dynamic configuration, 100+ plugins, and an Admin API. Covers NGINX OSS, NGINX Plus, and when to choose each." +slug: apisix-vs-nginx +date: 2026-06-24 +tags: [comparison, apisix, nginx, api-gateway] +hide_table_of_contents: false +faq: + - q: "Isn't Apache APISIX just NGINX with extra steps?" + a: >- + APISIX is built on top of NGINX and LuaJIT (via OpenResty), so it inherits NGINX's proven performance, but it is not just NGINX. APISIX adds a full API gateway layer that plain NGINX lacks: dynamic configuration through etcd with no reloads, an Admin API, a 100+ plugin ecosystem for authentication, rate limiting, and observability, service discovery, and a dashboard. You get NGINX's data plane plus a complete control plane out of the box. + - q: "Do I need to know NGINX to run Apache APISIX?" + a: >- + No. APISIX is configured through its Admin API, declarative YAML, or its dashboard, using high-level concepts like routes, upstreams, services, and plugins. You do not write or maintain nginx.conf. Familiarity with NGINX concepts can help with advanced tuning, but day-to-day operation does not require editing NGINX configuration files. + - q: "How does Apache APISIX compare to NGINX Plus?" + a: >- + NGINX Plus is the commercial edition of NGINX, adding dynamic reconfiguration, active health checks, JWT authentication, and a dashboard on a subscription. APISIX provides comparable dynamic configuration, health checking, and authentication, plus a much larger plugin ecosystem and AI gateway features, as open-source software under the Apache 2.0 license with no per-instance fee. Teams evaluating NGINX Plus for gateway features often find APISIX covers the same needs without licens [...] + - q: "Can I migrate my nginx.conf to Apache APISIX?" + a: >- + Most nginx.conf reverse-proxy setups map cleanly onto APISIX concepts: server and location blocks become routes, proxy_pass upstreams become APISIX upstreams, and directives like rate limiting, header rewriting, and access control become plugins. The main shift is moving from a static file that requires reloads to dynamic configuration managed through the Admin API, which removes reload-related downtime. +--- + +NGINX is the foundation that powers much of the web as a reverse proxy and load balancer, and Apache APISIX is built directly on top of it. The real comparison is not NGINX versus a competitor, but whether to assemble an API gateway from NGINX yourself versus using a purpose-built gateway that already provides the gateway layer on the same high-performance core. + +## Overview + +NGINX (open source) is a web server, reverse proxy, and load balancer. It can act as an API gateway, but you build that capability yourself through configuration files and, for advanced logic, the njs scripting module or Lua. NGINX Plus, the commercial edition, adds dynamic reconfiguration, active health checks, JWT authentication, and a monitoring dashboard. + +Apache APISIX uses NGINX and LuaJIT (through OpenResty) as its data plane, then adds a complete API gateway on top: etcd-backed dynamic configuration, an Admin API, 100+ plugins, service discovery, and a dashboard. It is an Apache Software Foundation top-level project under the Apache 2.0 license. + +## Architecture Comparison + +### Apache APISIX Architecture + +APISIX keeps NGINX's event-driven request handling for raw performance, but moves configuration out of static files and into etcd. Changes to routes, upstreams, and plugins propagate to every node in real time, with no reloads. Cross-cutting concerns are handled by plugins rather than hand-written configuration, and everything is managed through a REST Admin API. The result is NGINX-class throughput with the operational model of a modern, dynamic gateway. + +### NGINX Architecture + +Plain NGINX stores its configuration in `nginx.conf` and related files. Applying a change requires a reload, and while reloads are graceful, configuration is fundamentally static at runtime. API gateway behavior such as per-consumer rate limiting, token authentication, or request transformation must be expressed through directives, njs, or Lua modules that you write and maintain. NGINX Plus relaxes some of these limits with a runtime reconfiguration API and built-in modules, on a commerc [...] + +## Dynamic Configuration + +This is the clearest practical difference. With open-source NGINX, adding a route or changing an upstream means editing configuration and reloading the process. In dynamic environments, such as Kubernetes with ephemeral pods or frequent deployments, this static model adds friction. + +APISIX treats configuration as live data. Routes and policies can be created, updated, and removed through the Admin API and take effect within milliseconds, with no reload and no dropped connections. This makes APISIX a natural fit for service discovery, canary releases, and automation-driven platforms. + +## Feature Comparison + +| Feature | Apache APISIX | NGINX (OSS) | NGINX Plus | +|---------|--------------|-------------|------------| +| Core data plane | NGINX + LuaJIT | NGINX | NGINX | +| Configuration | etcd, dynamic, no reload | Static files, reload required | Dynamic API (subset) | +| Plugin ecosystem | 100+ built-in plugins | Modules / njs / Lua (DIY) | Selected built-in modules | +| Admin API | Full REST API | None (file-based) | Reconfiguration API | +| Authentication | Key, JWT, OAuth 2.0, OIDC, LDAP, mTLS | DIY / njs | JWT, basic | +| Service discovery | Nacos, Consul, Eureka, DNS, Kubernetes | DNS (limited) | DNS, some integrations | +| AI gateway capabilities | ai-proxy plugin, multi-LLM routing | None | None | +| Dashboard | Apache APISIX Dashboard (OSS) | None | Included | +| License | Apache 2.0 (free) | BSD-like (free) | Commercial subscription | + +## When to Choose Apache APISIX + +- **You need API gateway features** (dynamic routing, authentication, rate limiting, transformation) without hand-building them in NGINX configuration. +- **Dynamic, automation-driven environments** where reload-based config is a bottleneck. +- **A rich plugin ecosystem and AI gateway** without a commercial license. +- **NGINX-class performance** combined with a modern control plane. + +## When to Choose NGINX + +- **Simple reverse proxy, load balancing, or static web serving** without full gateway requirements. +- **An existing, finely tuned NGINX deployment** that already meets your needs. +- **Deep, low-level control** over NGINX directives for specialized use cases. +- **An existing NGINX Plus subscription** that already covers your dynamic configuration and authentication needs. + +## FAQ + +### Isn't Apache APISIX just NGINX with extra steps? + +APISIX is built on top of NGINX and LuaJIT (via OpenResty), so it inherits NGINX's proven performance, but it is not just NGINX. APISIX adds a full API gateway layer that plain NGINX lacks: dynamic configuration through etcd with no reloads, an Admin API, a 100+ plugin ecosystem for authentication, rate limiting, and observability, service discovery, and a dashboard. You get NGINX's data plane plus a complete control plane out of the box. + +### Do I need to know NGINX to run Apache APISIX? + +No. APISIX is configured through its Admin API, declarative YAML, or its dashboard, using high-level concepts like routes, upstreams, services, and plugins. You do not write or maintain nginx.conf. Familiarity with NGINX concepts can help with advanced tuning, but day-to-day operation does not require editing NGINX configuration files. + +### How does Apache APISIX compare to NGINX Plus? + +NGINX Plus is the commercial edition of NGINX, adding dynamic reconfiguration, active health checks, JWT authentication, and a dashboard on a subscription. APISIX provides comparable dynamic configuration, health checking, and authentication, plus a much larger plugin ecosystem and AI gateway features, as open-source software under the Apache 2.0 license with no per-instance fee. Teams evaluating NGINX Plus for gateway features often find APISIX covers the same needs without licensing cost. + +### Can I migrate my nginx.conf to Apache APISIX? + +Most nginx.conf reverse-proxy setups map cleanly onto APISIX concepts: server and location blocks become routes, proxy_pass upstreams become APISIX upstreams, and directives like rate limiting, header rewriting, and access control become plugins. The main shift is moving from a static file that requires reloads to dynamic configuration managed through the Admin API, which removes reload-related downtime. diff --git a/website/learning-center/apisix-vs-traefik.md b/website/learning-center/apisix-vs-traefik.md new file mode 100644 index 00000000000..68a0223bfc7 --- /dev/null +++ b/website/learning-center/apisix-vs-traefik.md @@ -0,0 +1,95 @@ +--- +title: "Apache APISIX vs Traefik: Performance vs Auto-Discovery" +description: "Compare Apache APISIX and Traefik. APISIX offers higher throughput and a larger plugin ecosystem; Traefik offers container-native auto-discovery and automatic TLS. Covers architecture, performance, Kubernetes, and when to choose each." +slug: apisix-vs-traefik +date: 2026-06-24 +tags: [comparison, apisix, traefik, api-gateway] +hide_table_of_contents: false +faq: + - q: "Is Traefik easier to set up than Apache APISIX?" + a: >- + Traefik is known for fast setup in container environments because it auto-discovers services from Docker labels or Kubernetes resources and configures itself, with automatic HTTPS through Let's Encrypt. For a small containerized setup this is very convenient. APISIX requires defining routes and upstreams explicitly, but provides more control and a richer feature set in return. For simple auto-wired deployments Traefik feels lighter; for feature-rich gateways APISIX's explicit model [...] + - q: "How do Apache APISIX and Traefik compare on performance?" + a: >- + APISIX is built on NGINX and LuaJIT, while Traefik is written in Go. APISIX generally achieves higher single-node throughput and lower, more predictable latency, which matters most at high request volumes where per-request overhead compounds. Traefik performs well for many workloads, but teams prioritizing maximum throughput and a low latency floor tend to favor APISIX. As always, benchmark with your own workload and hardware. + - q: "Which has a larger plugin ecosystem, Apache APISIX or Traefik?" + a: >- + APISIX ships with 100+ built-in plugins and supports custom plugins in Lua, Go, Java, Python, and Wasm. Traefik uses middlewares for cross-cutting concerns and supports plugins through a Go interpreter and Wasm, with a smaller catalog. Teams needing a broad set of ready-made capabilities, including AI gateway features, generally find more available in APISIX out of the box. + - q: "Do both Apache APISIX and Traefik support Kubernetes and the Gateway API?" + a: >- + Yes. Both run as Kubernetes ingress controllers and both support the Kubernetes Gateway API. Traefik is known for automatically discovering Kubernetes services and configuring routes from annotations and CRDs. APISIX provides its own ingress controller with CRDs, standard Ingress support, and Gateway API support, with configuration propagated through etcd in real time. +--- + +Apache APISIX and Traefik are both modern, cloud-native gateways, but they optimize for different things. APISIX prioritizes raw performance and a broad, ready-to-use feature set. Traefik prioritizes developer experience through automatic service discovery and configuration. The right choice depends on whether your priority is throughput and features or container-native convenience. + +## Overview + +Traefik (Traefik Proxy) is an open-source edge router written in Go. Its signature feature is automatic configuration: it discovers services from providers such as Docker labels, Kubernetes resources, and Consul, and wires up routes without manual definitions. It includes automatic HTTPS through Let's Encrypt, a dashboard, and middlewares for cross-cutting concerns. Commercial tiers (Traefik Hub and Traefik Enterprise) add further capabilities. + +Apache APISIX is an Apache Software Foundation top-level project built on NGINX and LuaJIT, with configuration stored in etcd and a 100+ plugin ecosystem. It targets high throughput, low latency, broad protocol support, and rich gateway features, configured explicitly through an Admin API, declarative YAML, or a dashboard. + +## Architecture Comparison + +### Apache APISIX Architecture + +APISIX uses NGINX's event-driven data plane with Lua plugins and stores configuration in etcd, which propagates changes to all nodes in real time. Routes, upstreams, and plugins are defined explicitly, which gives precise control over behavior. The architecture is tuned for high single-node throughput and predictable latency, and it supports a wide range of protocols beyond HTTP. + +### Traefik Architecture + +Traefik is built around providers and dynamic discovery. Instead of defining routes by hand, you label your containers or annotate your Kubernetes resources, and Traefik builds its routing table automatically and keeps it in sync as services come and go. This is excellent for fast-moving container environments. Being written in Go, Traefik benefits from a simple deployment model (a single binary) but generally trades some raw throughput compared to an OpenResty-based data plane. + +## Performance + +Performance is a frequent reason teams choose APISIX. Its NGINX and LuaJIT foundation and radix-tree route matching deliver high throughput and low per-request overhead, which becomes important at scale where small overheads multiply into real infrastructure cost. Traefik is fast enough for a large share of workloads, but Go's runtime characteristics typically place its peak throughput below an OpenResty-based gateway. For latency-sensitive or very high-volume APIs, APISIX usually has th [...] + +## Developer Experience and Configuration + +This is where Traefik shines. Its auto-discovery means a developer can deploy a container with a few labels and have it routed and served over HTTPS automatically, with minimal gateway knowledge. For teams that value convention over configuration in container-heavy environments, this is a real productivity gain. + +APISIX favors explicit configuration. Routes and plugins are declared deliberately, which is more setup up front but yields fine-grained control, clearer auditability, and behavior that does not change implicitly as labels change. APISIX also supports service discovery integrations (Nacos, Consul, Eureka, Kubernetes), narrowing the gap for dynamic environments while keeping configuration explicit. + +## Feature Comparison + +| Feature | Apache APISIX | Traefik | +|---------|--------------|---------| +| Implementation | NGINX + LuaJIT | Go | +| Configuration style | Explicit (Admin API, YAML) | Auto-discovery from providers | +| Plugin ecosystem | 100+ built-in plugins | Middlewares + Go/Wasm plugins | +| Protocol support | HTTP/1.1, HTTP/2, HTTP/3, gRPC, WebSocket, TCP/UDP, MQTT, Dubbo | HTTP/1.1, HTTP/2, HTTP/3, gRPC, TCP/UDP | +| Automatic TLS | Via plugins / cert management | Built-in Let's Encrypt (ACME) | +| Service discovery | Nacos, Consul, Eureka, DNS, Kubernetes | Docker, Kubernetes, Consul, others | +| AI gateway capabilities | ai-proxy plugin, multi-LLM routing | Not built in | +| Kubernetes / Gateway API | Ingress controller + Gateway API | Ingress controller + Gateway API | +| License | Apache 2.0 | MIT | + +## When to Choose Apache APISIX + +- **High throughput and low latency** are priorities, especially at scale. +- **A broad, built-in feature set** including advanced traffic management and AI gateway capabilities. +- **Multi-protocol support** beyond HTTP (gRPC, MQTT, Dubbo, TCP/UDP). +- **Explicit, auditable configuration** with real-time dynamic updates. + +## When to Choose Traefik + +- **Container-native auto-discovery** with minimal manual configuration. +- **Automatic HTTPS** through built-in Let's Encrypt integration. +- **Docker and Kubernetes label-driven** workflows where convention beats configuration. +- **A simple single-binary Go deployment** for small to moderate workloads. + +## FAQ + +### Is Traefik easier to set up than Apache APISIX? + +Traefik is known for fast setup in container environments because it auto-discovers services from Docker labels or Kubernetes resources and configures itself, with automatic HTTPS through Let's Encrypt. For a small containerized setup this is very convenient. APISIX requires defining routes and upstreams explicitly, but provides more control and a richer feature set in return. For simple auto-wired deployments Traefik feels lighter; for feature-rich gateways APISIX's explicit model pays off. + +### How do Apache APISIX and Traefik compare on performance? + +APISIX is built on NGINX and LuaJIT, while Traefik is written in Go. APISIX generally achieves higher single-node throughput and lower, more predictable latency, which matters most at high request volumes where per-request overhead compounds. Traefik performs well for many workloads, but teams prioritizing maximum throughput and a low latency floor tend to favor APISIX. As always, benchmark with your own workload and hardware. + +### Which has a larger plugin ecosystem, Apache APISIX or Traefik? + +APISIX ships with 100+ built-in plugins and supports custom plugins in Lua, Go, Java, Python, and Wasm. Traefik uses middlewares for cross-cutting concerns and supports plugins through a Go interpreter and Wasm, with a smaller catalog. Teams needing a broad set of ready-made capabilities, including AI gateway features, generally find more available in APISIX out of the box. + +### Do both Apache APISIX and Traefik support Kubernetes and the Gateway API? + +Yes. Both run as Kubernetes ingress controllers and both support the Kubernetes Gateway API. Traefik is known for automatically discovering Kubernetes services and configuring routes from annotations and CRDs. APISIX provides its own ingress controller with CRDs, standard Ingress support, and Gateway API support, with configuration propagated through etcd in real time. diff --git a/website/src/pages/comparisons.tsx b/website/src/pages/comparisons.tsx index c5834754ac6..0695f7a55c7 100644 --- a/website/src/pages/comparisons.tsx +++ b/website/src/pages/comparisons.tsx @@ -20,6 +20,36 @@ const COMPARISONS: Comparison[] = [ 'Architecture, performance benchmarks, plugin ecosystem, Kubernetes support, and when to choose each.', to: '/learning-center/apisix-vs-kong/', }, + { + title: 'Apache APISIX vs AWS API Gateway', + description: + 'Self-hosted open source vs a managed cloud service — architecture, cost at scale, and vendor lock-in.', + to: '/learning-center/apisix-vs-aws-api-gateway/', + }, + { + title: 'Apache APISIX vs NGINX', + description: + 'APISIX is built on NGINX — what a purpose-built gateway adds over raw NGINX and NGINX Plus.', + to: '/learning-center/apisix-vs-nginx/', + }, + { + title: 'Apache APISIX vs Envoy', + description: + 'A turnkey API gateway vs a service proxy that needs a separate control plane.', + to: '/learning-center/apisix-vs-envoy/', + }, + { + title: 'Apache APISIX vs Traefik', + description: + 'Throughput and plugin breadth vs container-native auto-discovery and automatic TLS.', + to: '/learning-center/apisix-vs-traefik/', + }, + { + title: 'Apache APISIX vs Apigee', + description: + 'An open-source gateway vs a full enterprise API management platform — scope and cost.', + to: '/learning-center/apisix-vs-apigee/', + }, { title: 'Open-source API gateways compared', description: diff --git a/website/static/llms.txt b/website/static/llms.txt index d6cb7d5ce15..6f0ce3f1c7c 100644 --- a/website/static/llms.txt +++ b/website/static/llms.txt @@ -59,4 +59,9 @@ - [What is Mutual TLS (mTLS)? How Two-Way Authentication Works](https://apisix.apache.org/learning-center/what-is-mutual-tls): mTLS and zero-trust security - [API Gateway Security: Threats, Best Practices & Implementation](https://apisix.apache.org/learning-center/api-gateway-security): API security, WAF, rate limiting, zero trust - [Apache APISIX vs Kong: Feature Comparison & Performance Benchmarks](https://apisix.apache.org/learning-center/apisix-vs-kong): APISIX vs Kong comparison +- [Apache APISIX vs AWS API Gateway: Self-Hosted vs Managed](https://apisix.apache.org/learning-center/apisix-vs-aws-api-gateway/): Open-source self-hosted gateway vs managed cloud service, cost at scale, lock-in +- [Apache APISIX vs NGINX: API Gateway vs Reverse Proxy](https://apisix.apache.org/learning-center/apisix-vs-nginx/): How APISIX builds a full API gateway on top of NGINX; NGINX Plus comparison +- [Apache APISIX vs Envoy: API Gateway vs Service Proxy](https://apisix.apache.org/learning-center/apisix-vs-envoy/): Turnkey gateway vs a proxy that needs a separate control plane; service mesh +- [Apache APISIX vs Traefik: Performance vs Auto-Discovery](https://apisix.apache.org/learning-center/apisix-vs-traefik/): Throughput and plugin breadth vs container-native auto-discovery and automatic TLS +- [Apache APISIX vs Apigee: Open-Source Gateway vs API Management Platform](https://apisix.apache.org/learning-center/apisix-vs-apigee/): Open-source gateway vs full enterprise API management platform, scope and cost - [MCP Protocol & AI Gateways: Managing AI Agent Traffic at Scale](https://apisix.apache.org/learning-center/mcp-protocol-ai-gateway): MCP and AI gateway architecture
