Discussions

News: A/B Technique for Web Application Deployment

  1. A/B Technique for Web Application Deployment (10 messages)

    Kyle Cordes has published "A/B Technique for Web Application Deployment," an article that documents a way to do application deployment without disrupting users by using a redirect at a common "start point." Luckily, he also shows how to handle some of the problems that can show up.
    Have the URL of your application, which I’ll call "/contact" here, be the URL of a proxy application (or "launching pad"). Then have two additional URLs for two specific instances of the actual application. For example, you might have "/contact" as your overall application URL and then "/contact/contactA" or "/contact/A" as one instance where you have that application installed. At the "/contact" URL, install a simple proxy application, whose job is to take a newly arriving user, present them an intro/login screen, then redirect them to one of the specific instances of the application. ... Because you avoid ever shutting down and restarting your whole Web application with your whole user population on it, you avoid the "empty cache" problems that can happen when you do that. Instead, since the switch only brings newly-logging-in users to the new version - the new instance - you gradually have people start using it, so you never take a big hit all at once in terms of cache population.

    Threaded Messages (10)

  2. This is fine for simple updates where you can have the two versions (a and b) of your application running. What happens if the update to your application actually changes things like your database schema, making running both A and B impossible?
  3. database changes[ Go to top ]

    In this scenario A and B typically are totally separate in terms of deployment and database and so can be updated independently. You bleed users from A to B where B has the new code and vice versa on the next change and then repeat. We do this via Apache mod-jk and it works great (although I prefer this than building an actual "login" app as a front). Regards, Bruce
  4. Re: database changes[ Go to top ]

    In this scenario A and B typically are totally separate in terms of deployment and database and so can be updated independently. You bleed users from A to B where B has the new code and vice versa on the next change and then repeat.
    This is all very nice, but how do you know there is no user left on instance A so that you can shut it down? Easy answer (shameless plug): use MessAdmin, my light-weight and non-intrusive tool (zero-code modification) for monitoring Java EE applications! :-) Cheers, Cédrik ________ MessAdmin, Java EE monitoring made easy
  5. Re: database changes[ Go to top ]

    In this scenario A and B typically are totally separate in terms of deployment and database and so can be updated independently. You bleed users from A to B where B has the new code and vice versa on the next change and then repeat.

    We do this via Apache mod-jk and it works great (although I prefer this than building an actual "login" app as a front).

    Regards,

    Bruce
    This does not solve the problem thought. If I understand you correctly you are saying that I start B using a separate database to allow A to continue to use the old schema. If so, then you run into tones of problems updating the new database with stuff being update by users still using the old (A) version. Your approach would only work in very simple cases (say for example B contains a new Web UI template).
  6. Indeed, this article is a little light on specifics. It's basically a vague, hand-wavey, "wouldn't it be nice if upgrades worked like this" kind of thing, with all the hard stuff left as an exercise for the reader. Don't get me wrong, it's a nice idea - but as presented it is just an idea, with no real implementation specifics that would help someone get started. Maybe that's beyond the intent of the author, but it is frustrating to read nonetheless. As you say, having code that depends on a new schema makes this approach hard. You have to phase the migration of your schema changes, and hope you never have to do anything completely contradictory. How else would you handle it? Sentences like this, on how to deal with a cluster, are an example of the ethereal nature of the content: "you could deploy the B application, with a few clicks, across all 37 servers; you could flip that switch in some global way to kick people onto the B, and so on." That's pretty much it on how to deal with a cluster - you just get it to work "in some way". Not wanting to knock the article too much (as I say, I like the idea), but it rather violates the "show, don't tell" rule. I think also that this kind of approach is much easier if you have a predefined strategy for dealing with upgrades before you even start building your app. Upgrade mechanisms should be part of the architecture from the start.
  7. broadcast message[ Go to top ]

    well i liked the way message can be broadcasted to all logged in users. This shall help specially in QA Test cycles where emergency fixes are required and teams are located at some place else - Mittal
  8. Load Balancing Firewall[ Go to top ]

    This is where you should use a load balancer to offload users from each server as you upgrade it. Of course this requires a bit more hardware than the technique described here, but it's simple and independent of your application. And regardless, you'll always have the schema change issues.
  9. application/x-httpd-fastphp??[ Go to top ]

    I click on the link, and it's asking Firefox to download something with that kind of content. I've no idea what that is. How is what he's talking about here different from a normal load balancer? Any modern load balancer has to ability to isolate legs in your system, including no longer directing traffic to it. Also, how does this help with bookmarks? If they bookmark "contactA" and only "contactB" is available, how does that work? As I said I didn't read the article, so I may be missing something.
  10. Re: application/x-httpd-fastphp??[ Go to top ]

    Can't view the page either. :( Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1
  11. Use WebLogic 9[ Go to top ]

    Since version 9 (released in may 2005), BEA WebLogic Server has a feature called "Side-by-side redeployment". WebLogic is able to maintain two versions of the application. Existing clients will remain with the old version, and new clients will acces to new version. As long as the old sessions disappear, old version is retired. More information: http://edocs.bea.com/wls/docs92/deployment/redeploy.html#wp1020276