Application Transition

If you just want 10% of traffic to go to the new app and you don't care which 10%, you could put new web app servers in the pool and do weighted ratio load balancing. Just make sure you have a persistence profile so that people aren't being bounced back and forth between old and new.

If you want to have specific people go to the new app, then you'll have to decide how you want to identify them. Say you want to identify them by IP address. In that case you could create a data group of IP addresses that should get the new site, then have an iRule something like this:

when CLIENT_ACCEPTED { if { [class match [IP::client_addr] equals new_web_app_class] } { pool new_web_app_pool } else { pool old_web_app_pool } }

You could also identify them by cookie or by some other more exotic method.

I appreciate your quick response. We would care which they are going to because they are a pretty dramatic look and feel change. We would need to figure out a seed of some sort to start with and then some method to increase the cut over in a controlled way. We would want them always to get the new app once they are there. We would also need to be able to distribute the users of either application to three different data centers with some control over the load to each data center as well. As I look the F5 products I wonder if this would be possible using a combination of the global product and the local product and how it could be done with minimal alteration to the applications themselves. Today we are using a round robin DNS distribution in to a competing local load balancer network.

Well, on your original question, you'll need to determine how you want to identify the users to be moved. The obvious options are IP address and cookies. If you go with IP addresses, your subnets should be carefully chosen to avoid splitting big dynamic pools. (So for example, if you decide RoadRunner customers in Seattle should get the new site, then you would want to do some due diligence to make sure you move the whole dynamic block, otherwise you might get people flipping between old and new sites when their local IP is refreshed.) If you go with cookies, you can be more certain that particular users will stay where they're put, as long as they don't clear their cookies.

Another option, if your application architecture supports it, would be to design a shared static login page and redirect users by username. This would avoid the above problems but might or might not even be possible, depending how your system works.

Thanks for the input. This is what I was thinking as well but looking for confirmation.