Fantastic API Gateways and where to find them – Watch the video!

Welcome

Hello everyone, and welcome to this video. Today, we’re going to explore the world of these fantastic tools, API gateways. We’re going to talk about what they are, their usage, and finally, we will get to compare some of the most popular tools available in the open source community. But let me introduce myself first.

My name is Giorgia Fiscaletti, and I am a Computer Science Engineer and a cat lover ‑ as you may guess from this GIF ‑ and currently I am working as a Cloud Engineer Specialist at Mia‑Platform. Mia‑Platform is one of the very first solutions on the market to create and develop Kubernetes applications. It is a product that was created by developers for developers, to help companies deal with their digital transformation. As a Cloud Engineer Specialist, I work in the Operations team, and we deal with R&D for both the infrastructure and the product, with maintenance, monitoring, and so on. 

If you have any doubts or questions, feel free to write them in the comment section, and we will try to reply as soon as possible. Also, remember to follow us on social media and subscribe to the channel, to know about our latest news. 

Agenda

So let’s get back to the main content of this presentation. We will start with a brief introduction on API gateways: we will see what they are, what they can be used for, and why they are so important for our applications. Then when we get to explore some of the most interesting features that we can find in these tools. And finally, we’ll get to the core of this video, where we will get to analyze some of the most popular tools available in the Cloud Native Computing Foundation landscape. 

Introduction to API gateways

But let’s start from the very beginning: what is an API gateway? The answer is actually quite straightforward: an API gateway ‑ as the name suggests ‑ is a gateway that is located between our application and the outside world. 

So what happens, when a client tries to make a request to our application, the API gateway takes this request in charge and performs some security checks. For example, authentication checks and authorization checks together with any other operations, depending on the features that are enabled on our tool. 

And finally, when it made sure that the request was authenticated and authorized, and that the client had all the permissions to access the resource, the API gateway forwards the traffic: i.e. forwards the requests to the correct underlying service in a unique way.

Scope of this video

So, why are we talking about API gateway today? To answer this question, we need to go back in time up to a few months ago. When I worked, I was asked to look for new API gateways for our product. We were searching for something that was even more performant with respect to the API gateway that we already had. It was the very first time that I dealt with such research, about these kinds of tools. So, now that a few months have passed, I started thinking about some hints, some suggestions that would have been useful for the Giorgia from a few months ago, to make a more formal research on this topic. 

So let’s get back in time again. I was asked to look among the tools that were available on the Cloud Native Computing Foundation landscape, to compare them, compare their features, and finally pick the best fit for our product. At that time, it was maybe the very first time that I had visited the Cloud Native Computing Foundation landscape webpage. So I navigated to the page, and this is what I found myself in front of, and it was a little bit overwhelming at first.

And clearly, this was my very first reaction. As soon as I put my glasses on, I realized that I did not have to look among all of these tools, but we were interested only in these two categories: Service Proxies and API gateways. But if you take a closer look, you may notice that there are still 38 tools ‑ I counted them ‑ and in a company you don’t always have the time to do an informed comparison on this kind of number of tools. You need to do some filtering, some preliminary selection. 

And in today’s video I hope to leave you with some hints, some suggestions, in case you find yourself in a similar situation, where you have to pick a new API gateway for your application, or you have to build a new application, so you have to select the very first API gateway for your product. 

Why are API gateways important?

But why are API gateways so important? Well, first of all, they are surely one of the core elements of our applications, since they are located in between our services and the outside world, and help managing the traffic that comes from external clients.

Then, they help ensuring performance, since a performant API gateway is able to reduce the latency of the requests, and, as a consequence, to reduce the latency that is perceived by the end users. Then, they help guaranteeing the reliability of our services with a feature set: for example, the rate limit service that we will see later on. 

And finally scalability: the API gateway helps ensuring the scalability of our application, since it is in charge of mapping the request to the correct underlying service in a transparent way, so that the external client is completely unaware of the number of services to which the API gateway is communicating with. 

