Does Client Affinity / Sticky Session via IIS ARR work with ASP.NET Core 3+ / .NET 5?

Question

There's an ASP.NET MVC 5 application (it uses Entity Framework 6.0, .NET 4.6.1 dependencies, it utilizes both MVC controllers and API controllers and most importantly) which relies on IIS's ability to provide session stickyness through ARR. Sometimes this is also referred as client affinity and IIS ARR implements it with a cookie if I'm not mistaken. ARR feature is essential for that app, it'd be unusable without it.

I haven't found any concrete evidence if such a project got upgraded to ASP.NET Core 3.1+ (or even .NET 5) then would the ARR still work as before? .NET Core architecturally is very different than .NET MVC 5 and want to prepare in advance for any surprises. Is there any cloud platform besides Azure which could provide equivalent feature what Azure WebApps can provide with IIS + ARR?

BTW I highly disadvise anyone from developing any solution which would rely on sticky session or client affinity. Ideally a webapp request/response code should be stateless in the sense that the requests should be able to be routed randomly to any server in case of a horizontal scale-out.

Sticky session routing can be also costly (I mean money) depending on the provider (fortunately IIS ARR is free) and it can also hurt even load distribution.

Vova Bilyachat Vova Bilyachat · Accepted Answer · 2021-08-18T02:07:10

Client Affinity in IIS is for load balancing / traffic routing so this is how your farm will redirect routes to nodes. Which means it does not matter what you have on backend since as soon as you enable then requests with those cookies will always hit same node.

For instance Kubernetes has similar concept

If you want to make sure that connections from a particular client are passed to the same Pod each time, you can select the session affinity based on the client's IP addresses by setting service.spec.sessionAffinity to "ClientIP" (the default is "None"). You can also set the maximum session sticky time by setting service.spec.sessionAffinityConfig.clientIP.timeoutSeconds appropriately. (the default value is 10800, which works out to be 3 hours).

You can also do the same with AWS

{     
    "Attributes": [
       ...
        {
             "Key": "stickiness.enabled",
             "Value": "true"
          },           
          {
              "Key": "stickiness.lb_cookie.duration_seconds",
              "Value": "86500"
          
          },
       ...
      ]
  }

So once Again session Affinity is for routing request to your nodes and has nothing to do with backend technology, but honestly I would avoid it since you could have some scalability problem or at least configure those sessions to be short.

Does Client Affinity / Sticky Session via IIS ARR work with ASP.NET Core 3+ / .NET 5?

1 Answers