Why do big companies have API gateways? It’s not as simple as you think!

[[319983]]

In this article, we will explore the role of the current API gateway.

1. The Use of API Gateway

API Gateway The following three scenarios will be used in my analysis.

1. Open API

Enterprises need to open up their own data, capabilities, etc. as development platforms, usually in the form of REST. The best examples are Taobao Open Platform, Tencent's QQ Development Platform, and WeChat Open Platform.

The Open API open platform will inevitably involve the access of customer applications, the management of API permissions, the management of call times, etc. There will inevitably be a unified entrance for management, which is when the API gateway can play a role.

2. Microservice Gateway

The concept of microservices was first proposed in 2012. With the vigorous promotion of Martin Fowler, microservices have been vigorously developed since 2014.

In the microservice architecture, there is a component that can be said to be indispensable, that is, the microservice gateway, which handles load balancing, caching, routing, access control, service proxy, monitoring, logging, etc. The API gateway exists in the microservice architecture as a microservice gateway.

3. API service management platform

The above-mentioned microservice architecture may be difficult to implement for enterprises. Enterprises have many legacy systems, and extracting all of them into microservices would require too much modification and be too costly for enterprises.

However, since there are a large number of API services calling each other between different systems, it is necessary to manage the service calls between systems, clearly see the call relationships between each system, monitor the calls between systems, etc.

API gateway can solve these problems. We can think that if the microservice architecture is not implemented on a large scale, then the microservice gateway is the API service management platform of the enterprise.

2. The position of API gateway in the overall enterprise architecture

As the complexity of an enterprise's information system increases, there will inevitably be external partner applications, the enterprise's own public network applications, and enterprise intranet applications. These three types of applications should be distinguished in the architecture, and the arrangement levels and access methods of the three applications are also different.

Therefore, in my design, these three applications are managed by different gateways, namely: API Gateway (OpenAPI partner application), API Gateway (internal application), API Gateway (internal public network application).

3. How to use API Gateway in enterprises

1. For the API gateway used by OpenAPI, partners generally need to access the OpenAPI platform in the form of applications, and partners need to apply for applications on the OpenAPI platform.

Therefore, in addition to the OpenAPI gateway, there needs to be a platform for partners to use, which requires the OpenAPI gateway to provide an API for this user platform to access.

The following architecture:

Of course, in simple scenarios, it may not be necessary to provide a portal for partners. The company's operations staff can directly add partner application IDs/keys, etc. In this case, there is no need for a partner portal subsystem.

2. For the API gateway of the intranet, it can be considered as a microservice gateway or as an API service governance platform of the intranet.

When an enterprise manages all applications using a microservices architecture, the API gateway plays the role of a microservices gateway.

When an enterprise only uses REST API to access calls between systems and uses API gateway to manage the calls, the API gateway plays the role of API service governance.

The architecture reference is as follows:

3. For the company's internal public network applications (such as APP, company website), if the management is more meticulous, it is possible that an independent API gateway can handle this part of the internal public network applications in the architecture. If you want a simpler processing, you can also use an API gateway for partners.

If you use a separate API gateway, there are the following benefits:

• The priorities for partners and the company's main business are different, and different API gateways can isolate business impacts.
• The management process for internal API usage may be different from the management process for partner-facing APIs.
• The internal API's requirements for functional expansion and other aspects are generally greater than the OpenAPI's requirements for functions.

Based on the above analysis, if the company has the ability, it is recommended to use the partner OPEN API gateway and the internal public network application gateway separately.

4. What are the competing solutions for API Gateway?

1. For the API gateway of the Open API platform, I analyzed that the API gateway can only be chosen as a solution. The industry has not found any other better solution that can be used as the entrance to the Open API platform.

2. For API gateways that serve as microservice gateways, the industry has many options for solutions to choose from, which also depends on the implementation of the microservice. Some implementations of microservice architecture do not require a microservice gateway.

• Service Mesh is an emerging architecture based on a non-API gateway. It shields access to the network layer through a proxy on the client, thus minimizing changes to the application layer. Currently, Service Mesh products are still under development, and there are no mature products that can be directly applied. The fastest growing product is Istio. It is recommended that you pay close attention to the development and business use of related products.

• Based on the duboo architecture, a gateway is usually not required in this architecture. The client directly accesses the service provider, and the registration center returns the address of the service provider to the client.

[[319984]]

5. API Gateway Solution

Private cloud open source solutions are as follows:

