“
- My experiences with API Gateways…
- Mahesh Mahadevan
- The Nuggets translation Project
- Permanent link to this article: github.com/xitu/gold-m…
- Translator: Prince Stuart
- Proofreader: Liu Haidong, Shixi-Li
Remember once – experience building API gateway services……
Not long ago, I was working on a project to implement API gateways for our cloud products. The primary motivation behind it is to provide a single entry point for all external communication and securing back-end services, but there are other reasons as well. I’m assuming that you stumbled across this article on API gateways and that you already have advanced knowledge of them. If not, you should read here and here before diving into this article.
Finding an API gateway that meets your requirements is the transition choice. If you make a big deal out of it, you may end up breaking down. Just like other major software stacks in the industry today, even API gateways come in a variety of options and styles. To be honest, it’s hard to make a decision without delving into every option and matching it to your specific needs. This article is my little attempt to simplify the task, and I provide a flow chart at the end that I hope will help you decide.
When we started searching, we started analyzing these options based on our research. To do this, we rely primarily on the various comparisons that already exist on the web, and we do some filtering based on their current popularity and the set of features they have to offer.
Disclaimer – This article does not provide performance comparisons for any API gateways, although this is also the criteria we chose. I’m not saying that the implementations discussed here are the only options available, but, as I wrote this article, they were the most popular choice based on our product requirements.
List of requirements……
First, let’s quickly list the lowest expectations for an API gateway solution. Please note that this is not an exhaustive list and is not necessarily a match for the solution you are looking for. However, it should cover most application scenarios of the API gateway.
- Reverse proxy – This is the most important reason for most projects to adopt gateway solutions. Any mature project that has exposed its apis to the outside world should avoid exposing the backend urls for security reasons, abstracting complex services from the backend to the client. This also provides a single point of access for all clients to the back-end API.
- Load balancing – The gateway can route an incoming single URL to multiple back-end targets. In microservice architectures, this is often useful when you want to scale your application for high availability, or when running a configuration for a service cluster, or even other things.
- Authentication and Authorization – Gateways should be able to successfully implement authentication and allow trusted clients to access the API and provide authorization services in a manner similar to role-based access control.
- IP list – Allow or deny certain IP addresses. Provides an extra layer of security for your ecosystem, which is useful when you find a set of malicious addresses that want to cripple your application via DDOS.
- Analysis – Provides a way to record logging usage and other useful metrics related to API calls. It should be possible to break down each client’s API usage to capture the potential benefits.
- Speed limit – Limit the ability of API calls, for example, you only want to allow 10000 calls per minute for all users, or 1000 calls per month for specific users.
- Transform – The ability to transform the request and response, including the header and body, before forwarding.
- Versioning – You can choose to use different versions of the API at the same time, or roll out the API slowly as a Canary release or a blue-green deployment.
- Circuit breakers – useful for microservice architecture patterns to avoid service outages.
- WebSocket support – Many dynamic and real-time functions can be solved using WebSocket. In business scenarios with frequent data exchanges, WebSocket interfaces are provided to clients to reduce the overhead of multiple HTTP calls.
- GRPC support – Google’s gRPC promises further load reduction through the use of HTTP/2, which can be effectively used for internal communication between servers. I recommend that you definitely add this to your list of requirements to make your solution more reliable.
- Caching – If frequently requested data can be cached, this will further reduce network bandwidth and round-trip time consumption and improve performance.
- Documentation – If you plan to expose your API to developers outside your organization, you must consider using API documentation. Such as Swagger or OpenAPI.
API gateways and service grids
Before comparing their actual implementations, I must also talk about another pattern you might encounter when looking for gateways and service grids. First, it can be confusing to understand the difference between AN API gateway and a service grid and what each is used for. So I’m going to describe them in detail before I go on.
API gateways are applied at layer 7 of the OSI model, or you could say manage network traffic from outside (sometimes referred to as north-south traffic). The service grid applies to layer 4 of the OSI model, or manages communication between services (sometimes referred to as east-west traffic). Some examples of API gateways include reverse proxy, load balancing, authentication and authorization, IP listing, and rate limiting.
The service grid, on the other hand, works like a proxy or sidecar pattern, relieving responsibility for communication between services and dealing with issues such as circuit breakers, timeouts, retries, and service discovery. At the time of publication, Istio was a well-known implementation of the service grid.
As you have no doubt noticed, my requirements list also includes some of the capabilities provided by the service Grid. Currently, quite a few API gateways are capable of working simultaneously at Layers 4 and 7 of the OSI model and addressing the needs of the service grid. It would be nice if we could get an implementation that addressed some of the grid service requirements, even if it wasn’t required. Here’s a great article detailing the differences.
To compare
The essence content
I’ll compare the following API gateways…… (Disclaimer)
- NGINX
- Kong
- Tyk
- Ambassador
- AWS API gateway
Nginx
Nginx is already one of the best choices for creating a single point of entry for tier 7 load balancing agents and back-end applications. It has been used and proven in many different production environments, and it replaces much of the existing load balancing hardware with very low memory usage, thus saving the company a lot of money. Many CDNS use Nginx as an engine to cache data from edge nodes.
The biggest advantage of using Nginx as a gateway is that it has functionality from simple to complex, allowing you to choose which features meet your requirements. For example, if you only need load balancing and reverse proxy functionality to start with, Nginx can easily do this with minimal effort, and you can eventually upgrade to other functionality as your product matures. You can also use their commercial product, NGINX Plus, to implement full API gateway services, even though its open source products can do this through a wide range of existing plug-ins.
Nginx is known for its small memory footprint and high performance with low latency. You can also get some third-party custom Nginx plug-ins that cover a wide range of custom scenarios. Of course, you can always turn to its vast developer community for help when you run into problems somewhere. The only problem you’re likely to run into is that Nginx configuration can be a bit difficult to master unless you’ve already done it yourself. Otherwise, you’ll have to wade through parts of its documentation until you’re comfortable with it.
Kong
Kong is an API gateway + service grid based on Nginx and OpenResty that meets most of the requirements we listed above. Following the Docker installation instructions provided is fairly easy.
Kong’s architecture is very straightforward and consists of many components……
- The Kong base module, which encapsulates OpenResty and Nginx, is the actual engine.
- Database layer, which can be Cassandra or Postgres to store all configuration data for easy recovery in the event of a failure.
- The dashboard provides a user interface for API management and view analysis (although Kong provides REST apis, upstream apis, and management services for its consumers, it only provides enterprise-level services)
Kong has both open source and enterprise implementations, both of which work stably with millisecond latency with Nginx support. Imagine using Nginx for gateway operations while the REST API and database layer easily manage configuration.
Kong provides a variety of plug-ins that address most crosscutting concerns from access control, security, and caching documents. It also allows you to write and use custom plug-ins in Lua. Kong’s open sourcing is a good start to understanding their stack. Although there are no Web interface dashboards, there are some open source dashboards available to help you manage their configuration. Otherwise, if you are familiar with REST, you can use their administration API directly.
Kong can also be deployed on Kubernetes Ingress and supports gRPC and Websocket proxies. Kong’s strength is its underlying engine, which is made up of lightweight but powerful Nginx and OpenResty engines and can itself be built into a full-fledged API gateway. You can think of Kong as an auto-switch version of Nginx. One possible drawback to this implementation is that not all features are available out of the box, and some must be manually configured by activating their respective plug-ins, which may require initial setup time and resources, but for many teams of mature engineers, this may not be a big hurdle.
Tyk
Tyk is another open source gateway that promises great performance, written by Go. Tyk provides a variety of features that are part of our list of requirements. Tyk’s Web dashboard is the best in its class, allowing you to control almost every aspect of YOUR API configuration and providing excellent API usage analysis.
With its rich feature set and beautiful Web user interface, Tyk is a good choice for projects with complex API management solutions. The nice thing about Tyk is that it includes API dashboards, analytics, security, version control, developer portals, speed limits, and other out-of-the-box gateway features that you can use for free in non-commercial scenarios. However, if used for commercial purposes, you will need to purchase their commercial license, which also includes their support.
Tyk is really good for projects that are looking out of the box and ready to pay for it from day one (e.g., you plan to use it for commercial purposes), rather than exploring options like Nginx and Kong, which can take some time for your developers to get all the necessary features. The disadvantages of Tyk compared to the first two implementations are ease of installation and cost. Tyk has too many components that are not easy to install and manage locally. It offers cloud and hybrid installation options, which can reduce installation and administration costs. But it also has its own pricing, which increases the cost of your project.
Ambassador
Ambassador is an open source Kubernetes local microservices gateway built on Envoy. It can be used as a Kubernetes interface and load balancer, and can easily and quickly publish and test microservices in Kubernetes environment.
Ambassador is very lightweight and all state is stored in Kubernetes, so no database is required. Ambassador is built developer-centric, so all of its operations and concepts are developer-centric, such as adding a route to Ambassador. The most recommended method is to add comments to the YamL configuration file of the Kubernetes service. Its free version includes version control, gRPC, WebSocket support, authentication, speed limiting and integration with Istio to work like a service grid, while OAuth, single sign-on, JWT authentication, access control policies and filtering are part of its paid version, Ambassador Pro.
It has the advantage of servicing heavy traffic on a Kubernetes environment with low footprint and minimal initial configuration services. What it lacks, however, is a lack of functionality compared to the gateways discussed earlier. Because it lacks an out-of-the-box dashboard and analytics integration, it requires some setup.
Amazon API gateway
Amazon API Gateway is a managed API cloud service provided by AWS that makes it easy to create, publish, and manage apis with just a few clicks. You can expose REST or WebSocket nodes, import new apis using Swagger or Open apis, and route your urls to various back ends, including AWS EC2, AWS Lambda, and even internal nodes. The cost of routing millions of apis through gateways is small and predictable. There is a fixed pricing model for a given number of requests (therefore, you should be careful about the cost of external data transfer).
The AWS API gateway does not need to be set up because it is managed, you can quickly create or route apis with a few clicks, secure them with SSL, provide authentication and authorization, create API keys for external clients of the API, manage your VERSION of the API, if you like, It can also generate a client SDK. AWS API Gateway services are really powerful and can be easily set up in just a few minutes. Therefore, if you already use AWS or plan to use AWS, you need to seriously consider this gateway as your first choice, unless you have some mandatory functionality that it doesn’t meet. The obvious downside is that you may be tied to AWS services, and these dependencies may at some point in the future make it much harder to migrate to other frameworks.
Comparison matrices
The following table summarizes a comparison of the five API gateway features.
- Green: Some of the features are open source
- Yellow flags: Features are supported in paid versions only
- Red Cross: The feature does not yet exist (visit the respective portal for the supported feature set)
- Basic features include reverse proxy and load balancing
- Tyk provides a developer license for non-commercial use, which includes all features. For production use, you need to purchase their commercial license, which can be installed as a Saas or hybrid.
- The open source version of Kong doesn’t have dashboards, but there are some third-party open source dashboards available that provide Web interfaces to manage your apis and plug-ins.
- Ambassador can be installed with Istio to act as a service grid.
Decision time
Finally, this is a flow chart, which I’ve deliberately simplified. You should use the following chart and the above feature matrix to simplify your selection.
Implementation worth mentioning
- Apigee
- WSO2
- Zuul
“
If you find any mistakes in your translation or other areas that need to be improved, you are welcome to the Nuggets Translation Program to revise and PR your translation, and you can also get the corresponding reward points. The permanent link to this article at the beginning of this article is the MarkDown link to this article on GitHub.
“
The Nuggets Translation Project is a community that translates quality Internet technical articles from English sharing articles on nuggets. The content covers Android, iOS, front-end, back-end, blockchain, products, design, artificial intelligence and other fields. If you want to see more high-quality translation, please continue to pay attention to the Translation plan of Digging Gold, the official Weibo, Zhihu column.
This article is formatted using MDNICE