Azure Service Fabric Reserve Proxy Exploring

Working with Azure Service Fabric you may hear about the Reverse Proxy. However, what is the reverse proxy and why it is too important when working with Azure service fabric?


Before explaining about the reserved proxy, let’s review the following Service Fabric cluster and the problems. So it will provide a clear picture about the advantage of reserve proxy that we are exploring.

This is 3 nodes Service Fabric cluster ( which all servers are load balancing together to make the high availability cluster.

Now let’s deploy an application to this cluster. I’m using ReacJs as a sample for this topic which you can find the source code here. Service Fabric will randomly assign the port and host the application on one of three cluster servers. In this case is port 20006 and on SF1 as below illustration.

Perfect, now we can access the application via, yeah, the application is accesstable and we can share the URL to users to tell them that the application has been deployed to Service Fabric and up to running.


Problem 1

We want to have high availability application on Service Fabric. However, now we are accessing the application directly via server name. What happens if Service fabric moves our application to the other nodes for some reasons like: Server team performs their maintenance cycle for pathing and restarting the servers or the application got the problem with existing node?

We need to check what is a new server name and port of the application on the cluster via Explorer and update back to our users. Quite manual stuff and may causing the downtime issue to the applications as we don’t know where and when Service Fabric is moving the applications.

Problem 2

Accessing the application directly via server name is silly and causing lot of issues in future instead We should accessing via NBL.

Nice, such a good idea now let’s try to access the application via Wow, it is working at the first request.

But, We got the problem in the subsequence requests the site is randomly unresponded. What happen? is Service Fabric not support NLB or any issue with our application?

Exactly, The problem is at the first request NLB redirect the request to the SF1 which the application is sitting on, such a luckily request so that we got the response property and the application was displayed on the browser.

However, the subsequence requests the NLB is redirected to the other nodes and obviously, the application is not there so the server response with refused to connect error.

So, accessing the application via direct-port is also a bad idea because the SF may assign a new port to the application is future and randomly moving the application around the cluster nodes without notification.

Workaround solution

We can specify the port of the application in the ServiceManifest.xml file and set the InstanceCount of the application to -1 in the ApplicationManifest.xml file with instance-count is -1 Service Fabric will deploy each instance of the application on each node with the provided port aw below ReactJs have 2 instances (HTTP and HTTPS) on each node so totally I have ( 2 * 3 = 6 instances of ReactJs).

Perfect, with this solution the NLB working perfectly without any refused to connect at all because the requests from NLB shall be served on any nodes.

The problem of the workaround solution

  1. Hardcode the port is not recommended as if we have many applications running on the cluster we need to ensure that there is no port conflict between the applications. If we have many development teams deploying the applications to the cluster we need to sync up the reserved ports between the teams as well. So The maintenance cost is increased.
  2. If cluster have 5 or 7 nodes with more than 100 applications running on and each application has deployed on every node. We are wasting the cluster resource.
  • Reverse Proxy, The Saviour

Reverse proxy built into Azure Service Fabric helps microservices running in a Service Fabric cluster discover and communicate with other services that have HTTP/HTTPS endpoints.

With reverse proxy all above issues had been resolved:

  1. No worry about fixing the ports
  2. No worry about deploying the instance of the application on all nodes.
  3. No worry about the URL of the application.

How to access the application via Reverse proxy?

The reverse proxy uses a specific uniform resource identifier (URI) format to identify the service partition to which the incoming request should be forwarded:

http(s)://<Cluster FQDN | internal IP>:Port/<AppName><ServiceName>

So, The ReactJs application URL via Reverse proxy shall be: which 19081 is the reverse proxy port, this is the fixed port for each cluster and never changes unless we re-build the cluster with the new port.

Amazing, thanks to the Reverse proxy that help to resolve all the issues when running the application on the environments. Now we can access the applications regardless of the port behind.

Develope the applications that compatible with Reverse proxy a is litle bit challeges. Refer here for details.

Please share and like if you found the post is useful.

Originally published at Drunk Coding.

Lernt what, share that

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store