<div>
Thanks Paul, a very interesting response. Let me explain my use-case a little more.</div><div><br></div><div>We already have functionality in our platform which allows us to control feature accessibility based on a user’s role. This works well for small, controlled scenarios, typically something like calling the same method with a different parameter or using a new setting. Something along those lines.</div><div><br></div><div>However, we’re in the middle of completely upgrading a complex Rails app (50k+ loc). To reduce risk to our paying customers (who are themselves businesses) we have to have some mechanism for controlling which version of the app your request will hit. We want to incrementally move traffic onto the new version rather than performing a big-bang switch-over, which would be very risky indeed. This would not be a permanent situation though, just something we could use during large, risky roll-outs of new code.</div><div><br></div><div>Granted, the logic in the load balancer (or any other layer that serves this purpose) would have to be very simple. But, this logic would have to exist in one of the very first few layers that a user request goes through. I don’t see any other place for it.</div><div><br></div><div>Based on our research and the feedback from everyone we’ve spoken to, there is no silver bullet here. There are a lot of “it depends” answers, which certainly muddy the waters. However, we are fairly certain that with risk mitigation as our primary concern, this approach looks the best so far. It’s more about “how do we do it” rather than “are we doing the right thing”.</div><div><br></div><div>Once again, thanks for a great reply though.</div><div><br></div><div>Best,</div><div>Ed.</div><div><div><br></div></div>
<p style="color: #A0A0A8;">On Wednesday, 5 March 2014 at 14:21, Paul Robinson wrote:</p>
<blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;">
<span><div><div><div dir="ltr">I'd like to propose - with respect and a clear admission I don't understand your exact use case here - that you're doing it wrong. The point that made me think this is:<div><div>
<br><div>On 4 March 2014 14:29, Ed James (Alt) <span dir="ltr"><<a href="mailto:ed.james.spam@gmail.com" target="_blank">ed.james.spam@gmail.com</a>></span> wrote:</div><div>
<br><blockquote type="cite"><div>
<div>What we want is to direct a user’s requests based on an application setting - this could be in the db, memcache, redis, whatever. The retrieval of the setting is another problem I think. It’s the logic around that setting's value that I’m interested in.</div>
</div></blockquote><div><br></div><div><br></div><div>This suggests it's an attribute of the user that determines the routing. I think that's a poor design. We just had a similar decision to make internally, and in the end we realised this was going to get very messy, very quickly.</div>
<div><br></div><div>The application setting you're talking about is directly equivalent to a user role if you abstract it far enough, what this configuration would lead to is code duplication: some servers over here have slightly different code to servers over here, and we're routing to them based on a setting per user.</div>
<div><br></div><div>What makes more sense is have the same code run everywhere and to handle the changes according to application setting within the method or as a before_filter. </div><div><br></div><div>If it is really very remarkably different, then it's a separate service that should be in a separate application on separate servers and you should deal with it accordingly.</div>
<div><br></div><div>Load balancers exist to ensure high availability and in ASGs on AWS, ELBs also allow you to scale up/down resources based on load. That's it. Trying to get any load balancer - whether it be an ELB or HAProxy or Varnish or something else - to start managing application logic seems like a bad idea. </div>
<div><br></div><div>Business logic lives in apps not in the load balancer.</div><div><br></div><div>And now, where I contradict myself: we have an AngularJS client for a new product we're building as well as native iOS and Android apps. They talk to a whole host of micro-services because we have a full-on SOA at the back end. </div>
<div><br></div><div>In order to be able to QA properly and also move users over to new versions of services a few at a time we have on user sign-in a call to retrieve the top level service URLs: <a href="http://servicex.domain.com">servicex.domain.com</a> and <a href="http://servicey.domain.com">servicey.domain.com</a>, etc.</div>
<div><br></div><div>These are defaults we can over-ride per user, so I can move one QA guy onto a new version of a service whilst leaving everybody else intact, and then to understand load I can move people over. </div><div>
<br></div><div>Could I (ab)use this to mimic your requested functionality? Sure, but I know that's going to be hard to manage so I'm more likely to use it for a few hours at a time at most. Seamless roll-on/roll-off of service updates is great. Using it as a permanent fix to avoid a conditional branch in an action? Probably not so great long-term.</div>
</div></div></div></div>
</div></div></span>
</blockquote>
<div>
<br>
</div>