• Kong kong is a solution for secondary development based on Nginx+Lua, https://konghq.com/
• Netflix Zuul, zuul is a recommended component of spring cloud, https://github.com/Netflix/zuul
• orange, this open source program is developed by Chinese people, http://orange.sumory.com/

Public cloud solutions:

• Amazon API Gateway, https://aws.amazon.com/cn/api-gateway/
• Alibaba Cloud API Gateway, https://www.aliyun.com/product/apigateway/
• Tencent Cloud API Gateway, https://cloud.tencent.com/product/apigateway

Self-developed solutions:

• Based on the solution of Nginx+Lua+OpenResty, you can see that Kong and orange are based on this solution
• Based on Netty and non-blocking IO model. Through online search, we can see that some domestic companies such as Yirendai are based on this solution, which is a mature solution.
• Node.js-based solution. This solution uses the inherent non-blocking characteristics of Node.js.
• Based on Java Servlet solution. Zuul is based on this solution, which is not efficient, which is why Zuul is always criticized.

6. How do enterprises choose API gateways?

If you want to choose an existing API gateway, you need to consider the following aspects.

1. Performance and availability

Once an API gateway is adopted, it will serve as the core of the enterprise application, so performance and availability are essential requirements.

From the performance point of view, the time consumption of the gateway should be as short as possible, and I think it should be less than 10ms. The system needs to use non-blocking IO, such as epoll, NIO, etc.

The interaction between the gateway and various dependencies also needs to be non-blocking, so as to ensure the high availability of the overall system, such as responsive programming of Node.js and RxJava and Future based on Java. The gateway must support cluster deployment, and the crash of a server should not affect the availability of the overall system. Multiple gateways should support the same management platform and the same monitoring center. For example, an enterprise's OpenAPI gateway and different microservice gateways of multiple system groups of internal applications can be monitored in the same monitoring center.

2. Scalability and maintainability

There are always areas where a product cannot meet production needs, so we need to think about how to carry out secondary development and maintenance of the product and whether it is convenient for the company team to take over and maintain the product.

3. Demand matching

It is necessary to evaluate whether each API gateway can meet the requirements. For example, if the OpenAPI platform needs to use an API gateway, then it is necessary to consider whether the product can meet the requirements of the OpenAPI core requirements such as partner application access, partner portal integration, and access limit.

If it is a microservice gateway, then you need to consider whether the product is powerful enough from the aspects of microservice operation, maintenance, monitoring, and management.

4. Is it open source? Does the company have the ability to develop its own software?

Existing open source products such as kong, zuul, and orange all have basic API gateway core functions, but most of these open source products are still a long way from being very useful.

For example: there is no UI interface that provides management functions, the monitoring function is weak, it does not support the OpenAPI platform, and there is no company operation and maintenance function.

Of course, open source products can obtain source code. If the company has strong R&D capabilities and can hold these open source products, kong and zuul should still be suitable for some companies after secondary development. However, the following points need to be noted:

• Kong is based on ngnix+lua. From the company's perspective, it is difficult to find people who can maintain this kind of architecture product. Need to assess whether the current company has the ability to maintain this product.
• Zuul's performance is not high under high concurrency conditions due to its architecture. At the same time, it is necessary to integrate open source monitoring and management systems that are compatible with Zuul based on research.
• Orange is not widely used, and it is open sourced by individuals in China. It lacks sustainability and community resources, so it may not be easy to find someone to ask questions when problems arise.

In addition, Kong provides an enterprise version of the API gateway, which is of course based on ngnix+lua. The enterprise version can purchase their technical support, training and other services, as well as interface management, monitoring and other functions.

5. Public cloud or private cloud?

Amazon, Alibaba, and Tencent Cloud are now providing basic public cloud API gateways. Of course, the basic functions of these gateways are certainly no problem, but secondary development, extended functions, and monitoring functions may not be able to meet the customized needs of some users.

In addition, many companies cannot use API gateway services on the public network due to their own information security reasons, so they have no choice but to choose a private cloud solution.

In terms of demand, if the API gateway based on the public cloud can only enable internal personnel to apply for applications for external network personnel, it cannot provide a customized partner portal, which is not suitable for the needs of some enterprises.

If used as a microservice gateway, in most cases it is hoped that the gateway server and the service provider server are in the intranet. In this case, only the API gateway of the private cloud can meet the requirements.

Based on the above analysis, the API gateway of the basic public cloud can only meet the needs of some simple customers. For many enterprises, the API gateway of the private cloud is the right choice.