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?

Problems

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.

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 sf1.hbt.net:20006, 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 sf.hbd.net:20006. 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, 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 an instance of the application on every node with the provided port.

As belowReactJs has 3 instances and 6 ports (HTTP & HTTPS).

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 node.

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 and more than 100 applications running on which each application beings deployed to all nodes. 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.

The reverse proxy is a service that runs on every node and handles endpoint resolution, automatic retry, and other connection failures on behalf of client services. It fully understands about the ports, locations of the applications in cluster.

If any request sends to the node which the application is not there Reverse proxy will forward it back to the appropriate node where the application is running on.

Beside of that, The reverse proxy also help to balance the workload  if application has more than one instances.

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 and location of the applications.
4. Saving cluster resources as we just need to scale the application instances based on the workload.

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:

So, The ReactJs application URL via Reverse proxy shall be: https://sf.hbd.net:19081/ReacJs/Web which 19081 is the default reverse proxy port, the fixed port for each cluster and never changes unless we re-build the cluster with the new custom 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.