While we want to ship new features, enhancements, and fixes to users with continuous integration and continuous delivery, as the number of users of your application increases, progressive rollouts help minimise risks and ensure a smooth user experience when releasing updates.
There are many ways to implement a progressive rollout, using Azure Front Door is one of the simplest and most suitable options for managing risks in small to medium applications. It provides an easy-to-configure strategy that balances stability with controlled feature releases.
Using Azure Front Door for Progressive Rollouts
Azure Front Door acts as a global load balancer and CDN, directing traffic across multiple backend pools based on routing rules. For progressive rollouts, In Front Door we can utilise few mechanisms based on our risk appetite.
Weighted Traffic Distribution
Azure Front Door allows traffic splitting between different backend versions using weighted routing. Example: 90% of traffic remains on stable version while 10% is routed to next-release version.
Geographic Rollouts
Deploy new features gradually to specific regions. Example: Start in Europe, then expand to North America.
Custom Rules with Azure Front Door Rules Engine
Create rules based on HTTP headers, cookies, or query parameters to control rollout logic. Example: Users with a "beta-user" cookie get routed to the new version.
Power Users vs. New Users Rollouts
Segment users based on experience level to control feature exposure. Example: Experienced power users in specific regions receive the new version first, while new users continue using the stable version to ensure a smooth onboarding experience.
1. Origin Group
Azure Front Door requires defining an origin group, which contains multiple origins (backend endpoints). In this setup:
The Stable Origin represents the existing production version, initially receiving most traffic.
The Next-Release Origin represents the new version, receiving a small portion of traffic that can be gradually increased.
Each origin within the group is assigned a
Each origin within the group is assigned a weight, dictating the proportion of incoming requests it should handle.
2. Configuring Weighted Traffic Distribution
Azure Front Door routes incoming requests to backends based on the configured weight values in the origin group settings. The load balancer evaluates these weights for each request and distributes traffic accordingly.
Weight-Based Load Balancing
If 90% weight is assigned to the stable backend and 10% to the new release, then out of 100 requests, roughly 90 will go to the stable backend and 10 to the new version.
These percentages can be modified as the rollout progresses.
*Each origin within the group is assigned a *
Azure Front Door Weight-Based Load Balancing
Priority Handling
Both origins in the group should have the same priority level to ensure they are load-balanced based on weight rather than failover behavior. If different priority levels are assigned, Azure Front Door will send all traffic to the higher-priority backend unless it becomes unhealthy.
3. Ensuring Session Consistency with Session Affinity
With this approach, enabling Session affinity on Front Door is critical in a progressive rollout to provide users a consistent experience. If session affinity is not enabled, users might experience. Switching between versions mid-session, leading to inconsistent behavior. Authentication issues if session tokens are not shared across instances.Summary: Azure Front Door Session Affinity
Azure Front Door uses cookie-based session affinity, leveraging managed cookies (ASLBSA and ASLBSACORS) that encode the origin URL. This mechanism differentiates users, even if they share the same IP address. Read more about Azure Front Door Session Affinity
Ensuring Session Consistency with Session Affinity
*Progressive Rollouts with Azure Front Door – Q&A *
Q: Will two users on the same public IP get different versions of the application?
A: Yes, because Azure Front Door does not use IP-based session persistence. Instead, it relies on cookies to maintain session affinity. Each user's browser session is assigned a unique session affinity cookie (FrontDoorAffinity), which determines which backend origin they will continue interacting with.
If session affinity is disabled or not functioning (e.g., due to caching issues), each new request is treated independently, and Azure Front Door routes traffic based on the weighted traffic distribution, which means different users even on the same IP may receive different versions of the application.
Azure Front Door does not use IP-based session persistence
Q: Why am I getting a different version of the application every time I refresh the page?
A: One of the following issues might be occurring:
Session Affinity is Disabled - Without the FrontDoorAffinity cookie, every request is independently routed, causing the backend selection to vary based on traffic weight distribution. Also check if the cookies are disabled in the browser. Read more about Azure Front Door Session Affinity
Cached Responses Prevent Cookie Assignment – If the response from the backend is cacheable (e.g., Cache-Control: public), Azure Front Door cannot attach the session affinity cookie, resulting in random backend selection.
Solution
Ensure that session affinity is enabled at the origin group level.
Check that the browser allows cookies and does not clear them between requests. Use "Cache-Control: no-store" in backend responses to prevent caching conflicts with session affinity.
Top comments (0)