NGINX to APISIX – Redefining Airline Gateway Dynamics

January 24, 2024

Case Study

Overview

About

Named the World's 5-star Airline by Skytrax, this leading airline company has been operating safely for 30 years, covering a total of nearly 1,900 international routes, including scheduled passenger transport, charter flights for resumption of work and school, and passenger flights in Asia, Europe, Africa, North America, and Oceania, etc.

As a rapidly growing airline, this leading airline company needed an API gateway to facilitate efficient flight booking processes, integrate and connect with different systems and services, and handle high-concurrency scenarios and financial and risk data.

Challenges

  • The rise of microservices and containerized deployments poses difficulty in managing the increasing NGINX instances and diverse domain configurations.
  • The coexistence of too many versions of NGINX increases the complication of upgrading, compiling, and adapting the plugins.
  • The previous API gateway can only meet the basic requirements of this leading airline company, but can't provide advanced ones like circuit breaker, canary release, etc.

Results

  • The multi-node configuration is simplified, greatly improving the development efficiency and saving management costs thanks to APISIX's hot reloading feature.
  • The leading airline company leverages APISIX's inclusive plugin ecosystem to perform more advanced functions, simplifying the upgrading of plugins and systems.
  • The upgrade improves the gateway's efficiency and maintainability—a crucial shift towards organized, modular, and reusable configuration management.

Background

This leading airline company has been using NGINX as its north-south gateway for a considerable period. However, despite effectively handling its traffic needs as the business and product portfolio expanded, the company encountered increasing pain points in various aspects.

1. Multiple NGINX Instances and Domains

Within this company, there were multiple NGINX instances, and sets of different domains, the complexity of which increased the management difficulty. The core of NGINX lies in its configuration files. As the number of NGINX instances grew, relying solely on copying files through SCP for configuration management became increasingly difficult. Especially with the widespread use of microservices and containerized deployment in the backend, there was a higher demand for flexibility in reverse proxy configuration, leading to a significant increase in the workload for configuration consistency.

2. Various NGINX Versions and Troublesome Plugin Upgrades

Due to historical reasons, the team was using multiple versions of NGINX concurrently along with numerous NGINX plugins. While upgrading NGINX itself posed no significant challenges, the difficulty arose when upgrading, compiling, and adapting various plugins. Many of these were unofficial, making troubleshooting during compilation challenging. Moreover, ensuring compatibility with NGINX versions was not guaranteed.

3. Lack of Standards for NGINX Configurations

Inheriting systems from various teams led to a plethora of NGINX configuration practices, showcasing numerous approaches without a standardized configuration. The absence of a unified configuration standard underscored the diversity in implementation methods across teams, highlighting the need for a cohesive and standardized approach to NGINX configurations.

4. Insufficient Modern Gateway Features

While NGINX efficiently met fundamental north-south gateway demands like reverse proxy and load balancing, the company's dynamic business requirements necessitated advanced features. Implementing services such as circuit breaking, security controls, and canary release became challenging when relying solely on NGINX, prompting the exploration of more robust solutions.

Gateway Selection for Precise Business Needs

To address the challenges faced with NGINX, this leading airline company meticulously outlined three primary fundamental requirements for a new gateway solution:

  1. Ease of Management and Configuration: They require a solution that facilitates easy and unified management and deployment of configurations such as routes and upstream services across multiple gateway nodes.
  2. More Advanced Features of API Gateway: The new gateway must fulfill modern API gateway business requirements, including circuit breaking, security controls, and canary release.
  3. Ease of Use and Low Learning Curve: Considering lowering the management cost, the team expects the new gateway solution to meet most basic requirements through configuration and low-code methods effortlessly.

After clarifying the iterative upgrades and basic requirements for its existing north-south gateway, the company researched various popular products in the market and ultimately chose APISIX as their new gateway.

Why Not OpenResty

During the research, OpenResty was considered first, a widely adopted solution by some companies. Its major advantage was the full compatibility of configuration files with NGINX. Migrating from NGINX to OpenResty was not so difficult for the company, although there existed setups of complex domains.

However, compared to Kong and APISIX, OpenResty's open-source version lacked comprehensive plugins and a dashboard for visual configuration. Users had to engage in coding with to meet some basic functionalities.

Why Not Kong

The airline company considered Kong as an alternative. Although its default plugins addressed most requirements, the open-source version's visual interface (Dashboard) remained unchanged for several years, prompting a preference for solutions with more updated and user-friendly interfaces.

In stress tests, APISIX outperformed Kong, showing impressive performance—twice that of Kong without plugins and up to ten times better with rate limiting and Prometheus plugins enabled. Additionally, APISIX, based on OpenResty, demonstrated excellent routing capabilities, boosting the team's confidence.

Why Not Envoy

Despite Envoy's impressive features, the C++ language and the steeper learning curve, particularly for the technical team's limitation, led the team to decide against choosing Envoy as the preferred gateway solution.

In the end, the technical team opted for APISIX as their new gateway due to its recognized functionality and performance.

Why Does APISIX Stand Out?

APISIX stood out compared to Kong for two main reasons.

  • APISIX Dashboard

    With the Dashboard, the technical team can conveniently manage various routes and plugin configurations. Notably, the APISIX Dashboard is an open-source part of the project, ensuring continuous updates in line with APISIX's development, providing an enhanced management experience.

  • Apache Open Source Project

    Being a top-level project in the Apache Software Foundation, APISIX made it easier for users to find relevant technical documentation compared to Kong. Having the support of the Apache community provided with reliable technical assistance when facing challenges makes APISIX a more suitable choice for the airline company.

