Why should I use the Service Fabric Reverse Proxy instead of the Azure App Gateway to talk to SF Cluster?

Question

It's a long question and there are trade-offs, I'm sure. The documentation in this area:

Doesn't give me enough to answer the question above confidently.

So, they say: "Azure Application Gateway (AG) attempts to resolve a service address again and retry the request when a service cannot be reached".

I know how the Service Fabric Reverse Proxy (RP) does this by encapsulating the resolve loop. Does the AG have this capability too? The AG is a reverse proxy too, by all accounts.

So, crucially for external traffic into a SF cluster, why would I use one over another (I am aware that the RP allows intra-cluster comms too and this is a good fit).

Answer 1

Well, for external traffic into the cluster you will get an Azure Load Balancer / Reverse Proxy combination out-of-the-box. But whether it is sufficient is another question. We had the same decision to make, we ended up using the Application Gateway.

The differences between the Azure Load Balancer and Application Gateway are outlined in this document.

Some takeaways:

• Azure Load Balancer works at the transport layer (Layer 4 in the OSI network reference stack). It provides network-level distribution of traffic across instances of an application running in the same Azure data center.
• Application Gateway works at the application layer (Layer 7 in the OSI network reference stack). It acts as a reverse-proxy service, terminating the client connection and forwarding requests to back-end endpoints.

So, Application Gateway additionally supports SSL termination, SSL end to end and URL-based routing which makes it a good candidate for Service Fabric applications that have external clients.

Answer 2

Given a path well trodden, additional trade offs only became apparent and real to me when I actually witnessed it implemented.

If you don't use a reverse proxy, adding other services in your cluster and being able to differentiate requests to them becomes a mammothly expensive exercise.

Consider the cost of adding new PIPs (permanent IPs in Azure), load balancer s NATting rules, firewall rules (if using NVAs) and NATting rules contained therein to provide a route into your API. If all of this is set up to allow access to your RP then adding services/APIs behind your RP should be a relatively straightforward task

Put another way, without an RP, I am saying you effectively end up having a one to one relationship between an external IP address and a service on a node manifested by hard coding a route from point to point.

With a reverse proxy like traefik, you can use service discovery to deploy and make active services with much much less configuration. Significantly saving time, effort and money. When implementing the RP I will update answer again.