I have been working on implementing a (1) server, (n) worker role servers setup via WCF. One server handles requests, passes the work on via WCF to an available Worker Role, which processes the request, and passes the data back to the server. It’s a bit too complicated for what I am able to handle. I’m trying to simplify the solution, and thought I could remove the WCF component by creating (n) servers, each capable of handling both the worker role service and the web server role. Assume each worker server is capable of only (1) worker role.
So that way, when a request comes in, some round-robin style handler picks an available server and forwards the HTTP request to that server/worker. That server/worker does the work, and returns the data directly to the requester.
Is this a feasible approach? I realize for some advanced developers, the WCF solution would pose no problem. I’m asking if there is a simpler, more hacked style approach that would allow me, with my limited ability, create a 1 server solution, then replicate and load balance multiple versions of that solution?
Any suggestions mucho apprecianado!
What you describe is precisely what Load Balancers are built for – they attempt to distribute incoming requests across a pool of available servers.
Many hosting companies offer hosting plans involving multiple servers which you can choose to load-balance incoming requests against.
For example: Rackspace offer load balancing as an optional feature of some of their hosting plans.
If you host a site with more than one web-role instances in Microsoft’s Azure cloud, your site is automatically load balanced for you. You can also build your site such that it is dynamically load-balanced in multiple geographical regions also so that requests originating from, for example Asia, are routed to a datacenter in asia, reducing latency and intra-datacenter bandwidth.
Also, consider introducing queueing/message-bus between your front-end website and your back-end batch/intensive workload processing. This way you can independently scale the front and back ends of your system.
Having said all of the above, don’t over-engineer your solution – focus on building a stable, solid, reliable, efficient system, then monitor and measure its performance and tune it where appropriate. Otherwise, you could spend valuable time and effort implementing features/tweaks that don’t actually benefit the site or the user!
Update 2012-01-31 based on OP’s comments:
If you want to make your worker roles perform one task at a time and only go back for another piece of work when they’re no longer busy, I suggest you invert your architecture:
Instead of having some front-end server try to work out which of the workers is “busy” and distribute work accordingly, consider having your front-end server queue incoming messages into an “incoming” queue.
Workers “pull” a new work-item from the front-end, perform whatever work is required and then inform the front-end that the work is complete and ask for another work-item.
The beauty with this approach is that it can scale in a linear fashion and can be HIGHLY resilient.
When a worker “pulls” a new work item, the front-end timestamps the message and moves it to a secondary “pending” queue. Workers inform the front-end when they’re done with a work-item; the front-end moves completed items to a “completed” queue (or deletes them if it doesn’t care).
The front-end can then run a periodic scan of the “pending” queue, looking for messages that have been waiting too long and can return those messages to the “incoming” queue if they’ve been pending for too long.
Queues can be A LOT of fun 🙂 However, building such a queueing system can be complex and making it truly reliable can be time consuming and costly.
Luckily, you can take advantage of some very proficient message-bus implementations that’ll provide you with 90% of what you’ll need to make this happen! My favorite is Microsoft’s cloud-based Azure Message Bus which provides you a pretty bullet-proof durable-messaging, pub-sub and queueing infrastructure that’s ideally suited to your scenario.
HTH.