Finally, last but not least, they help enforcing security, thanks to the checks that are performed as soon as the request is received by the API Gateway. It may be, for example, authorization checks, thanks to an external authorization service, or authentication checks. 

API gateways main features

But now let’s dive deeper and let’s get to explore some of the most interesting features that we may find in these tools. Just a little disclaimer, before we go on. Features are strictly dependent on our scenario, on our use case. We’re going to present you the features that were essential in our specific use case, but in your scenario, you may need maybe the same features, different features, more or less features. So keep that in mind.

URL mapping and rewriting

Let’s start from the most straightforward one, which is URL mapping. It is essential that an API gateway is able to map the URL of the request so that it receives the correct underlying service in a unique way. While doing that, the API gateway should be able also to rewrite the URL that it receives. This is because we do not always want to expose the routes of our underlying services. 

So, this kind of feature enables an additional layer of security that protects our services from potential attacks. So, what an API gateway does is that as soon as it receives a request from an external client, it maps the URL to the correct underlying service, and it rewrites that URL to another path that is accepted and compatible with the routes that are exposed by the underlying service. 

Rate limit

Then, a feature that we already mentioned: rate limiting. A rate limit service is a service that is in charge to limit the number of requests that can be executed in a unit of time on our application. For example, it may limit the number of times that a single user may reload a login page. This helps our application to ensure the availability of our services, and also to avoid potential bot attacks: for example, denial of service attacks. 

API key management

Then, let’s get more into the security field with API key management. An API gateway should be able to handle secret resolution by extracting the secrets from either a header or a cookie ‑ depending on how the application is developed ‑ and to resolve the secret in order to apply it to the secreted routes, and to verify the correct information.

Authorization service

Now let’s get to one of the most important features in API gateways, which is the ability to communicate with an external authorization service. This feature is essential in order to verify the permissions of the clients, and to make sure that the external agent is authorized to perform such requests and to access that specific resource.

HTTP cache

Now let’s get to a little bit more advanced feature, which is the HTTP cache. The HTTP cache helps with the performance of our application, since it allows us to save some information from the request, and to reuse it in case a similar request is repeated in a short amount of time. 

Service Proxies vs API gateways

Now that we analyzed some of the most essential features for API gateways, we can finally get to the core of this video, where we are going to compare the features and implementation of some of the most popular tools from the Cloud Native Computing Foundation landscape. 

Let’s start by listing the differences between the two main categories that we are going to explore, which are Service Proxies and API gateways. 

Service Proxies

Service Proxies are not API gateways by definition. They are more generic tools that can be implemented in many different ways. For example, to build a security proxy, canary, and many other tools. So, the API gateway is just one of the many implementations. This allows us to build an API gateway from scratch, leaving us with many options that may not be essential for an API gateway, but they may be some interesting evolutions for our tool. 

So, they are generally very extensible, but this kind of extensibility often implies a higher underlying complexity, which means a slower learning curve. So, when dealing with service proxies, you will surely need ‑ from my experience ‑ more time for studying the documentation, studying the tool, and finally, for the implementation. 

Some examples of service proxies that are available on the Cloud Native Computing Foundation are: Envoy, Traefik, Contour, and Nginx. 

API gateways

On the other side, we have API gateways. API gateways are tools that were built with the only purpose to work as API gateways, so they have a targeted implementation. 

They are, as a consequence, a little bit less complex and generally less extensible, but this is not necessarily a flaw. It just means that API gateways have a well‑defined set of boundaries in which we can move freely being sure that our final result will work perfectly and properly as an API gateway, and within which we will be sure to have all the essential features for our final tool. 

Some examples of API gateways that are available in the Cloud Native Computing Foundation are: Emissary Ingress, Gloo Edge, Kong, and Tyk. 

Comparison analysis

I personally selected four among these tools: two service proxies and two API gateways. But now we’re going to analyze further, starting from Envoy. 

Service Proxies ‑ Envoy

Envoy is a high‑performance C++ service proxy, and the tool that I like to define the final boss of service proxies, since many other tools from the Cloud Native Computing Foundation are built and based on Envoy. 

