This is a continuation of previous articles on IaC shortcomings and resolutions. With the example of Azure Front Door, we were explaining the use of separate origin groups for logical organization of backend and front-end endpoints. This section talks about route configuration.

A route is the primary directive to Azure Front Door to handle traffic. The route settings define an association between a domain and an origin group.  Features such as Pattern-to-match and rulesets enable granular control over traffic to the backend resources.

A routing rule is composed of two major parts, the “left-hand-side” and the “right-hand-side”. Front Door matches the incoming request to the left-hand side of the route while the right-hand side defines how the request gets processed. On the left-hand side, we have the HTTP Protocols, the domain, and the path where these properties are expanded out so that every combination of a protocol, domain and path is a potential match set. On the right-hand side, we have the routing decisions. If caching is not enabled, the requests are routed directly to the backend.

Route matching is all about the “most-specific-request” that matches with the “left-hand-side”. The order of match is always protocol first, followed by the domain and then the path. The Match is always a yes or a no. Yes, there is a route with an exact match on the frontend host or no there is no such match. In the case of a “No”, a bad request error gets sent. After the host matching comes path matching. A similar logic to frontend hosts is used to match the request path. The only difference is that between a yes or a no, an approximate match based on wild card pattern is allowed. And as always, a failed match returns a bad request error.

One of the key differences between an application gateway and Front Door is this hybrid custom-domain and path-based routing combination matching as described above. Application gateway can be either custom-domain based or path-based routing in most deployments but FrontDoor by its nature to being global across different regional resource types, allows for both custom-domain and path-based matches. 

The anycast behavior from FrontDoor requires a comprehensive test matrix to avoid any unpredictability with low-latency choices made by default. For a choice of host and path, there can be four test cases at least even for a “/*” path. Predictability also involves trying those requests from various regions.

Thus, separate endpoints, routing and host header all play a role in determining the responses from the Azure Front Door. 

#codingexercise 

Given a linked list, reverse the nodes of a linked list k at a time and return its modified list. 

Node reverse(Node master, Node start, Node end) {

If (start == null) return null;

If (start.next == null) return start;

Node tail = start;

Node prev = end;

Node cur = start;

Node next = cur.next;

While (next && cur != end) {

Cur.next = prev;

Prev = cur;

Cur = next;

Next = cur.next;

}

if (cur != end) {

     cur.next = prev;

     prev = cur;

     cur = next;

}

if (master != null) {

     master.next = prev;

} else {

    master = prev;

}

Return tail;

}

public Node reverse(Node head, int k) {

Node start = head;

Node end = head;

Node master = null;

while (end != null) {

    int count = 0;

    while (count < k && end != null) {

       end = end.next;

       count++;     

    }

    if (count == k) {

        Node last = master;

        master = reverse(master, start, end); 

         if (start == head) {

         head = master;

         }

         if (last != null) {

              last.next = master;

         } 

         while(master.next != end)  {

              master = master.next;

         }

         start = master.next;

         end = start;

    }

}

return head;

}