Besides, APISIX effectively addresses the pain points mentioned earlier regarding NGINX.

  • APISIX stores configurations in etcd, allowing developers to manage multiple APISIX nodes for different domains with ease by deploying a single etcd cluster.

  • APISIX comes with common plugins, including health checks and other monitoring plugins, eliminating concerns about compatibility and upgrades similar to those faced with NGINX.

  • APISIX includes various security and traffic control plugins, effortlessly enabling features like circuit breaking, security controls, canary releases, and more.

Overall, APISIX stands out as the most suitable product for the technical team.

Migrating from NGINX to APISIX: Exploring Advanced but Simpler Solutions

In NGINX, domain management and the implementation of functionalities are primarily achieved through NGINX configuration files. While still based on NGINX and OpenResty, APISIX adopts a completely different approach, no longer using NGINX configuration files to manage domains and implement functionalities.

Instead, APISIX configures routes and upstreams based on domain names and implements various additional features on these routes through plugins. The built-in CORS plugin of APISIX can be adopted to achieve cross-region configurations, saving the need to convert it line by line.

Below is a code comparison between configuring in NGINX and APISIX.

#   NGINX  conf
    add_header 'Access-Control-Allow-Origin' $corsHost;
    add_header 'Access-Control-Allow-Methods' 'GET,POST,OPTIONS';
    add_header 'Access-Control-Allow-Credentials' 'true';
    add_header 'Access-Control-Allow-Headers' 'DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Accept,Authorization,appver';
    if ($request_method = 'OPTIONS') {
            return 204;
     }

#  APISIX  plugins config
    "cors": {
      "allow_credential": true,
      "allow_headers": "DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Accept,Authorization,appver",
      "allow_methods": "GET,POST,PUT,OPTIONS",
      "allow_origins": "https://wap.test.com,http://wap.test.com,",
    },
    "response-rewrite": {
      "status_code": 204,
      "vars": [
        [
          "request_method",
          "==",
          "OPTIONS"
        ]
      ]
    }

By comparing NGINX and APISIX, it can be easily found that the NGINX configuration may appear more concise, but for individuals unfamiliar with NGINX and CORS, understanding the underlying meaning might not be so straightforward. In contrast, APISIX encapsulates different functions into plugins, making the configuration more modular. Therefore, it becomes more obvious to find features and understand the functions. Similar examples of migrating configuration from NGINX to APISIX exist for various scenarios, such as configuring WebSocket in NGINX.

Achievements

Simplified Multi-Node Configuration Management

APISIX improves configuration storage with etcd, making it easier to manage diverse APISIX nodes across multiple domains. This simplifies tasks by using a single etcd cluster, ensuring effective control over different APISIX instances with specific domain setups. Besides, the centralized method reduces complexity, promotes smooth management, and enhances the scalability and efficiency of APISIX in various domain scenarios. Consequently, in the airline company, deploying a single etcd cluster is sufficient to oversee different APISIX instances linked to distinct domain setups.

Streamlined Operations with APISIX Plugins

APISIX comes with built-in plugins like common health checks, similar to frequently used plugins in NGINX. This feature eliminates the need for the airline company to worry about issues related to upgrades and compatibility. The inclusion of these plugins in APISIX ensures seamless functionality and alleviates concerns associated with upgrading and maintaining compatibility, providing a hassle-free experience for the airline company.

Furthermore, in APISIX, features like cross-origin resource sharing (CORS) and WebSocket support can be seamlessly implemented using plugins. This approach not only simplifies the development process but also contributes to a more sophisticated and efficient resolution of the airline company's challenges.

Established a Comprehensive API Gateway

APISIX comes equipped with various security and traffic control plugins, facilitating the effortless implementation of service throttling, security measures, and gradual releases. This empowers the airline company to leverage a broader range of foundational and advanced features. The adoption of APISIX translates into a significant achievement for the airline, enabling enhanced service reliability, robust security controls, and efficient deployment strategies such as gradual releases, ultimately contributing to an elevated operational capacity and performance.

Revamped Legacy Configurations into Reusable Modules

Throughout the entire upgrade process, the technical team discovered numerous outdated configurations in the existing NGINX setup, many of which involved nonsensical copy-pasting. This upgrade served as a comprehensive overhaul of their entire north-south gateway, focusing particularly on the functionalities provided by APISIX, such as plugin_config. These features significantly facilitated the modularized management and reuse of configurations at the gateway level. The implementation of APISIX's plugin_config and related capabilities not only streamlined the configuration process but also enhanced the overall efficiency and maintainability of our north-south gateway. This upgrade marked a pivotal shift towards a more organized, modular, and reusable configuration management approach.

Summary

From April 2023, this leading airline company initially encountered APISIX, to the successful migration from NGINX to APISIX in the production environment in July of the same year, the entire migration process has yielded satisfactory results.

In the early stages of migration, the technical team dealt with various historical configurations and raised concerns about whether APISIX plugins could fully replicate all the functionalities of our existing NGINX. However, the final outcome demonstrated that APISIX plugins were more than capable of meeting this challenge.

In summary, APISIX provided a more elegant solution and helped the leading airline company march into a new technical phase. It has perfectly addressed the various pain points we encountered in NGINX and its rich set of plugins allows the airline company to easily tackle various new requirements posed by clients.

Tags:
Airlines