Born at China’s ZhiLiu Technology in April 2019, it was open sourced that June and entered the Apache Incubator in October last year.
Originally with only about 20 contributors, after seven months of incubation, there are now close to 100 contributors, including 26 committers, according to Ming Wen, vice president of the project.
In a market rife with API gateway options, why create a new one?
Cloud native architectures bring a whole new level of challenges, as does traffic from websites, mobile and IoT applications, according to Wen.
“We investigated several popular open source API gateway projects and found that none of them can solve these new challenges brought by cloud native and microservices,” he said.
“Some are only suitable for handling enterprise intranet traffic and cannot handle tens of thousands of client requests; some rely on relational databases, which cannot be easily and elastically scaled. This is mainly because the technology is evolving too fast. When the architecture of these API gateways was designed, cloud native and microservices had not yet become popular.
“We have also considered implementing an API gateway based on Envoy, but Envoy is more difficult to get started and develop, and it is not suitable for use in north-south traffic.”
APISIX is designed to handle a large number of requests, and to have a low threshold for secondary development, he said. It’s pronounced “API six”; the original company offers a commercial version, API7.
Wen outlined the design criteria this way:
- Cloud native, lightweight and easy to containerize
- Integrate statistics and monitoring components such as Prometheus, Apache Skywalking and Zipkin.
- Support proxy protocols such as gRPC, Dubbo, WebSocket, MQTT, and protocol transcoding from HTTP to gRPC to adapt to a wider range of scenarios
- Take on the role of OpenID Relying Party, connect with the services of Auth0, Okta and other identity authentication providers
- Support serverless by dynamically executing user functions at runtime, making the edge nodes of the gateway more flexible
- Support hot loading of plug-ins
- Not lock in users, support hybrid cloud deployment architecture
- Finally, the gateway node should be stateless and can be expanded and flexible.
“With these features, the user’s service is only concerned with the business itself, while non-business-implementation related features such as service discovery, authentication, statistics, metrics, etc. can be addressed at the gateway,” Wen said.
“From this point of view, the API gateway can either replace Nginx to handle north-south traffic or fulfill the role of the Istio control plane and Envoy data plane to handle east-west traffic.
APISIX consists of a data plane to dynamically control request traffic; a control plane to store and synchronize gateway data configuration, and an AI plane to orchestrate plugins, as well as real-time analysis and processing of request traffic.
It’s built atop the Nginx reverse proxy server and the key-value store etcd to provide a lightweight gateway. It’s primarily written in Lua, a programming language similar to Python. It uses Radix tree for routing and prefix tree to perform IP matching.
Using etcd to store configurations instead of a relational database puts it closer cloud native, according to Wen, but also ensures availability of the entire gateway system even when any server is down.
All components are written as plug-ins, so its modular design means developers of features only have to concern themselves with their own project.
Its built-in plug-ins include current and speed limiting, identity authentication, request rewriting, URI redirection, open tracing and serverless.
It supports both OpenResty and Tengine run environments and can run on bare metal to Kubernetes. It supports both X86 and ARM64.
In a Medium post, Wen points to specific differences with competitors:
- “Inherit” on-demand
- Allowing mounting at all stages of Nginx
- Plug-in hot loading and unloading
“We developed Kubernetes ingress controllers based on Apache APISIX to replace the Kubernetes-native ingress to handle all north-south container clusters and part of east-west traffic. APISIX’s high-performance routing, flexible plugin mechanism, API management and design concepts are just the needs of cloud native architecture,” said Shun Zhang, senior R&D director at speech recognition startup AISpeech.
The project touts its performance, low latency and scalability for microservices architectures. It maintains it provides five to 10 times performance improvement over competitors.
These companies are contributing to the project and providing feedback “which forms a virtuous circle and promotes the diversity and healthy development of the community. This is also the charm of open source,” he said.
In seven months, the project has had six releases.
Nirojan Selvanathan, software engineer at Salzberg Research in Austria, says in a video that in its work for the eFactory project, it found three advantages to APISIX:
- Dealing with the latency involved in working with multiple platforms.
- Modularity and stateless architecture provided an easier way to write plug-ins for dealing with multiple platforms and multiple authentication systems.
- MQTT support was a natural fit for the manufacturing data it was dealing with.
More Kubernetes, AI
“Recent growth in demand for interconnection between mobile applications, enterprise interoperability, and the Internet of Things have expanded backend service support objects from single web applications to a variety of usage scenarios. This increases both the access pressure and the complexity of backend services. A suitable solution for this issue is an API gateway. … We evaluated many API gateways, and finally chose Apache APISIX as the core component of our new generation API gateway because of its high performance, high scalability, and active community,” said Hui Li, engineer at Tencent Cloud.
Going forward, the project plans to enhance the control plane to make APISIX easier to run in the Kubernetes environment.
It’s also expanding its AI plane capabilities. Functions such as load balancing, dynamic upstream, and identity authentication are not enough to cope with the current complex and changeable terminal requests, according to Wen. In that vein, help users complete some AIOps functions at the traffic processing level and improve work efficiency.
It also plans to address service mesh, which he calls “a very important direction.”