Comparison between MSE cloud-native gateways and other open source self-managed gateways - Microservices Engine

This topic describes the differences between Microservices Engine (MSE) cloud-native gateways and self-managed gateways in terms of cost, stability, security, ease of use, and scalability.

Item		MSE cloud-native gateway	Self-managed NGINX Ingress gateway	Self-managed Spring Cloud gateway
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. MSE offers a discount for your purchase. You can receive a higher discount the first time you purchase Microservices Registry, Microservices Governance, and a cloud-native gateway at the same time. MSE provides you with higher performance and lower costs. Note The actual prices are subject to the product buy page.	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	Ingress gateways are integrated with microservice gateways. Costs are reduced by 50% in scenarios in which containers and microservices are deployed. MSE cloud-native gateways are integrated with Prometheus Service and Log Service. You can use these services free of charge.	You must create microservice 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.
Stability	High availability	Gateways are deployed across multiple zones and failures are automatically detected and fixed. A service-level agreement (SLA) of up to 99.95% is provided.	You must develop a high-availability system that may deliver a low SLA.	You must develop a high-availability system 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.
	Monitoring and alerting	MSE cloud-native gateways are deeply integrated with Prometheus Service, Log Service, and Tracing Analysis. MSE cloud-native gateways provide various dashboards, display metric data at the service level, and send alert notifications by using DingTalk messages, phone calls, and text messages. MSE cloud-native gateways also allow you to create custom alert rules. This helps locate abnormal gateways.	You must develop a monitoring and alerting system.	You must develop a monitoring and alerting system.
Security	Web application firewall (WAF) protection	A built-in WAF is provided to decrease the request processing duration and response time. Route-level protection is used instead of instance-level protection.	A separate WAF is used and security protection is time-consuming.	A separate WAF 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 manually configure complex security and authorization settings.	You must manually configure complex security and authorization settings.
Ease of use	Protocol conversion	HTTP-to-Dubbo conversion is supported.	Manual operations are required.	Manual operations are required.
	End-to-end canary release	Cloud-native gateways can work with Microservices Governance to implement an end-to-end canary release without requiring you to modify business code.	Manual operations are required.	End-to-end canary release is supported.
	Throttling and degradation	By default, cloud-native gateways are integrated with Sentinel to provide routing-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.	Throttling and degradation are supported.
	Service discovery capabilities	The following service sources can be used for service discovery: Kubernetes clusters, Nacos instances, ZooKeeper instances, DNS, fixed IP addresses, Alibaba Cloud Enterprise Distributed Application Service (EDAS), and Serverless App Engine (SAE).	Kubernetes clusters can be used for service discovery.	Nacos instances and ZooKeeper instances can be used for service discovery.
	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. Reloading is required because rolling updates are not supported for route configuration updates. Traffic performance may become unstable.	HTTP rewrites, redirects, overwrites, and throttling are supported. Reloading is required because rolling updates are not supported for route configuration updates. Traffic performance may become unstable.
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.