Is it a good idea to reuse the Azure web role to handle the backend?

Question

I port a huge application in Windows Azure. It will have a web service interface and a processing server. Until now, I thought that I would use web roles to serve client requests and work roles to handle the backend.

Managing the two types of roles seems problematic - I need to decide how to scale the two types of roles, and I will also need several (at least two) instances of each to provide reasonable resiliency, and this will slightly increase operating costs. Also, in my application, client requests are fairly lightweight, and backend processing is heavy, so I expect backend processing to consume much more processing power than serving client requests.

That's why I'm thinking of using web roles for everything - just create threads and execute both service requests and backend processing on each instance. This will complicate this role, but I think it’s easier to manage. I will have more cases of a uniform role and better fault tolerance.

Can web roles be reused for backend processing? What disadvantages should I expect?

Answer 1

It looks like you already have a pretty good idea of ​​what to think when using multiple roles:

• The cost of 2 copies to meet the SLA (although some background tasks do not really require SLA if the end user does not see the impact)
• Individual scale units

However: if you run everything in one role, then everything scales together. If, say, you have an administrative website on port 8000, it may be difficult for you to reach it if your user base slams the main website on port 80 with traffic.

I wrote about the combination of roles on the Internet and workers, here , which describes in more detail what we are discussing here. In addition, after some time in March, the restriction of 5 endpoints per role was removed - see my blog post here only for how far you can click endpoints. Having this less restrictive endpoint model really opens up new opportunities for single-role deployment.

Answer 2

From what I understand, you are asking if it makes sense to consolidate service levels, so you only need to deal with one layer. At a high level, I think it makes sense. The simpler, the better, if it is not so simple that you cannot complete your basic tasks.

If your main goal is performance and your service calls are built-in (which means the caller is waiting for a response), then combining the layers can help you achieve better performance, since you do not have to deal with the overhead of additional network delay for additional physical layers . You can use the parallel task library (TPL) to implement your thread logic.

If your main task is scalability, and the calls at your service are out of range (this means that the caller implements the “fire and forget” pattern), then using processing queues and work roles may make more sense. One of the principles of cloud computing is loosely coupled services. While you have more maintenance work, you also have more flexibility to independently create your own layers. Your work roles can also use the TPL mentioned above, so you can deploy work roles on large virtual machines (say using 4CPU or 8), which would reduce the number of instances to a minimum.

My 2 cents. :)

Answer 3

I would suggest that you develop them as separate roles: the Internet role and the worker role, and then simply combine them into one web role.

so in the future you can easily convert to real split roles if necessary.

for more details: http://www.31a2ba2a-b718-11dc-8314-0800200c9a66.com/2010/12/how-to-combine-worker-and-web-role-in.html http: // wely- lau.net/2011/02/25/combining-web-and-worker-role-by-utilizing-worker-role-concept/