First of all, it is an out‑of‑process service, meaning that it is completely agnostic with respect to the environment it is built in, and as a consequence is completely independent from any other technologies that we may find in our application. 

It has support for both the gRPC and HTTP/2, leaving us with more options when implementing communication between the API gateway and the underlying services. 

Then it has a massive extensibility thanks to filters, which are the building blocks of Envoy configuration, and provide us all the features that we may need. And with this extensibility, we have many features that may not be essential for our API gateway, but that may be useful for interesting evolutions of our tool. 

Service Proxies ‑ Traefik

Now let’s get to the second tool we’re going to analyze today: another service proxy, which is Traefik, a tool that I would personally choose only for its logo. Traefik is an HTTP reverse proxy and load balancer, and the tool that is also famous for its stack. It has a smooth integration with other components of our applications that may be, for example: Docker, containerd, Kubernetes, and so on. 

Then it provides automatic service discovery, meaning that we can either choose to write all the routes manually to our underlying services, or we can let Traefik do it automatically for us. 

Then, it comes with automatic HTTPS, thanks to its integration with Let’s Encrypt. Obviously you can choose to implement HTTPS with any other third‑party service, but having Let’s Encrypt already included in the package is surely helpful. 

And finally, although computer scientists are very jealous of our terminals and IDE and beam, I assure you that having a clean web UI when dealing with an API gateways and route managers, it happens to be very useful. 

API gateways ‑ Emissary Ingress

Now let’s get to the second category of tools that we are analyzing today, which are API gateways, with the first one I selected: Emissary Ingress. 

Emissary ingress is a specialized control plane for Envoy proxy. This means that it is built on top of Envoy Proxy, and it provides many of the stable features that are available on the Envoy service proxy. Being on top of Envoy is also an advantage, because Emissary Ingress provides us with a layer of simplification to write Envoy configurations. It is also Kubernetes native, which comes with all the advantages of working with the Kubernetes environment (for example, the possibility to write Envoy configuration via custom resource definitions). 

Finally, it has a stateless architecture, meaning that you do not need to build it as a single centralized element that has to guarantee all the availability and the security of your system, but you can distribute it on multiple instances.

API gateways ‑ Gloo Edge

Let’s get now to the final tool of this first introduction, which is Gloo Edge, another API gateway, and another tool that I would personally pick only for its icon. Gloo Edge is a Kubernetes‑native next‑generation ‑ as they define themselves ‑ API gateway. 

It is, again, built on top of Envoy, which comes again with all the advantages of exposing the Envoy API, which are the possibility to use many of the stable features of Envoy. And it is Kubernetes native, so, again, we can write in the configurations thanks to Kubernetes custom resource definition (CRD). 

Then it provides support for hybrid applications, meaning that it can be integrated smoothly in applications using many different technologies from orchestration to virtualizations, containerizations, and so on. 

Then, finally, it comes with fully automatic discovery, similar to Traefik. So this means that we can either choose to write all the routes manually to our underlying services, or we can let Gloo do it for us. 

Features comparison

Now that we introduced these two service proxies and these two API gateways, we can finally get to compare how the features that we presented before are implemented in these four tools, starting from URL mapping and rewriting. 

URL mapping and rewriting

In Envoy, mapping and rewriting are configured inside the route configuration, which is a property of the HTTP connection manager. The route configuration provides a list of matches, where we can specify the URL of the request, the underlying service that corresponds to the request, and eventually a rewrite of the URL to make it compatible with the ones accepted by the underlying service.

In Traefik, mappings are configured inside the router, which is the element responsible for routing the requests to the underlying services. On the other hand, the rewrites are defined into a dedicated middleware. 

In Emissary, for both URL mapping and rewriting, we have a dedicated custom resource definition, which is called mapping, where we can specify a list of matches with the URL, the corresponding underlying service, and the eventual rewrite. And we can do something similar in Gloo, thanks to the virtual service custom resource definition, where, again, we can specify a list of matches with their URL, the corresponding service, and a possible rewrite. 

Rate limit

Now let’s see the step two: rate limit. 

