Differences between Cloud-native API Gateway and self-built gateways - API Gateway

This topic compares Cloud-native API Gateway with a self-built gateway in cost, stability, security, ease of use, and scalability.

Item		Cloud-native API Gateway	Self-built ingress-nginx	Self-built Spring Cloud Gateway	Self-built Higress
Cost	Resource cost	Resources are fully managed and O&M-free. You do not need to provide CPU and memory resources. This helps reduce resource costs.	Resource O&M is required. You must provide CPU and memory resources. Resource costs are high.	Resource O&M is required. You must provide CPU and memory resources. Resource costs are high.	Resource O&M is required. You must provide CPU and memory resources. Resource costs are high.
Cost	System development cost	Combines an API gateway, traffic gateway, and microservices gateway to save cost by 50% in container and microservices scenarios. Provides a built-in traffic monitoring feature free of charge.	You must create microservices gateways in scenarios in which microservices are deployed. If you want to use the metric monitoring and log analysis features, you must purchase additional resources and products.	In Kubernetes scenarios, you must separately create Ingress gateways. If you want to use the metric monitoring and log analysis features, you must purchase additional resources and products.	You must purchase resources that are required to develop a platform, and invest efforts in upgrading and maintaining the platform. The cost of manual O&M is high.
Stability	High availability	Gateway nodes are deployed across multiple zones and node failures are automatically detected and fixed. An SLA of up to 99.99% is provided.	You must develop a high-availability system on your own that may deliver a low SLA.	You must develop a high-availability system on your own that may deliver a low SLA.	You must develop a high-availability system on your own that may deliver a low SLA.
	Performance	If the CPU utilization ranges from 30% to 40%, the transactions per second (TPS) performance of cloud-native gateways is about 90% higher than that of open source NGINX Ingress gateways and is about 100% higher than that of open source Spring Cloud gateways. Transport Layer Security (TLS) offloading is implemented based on hardware and software integration. This helps improve server performance and decrease the response time.	Manual performance tuning is required.	Manual performance tuning is required.	Manual performance tuning is required.
	Monitoring and alerting	Deeply integrated with CloudMonitor, Simple Log Service, and Tracing Analysis to provide a wide range of dashboards and service-level monitoring features. Supports custom alert rules and alert channels such as DingTalk, phone calls, and text messages to facilitate troubleshooting.	You must develop a monitoring and alerting system on your own.	You must develop a monitoring and alerting system on your own.	You must develop a monitoring and alerting system on your own.
Security	Web application firewall	A built-in web application firewall is provided to decrease the request processing duration and response time. Route-level protection is used instead of instance-level protection.	A separate web application firewall is used and security protection is time-consuming.	A separate web application firewall is used and security protection is time-consuming.	A separate web application firewall is used and security protection is time-consuming.
Security	Authentication	Multiple authentication methods such as JSON Web Token (JWT) and OAuth are used. Route-level blacklists and whitelists are provided. Security plug-ins are supported.	You must configure complex security and authorization settings on your own.	You must configure complex security and authorization settings on your own.	You must configure complex security and authorization settings on your own.
Ease of use	Full-lifecycle API management	Provides full-lifecycle management capabilities, including API design, development, testing, publishing, and unpublishing.	You must develop these capabilities on your own.	You must develop these capabilities on your own.	You must develop these capabilities on your own.
	Routing	HTTP rewrites, redirects, overwrites, and throttling are supported. Supports warm-up in addition to standard load balancing capabilities such as round robin polling, random polling, minimum-number polling, and consistent hashing. The warm-up feature allows requests sent to a backend machine to smoothly increase without affecting business during a hot configuration update.	HTTP rewrites, redirects, overwrites, and throttling are supported. Hot configuration updates are not supported. Reloads are required during configuration updates, which lead to traffic jitter.	HTTP rewrites, redirects, overwrites, and throttling are supported. Hot configuration updates are not supported. Reloads are required during configuration updates, which lead to traffic jitter.	HTTP rewrites, redirects, overwrites, and throttling are supported. Supports warm-up in addition to standard load balancing capabilities such as round robin polling, random polling, minimum-number polling, and consistent hashing. The warm-up feature allows requests sent to a backend machine to smoothly increase without affecting business during a hot configuration updates.
	Throttling and degradation	By default, Cloud-native API Gateway is integrated with Sentinel to provide route-level fine-grained throttling and degradation policies. You can implement throttling and degradation without the need to modify business code.	Route-level throttling policies are not supported.	Supported.	Supported.
	Service discovery	Supports a rich variety of service discovery methods, such as Kubernetes, Nacos, ZooKeeper, DNS, fixed IP address, and Alibaba Cloud Serverless App Engine (SAE).	Kubernetes clusters can be used for service discovery.	Nacos instances and ZooKeeper instances can be used for service discovery.	Supports Kubernetes, Nacos, ZooKeeper, DNS, and fixed IP address.
Scalability	Plug-in marketplace	WebAssembly plug-ins are supported. You can use Lua scripts that are written in non-Java programming languages to perform rolling updates of plug-ins. The updates take effect in milliseconds.	Lua scripts are supported. Process reloading is required for plug-in updates.	Java filter extension is supported.	WebAssembly plug-ins are supported. You can use Lua scripts that are written in non-Java programming languages to perform rolling updates of plug-ins. The updates take effect in milliseconds.