[LRUG] Intelligent load balancing
Paul Robinson
paul at iconoplex.co.uk
Wed Mar 5 06:21:33 PST 2014
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:
On 4 March 2014 14:29, Ed James (Alt) <ed.james.spam at gmail.com> wrote:
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.
>
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.
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.
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.
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.
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.
Business logic lives in apps not in the load balancer.
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.
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: servicex.domain.com and servicey.domain.com, etc.
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.
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20140305/28eadbd3/attachment-0003.html>
More information about the Chat
mailing list