In our daily work we often use or at least encounter different technologies that affects how traffic reaches our systems and vice versa.

Some of these are closely related but they serve different purposes. Sometimes the technology used can be the same for e.g. a load balancer and a reverse proxy. Here I go through some of them on a high level and explain some common use cases.

Load Balancer:

When we talk about Load Balancers, we mean systems that distribute traffic to multiple servers using some sort of algorithm, e.g. round robin. This allows our servers to have a higher availability and resiliency than what they would otherwise have. It also increases their scalability.

Load Balancers usually work on transport layer (Layer 4) or application layer (Layer 7) and they can be either software based (HAproxy, Nginx) or hardware based (F5).

loadbalancer

Use Cases:

We have multiple servers and need to ensure that the traffic gets spread across them in a controlled manner to allow for better resource utilization, performance and to avoid SPOF (Single point of failure).

It also allows for handling high amounts of traffic and prevents overloading individual servers, thus ensuring fault tolerance.

Common Load Balancers

  • F5 BIG-IP
  • Citrix ADC
  • Nginx
  • HAProxy

Reverse Proxy:

Reverse Proxies operates on the application layer (Layer 7) and we use them as intermediaries between client requests and the backend servers. They work by forwarding client requests to the appropriate servers. Due to the fact that an intermediary is being used, we can avoid having our internal servers being exposed directly.

Similarly to a Load Balancer a Reverse Proxy can load balance the requests to multiple instances. It can still be used efficiently when it is forwarding requests to single replicas due to the fact that it is shielding the internal servers.

Reverse Proxy

Use Cases:

Using Reverse Proxies, we can reduce the attack surface to the internal servers by having the request go through the proxy. In other words, this means that we can avoid exposing the internal servers directly and rely on the proxy to handle the requests.

They can also be used for SSL offloading. In this case, a secure client request comes in and instead of having the backend application use compute in order to do the SSL/TLS decryption we can do this on the Reverse Proxy instead. This is how Re-Encrypt routes work in OpenShift for example.

Common Reverse Proxies

  • Nginx
  • HAProxy

Forward Proxy:

In contrast to the Reverse Proxy, a Forward Proxy is used as a intermediary between client requests and external servers. For example, if the client is on a enterprise network and accesses a public website, the request will go through the Forward Proxy before reaching the external server. This will mask the identity of the client and the proxy can also scan the content of the request that is being made.

Both the client request and the server response will be evaluated by the Forward Proxy which will increase the security. As with the Reverse Proxy, the Forward Proxy works on the application layer (Layer 7).

FW Proxy

Traffic goes from the client is forwarded to the proxy where it gets evaluated based on configured rules.

FW Proxy2

The response from the server also gets evaluated before being sent back to the client

Use Cases:

Using Forward Proxies we can increase the security and anonomity of clients. Since the request will be forwarded on behalf of the client, the client’s IP address will not be visible and they will be anonmymous. They will also not have the direct contact with the external server since the requests are going through the intermediary.

Organisations can use Forward Proxies as away of enforcing compliance to certain organisation rule and requirements. As the forward proxy can scan the content of the request it receives, it can also identify compliance violations as well as look for suspicious payloads before forwarding the actual request to the external server.

Common Forward Proxies

  • Zscaler
  • Nginx

API Gateway:

An API Gateway serves as a primary interface for handling and exposing APIs, providing functionalities such as authentication, authorization, rate limiting, logging, and version control. It operates at the application layer (Layer 7) of the OSI model.

API Gateway

Use Cases:

By making use of an API Gateway, we can managing and control access to APIs by enforcing authentication and authorization policies. This ensures that only authorized users or applications can interact with the APIs we havem which helps protect sensitive data and resources.

It can also help preventing abuse and ensuring fair usage of APIs by implementing rate limits. By controlling the frequency of API requests, the Gateway maintains optimal performance and fairness for all users, preventing overloads and ensuring a proper user experience.

Common API Gateways

  • MuleSoft
  • Kong
  • 3scale

Conclusions

Understanding the roles and functionalities of load balancers, reverse proxies, forward proxies, and API gateways is important to better comprehend client-server computing architecture.

Load balancers play a vital role in distributing traffic across multiple servers, ensuring high availability, resiliency, and scalability. Reverse proxies act as intermediaries between client requests and backend servers, enhancing security by reducing the attack surface and enabling SSL offloading. Forward proxies, on the other hand, serve as intermediaries for client requests to external servers, enhancing security and anonymity while enforcing compliance with organizational rules.

Lastly, API gateways serve as primary interfaces for managing and exposing APIs, providing essential functionalities such as authentication, authorization, rate limiting, and logging.


<
Previous Post
Getting into a cluster with a broken API server
>
Blog Archive
Archive of all previous blog posts