If you deploy the new docker containers along with the old ones, having the new ones in an idle state, and then switching your load balancer to the new containers the downtime will be almost zero, if not 100% zero. Keep in mind that this requires extra work to make it work correctly, but it also gives you the ability to easily rollback your frontend changes in case something goes awfully wrong, by just switching back to the old docker containers.
Now, if the changes are not incremental and each version contains major changes in javascript or the UI of the site, for example, you will have to have some kind of "stickiness". Although, you don't have to limit the new version to only one server. If you have 4 servers, you can balance the load of each version to 2 and 2 servers. So yes, it would require having stickiness. But you can avoid binding a user to only one server.
Hi again,
If you deploy the new docker containers along with the old ones, having the new ones in an idle state, and then switching your load balancer to the new containers the downtime will be almost zero, if not 100% zero. Keep in mind that this requires extra work to make it work correctly, but it also gives you the ability to easily rollback your frontend changes in case something goes awfully wrong, by just switching back to the old docker containers.
Now, if the changes are not incremental and each version contains major changes in javascript or the UI of the site, for example, you will have to have some kind of "stickiness". Although, you don't have to limit the new version to only one server. If you have 4 servers, you can balance the load of each version to 2 and 2 servers. So yes, it would require having stickiness. But you can avoid binding a user to only one server.
Load balancing is a fair point. Good one. Thanks again Mr. Koniaris