Microservice architecture involved breaking down a complex application into small self-contained applications so that each one of them can be scaled and maintained independently. With the plethora of benefits that comes with the microservice architecture, it is no wonder why everyone in the IT sector is moving towards this new architecture!
At the core of microservice architecture is the concept of reverse proxying. A reverse proxy plays a pivotal role in directing traffic among different microservices, as well as distributing the workload across multiple instances of a microservice. Without the reverse proxy, the intricate web of interactions and load distribution within the microservice architecture as we understand it today would simply not be feasible!
Let us dive deep into the role of a reverse proxy in a microservices settings!
What is a proxy?
A proxy is a server that sits between a client’s computer and internet. Any traffic that comes out of client’s machine passes through the proxy server. For the rest of the internet, it appears as though the proxy server is initiating the requests.
There are several reasons why one would use a proxy server. Some of them are as follows -
- Identity Masking: Using proxy, the real identity of a client is not revealed to the internet. It can be used to access content that would have otherwise be blocked/restricted for the client.
- Setting up restrictions: Using certain configurations, proxy servers can be used to restrict access to certain content for the client.
- It also enhances security
What is a reverse proxy?
A reverse proxy is a server that sits between the internet and backend servers. Any traffic that is destined for the servers must pass through the reverse proxy. For the rest of the internet, it appears as though the reverse proxy is serving the requests.
There are several benefits to using reverse proxies in general. You may find some listed here.
The concept of a reverse proxy breathes life into the microservice architecture, enabling the client to navigate the dynamic environment of microservices by determining which servers to access. Without this vital component, the client would be left without the means to effectively navigate the intricate landscape of the microservices architecture.
Service Discovery 🌍
Services in a microservice architecture scales up and down based on the load. This means that replicas of a service may come and go anytime during the lifetime of an application. Reverse proxy detects the servers of a service and effectively directs client’s traffic to these.
Load Balancing ⚖️
Since a service may have several replicas running, it becomes important that the client’s requests are properly distributed across available servers. Load balancing is just another feature of revere proxy that comes to use here. Reverse proxy smartly distributes the load across available replicas of a service.
Monitoring 🖥️
Since any request entering our application goes through the reverse proxy, it is a good place to monitor requests and perform logging. It helps in gaining crucial insights about the number of services present in the system.
Internal Traffic 🚦
In a microservices setting, a reverse proxy is also used to route the internal traffic of the cluster. This is specially useful for the case of service-to-service communication.
Caching 💰
Caching is a general advantage that comes with the use of reverse-proxy. The proxy server can return cached results for similar queries, thus improving the time to response for the client.
Aggregation ⛙
A single client’s request may require response aggregation from more than one service at the backend. Such aggregation can be performed by the reverse proxy leaving the client with a clean endpoint to use!
Proxying across layers
A reverse proxy can be used in different configuration. These configurations usually dictates the OSI layer at which the routing decision is taken. Popularly there are two famous proxying - (1) Proxying at Layer 4, and (2) Proxying at Layer 7. As we move up the layers, we decode more information from the internet packets that can be used for routing decision.
Layer 4 Proxy
Layer 4 in the OSI model is the transport layer. From an application developer’s perspective, the things available at layer 4 for routing decision are -
- IP and port of the client sending the request
- IP and port of the server that is receiving the request
Thus a layer 4 proxy can only make routing decisions based on IP and port of server and client. It cannot look into the contents of the requests and thus can make limited routing decisions.
There are several reasons as to why one would use layer 4 proxy -
- When only packet-level load balancing is required.
- One does not want the reverse proxy to decrypt the request for safety concerns.
- Efficiency is required since proxying at layer 4 is fast.
There are several downsides to the layer 4 proxy as well -
- Since we are at level 4, smart load balancing is not possible
- It cannot perform true microservices load balancing.
Layer 7 Proxy
Layer 7 in the OSI model is the application layer. From an application developer’s perspective, the things available at layer 7 for routing decision are -
- Everything that was available at layer 4
- The entire content of the request including headers
Since a lot more content for decision making is available at layer 7, smarter routing can be performed.
Here are some reasons why one would use a layer 7 proxy -
- You need to make smart routing decisions in your reverse-proxy
- You want to use caching
Here are some downsides to using a layer 7 proxy -
- Layer 7 proxying is generally slower than layer 4 since it decrypts the request and examines its content for routing decisions
- Since the reverse proxy examines the contents of the requests, there is also a safety concern in using layer 7 proxy
Reverse proxy is undoubtedly one of the important piece in a microservice architecture. Without it, the true benefits of microservice architecture can never be realised in their entirety.
With this we reach the end of this blog! I hope you learned something new today.