Envoy has the most complete configuration of rate limiting, since it provides both global and local rate limit filters. The global rate limit filter communicates with an external source through gRPC, so it requires the configuration of an external client service, the configuration of the rate limit parameters, which are the number of requests, the time unit, and the key on which the rate limit must be performed. For example, the IP address of the external client can be found inside the configuration of the external rate limit service. On the other hand, the local rate limit filter is internal and provides a configuration to protect the external rate limits service from possible traffic bursts. 

In Traefik, we have another dedicated middleware for the rate limit, where we can specify all the parameters that we already mentioned, that are the number or requests, the time unit, the key on which the rate limit must be applied and burst for traffic peaks. 

In Emissary and Gloo, we have a similar configuration. In Emissary, we have a custom resource definition, which is called the rate limit service, which exposes the Envoy API for the global rate limit service, where we can specify an external rate limit service that communicates with our API gateway through gRPC. And we can do the same in Gloo through the virtual service custom resource definition, which in turn exposes the Envoy API as well for the global rate limit. 

API key management

Concerning API key management, the vast majority of the tools that I had the opportunity to analyze do not provide explicit support, but we can still implement it by combining different features into two main steps.

The first one can be implemented through header manipulation, since we just need to extract the secret from a header or a cookie, depending on how our application is implemented. 

The second one is the actual secret resolution, and it can be implemented with a little bit of logic where we just need to extract information from the secret and to apply the permissions on the secreted routes. 

Among these four tools, Gloo is the only one that provides an API for API key management, which is the secret custom resource definition. With this CRD, we are able to define secrets and apply them to the secreted routes, and Gloo will be automatically in charge of resolving them and handling the permissions. 

Authorization service

The authorization service, since, as we already mentioned, is a very essential feature, it is implemented in a similar way in all the tools that we analyze. The API gateway needs to communicate with an external authorization service, and to be able to exchange information with it. 

In Envoy this is implemented with the ExtAuthz filter, in Traefik with the ForwardAuth middleware, in Emissary with the AuthService plugin, and in Gloo with the custom auth server. As you can see, they all have similar configurations. 

HTTP cache

Finally, we have the HTTP cache. This feature is not implemented yet in many of the tools that had the opportunity to analyze. 

In Envoy we have a cache filter, but it’s still a work in progress, and if you go into the documentation, you can find a big warning that says: “Do not use in production environments” ‑ and, personally, I do trust them. 

In Traefik it is an enterprise feature, so we’re not going to further analyze it. 

Finally, in Emissary and in Gloo, since they are both control planes for Envoy, the HTTP cache is not supported yet, as it is not a stable feature in the Envoy proxy itself. 

And this concludes the comparison between these popular tools from the Cloud Native Computing Foundation landscape. 

Summary

Let’s now review what we talked about today in this video: we explored API gateways, which are some of the most essential tools for our applications as they are located in between our services and the outside world, and they help managing the traffic that comes from external clients in a secure way.

Then, we explored some of their features, and we’ve got to compare some of the most popular tools from the Cloud Native Computing Foundation landscape. On one side, we analyze service proxies, which are generic and very extensible, and allow us to build API gateways from scratch. And on the other side, we saw API gateways, which are tools with a targeted implementation that work properly and perfectly within a well‑defined type of boundaries.

Which is the best fit for your application?

So let’s get back to the main question: which is the best fit for your application? Well, the answer is up to you. It strictly depends on your scenario and on your application’s needs. 

If you have the time to explore the documentation, to study how to build an API gateway from scratch, and if you want to leave yourself with many options for possible evolutions of your tool, well, maybe a service proxy is what fits you best. 

On the other hand, if you do not have that much time and you want a tool that works properly with the only purpose of functioning as an API gateway, and that offers you all the essential features of an API gateway, well, maybe you should pick one from the API gateway category. It’s all up to you. 

Conclusions

So this concludes today’s video. If you have any questions or doubts, you’re free to add them in the comments section and we’ll get back to you as soon as possible. And, also, scan this QR code if you want to leave any feedback. 

And that’s all for today. Thanks for watching, and I’ll see you guys next time!