Azure: ARRAffinity makes affinity cookies!

clip_image001[4]

Sources:

Affinity Cookies sound delicious, maybe turkey bacon with chocolate or something.  But no, Affinity Cookies are used to aid people who need to stay with a certain instance of web app or web site in Azure.  The reason for this is that we strive for statelessness, but do not always achieve it.  This means that the user must stay on the particular instance that they using till they break state and then things are saved at that time.  Example might be your design for the next big deal, but because there was a hiccup on your phone as the train speeded through a tunnel.  What are you going to do?

So in this case what is used? Application Request Routing IIS Extension, which I just basically wrote down, but is something I definitely need to explore more over the next few days.

Let’s take a case: You have a Raspberry Pi that you want to use to connect a number of Arduino Sensors inexpensively to the cloud, so you don’t want the Arduino’s, which are excellent at the point of a sensor, but not as good for connecting to expensive services like AWS or Google.  To keep costs down on any system, the Raspberry Pi or similar make good relays.  The Arduino’s feed into the Raspberry Pi, then the Raspberry Pi feeds the sensor data non-realtime at the optimized least cost times.

So what is the process for the Raspberry Pi to connect with Azure Web Apps or Web Sites? If you thought this was a good idea, how would it work?  Scroll down to see more…

Drawing2

Drawing3

This could totally be a state machine, but if we did this procedurally, then it might be written as:

  1. Raspberry Pi connects to a Web App (Web Site)
  2. ARR runs on the front-end Azure server shown as a router labeled “Application Request Routing” this routing server then receives the request using a protocol decided by the Raspberry Pi side of things.  That is you need a way to name the Raspberry Pi’s.
  3. ARR Affinity Server,  decides to which of the available instances the request should go, in this case it could be instance 1, 2, 3 or N.
  4. ARR serves the request to the Web App Server instances, after creating a unique GUID or similar and attaches an ARRAffinity cookie to the request.
  5. The response comes back to the Raspberry Pi, holding the ARRAffinity cookie.
  6. The Raspberry Pi receives the request which stored as a cookie for later use
  7. The Raspberry Pi then submits a subsequent request along with the unique cookie
  8. When ARR Affinity Server receives the request from the Raspberry Pi, the Server decodes the cookie
  9. The decoded cookie holds the name of the instance that was used earlier, and so ARR Affinity Server serves the request to the same instance
  10. If it is a new instances from one of the other Raspberry Pi’s then step 1 through 5 are completed.
  11. The same thing (steps 7-9) repeat for subsequent request for the same site, until the user closes the browser, at which point the cookie is cleared.  If new instances is required then step 10 is run

To control the Affinity Cookie, you would use: headers.Add(“Arr-Disable-Session-Affinity”, “True”); to strip out the cookie.

It is likely you will want to experiment with this, you will need to think about the test.  It is always clearer if you have a bunch of different devices use this for your testing.

So enjoy your clip_image001[4]