On an earlier post, I showed how you could create schedule tasks on a web role, and also to include multiple websites/web apps onto a single role. It's handy to do, and may shave off dimes spent on Computing role.

However, overloading a web role doesn't come for free. Here are a few things that you need to be aware of before doing so.

design for 2 and you'll be able to scale to 2,000

Scalability doesn't come for free. Most cloud computing platform allows you to scale by partitioning things into smaller chunks. For e.g. Azure table recommends you to chunk data by using partition keys, computing roles is partitioned by update and failure domaines, etc.

Building things for 1 role may lead you to a path where you can't easily increase the number to 2. For e.g. a web role that contains scheduled tasks will have 2 scheduled task running once you increase the role number to 2? That might OR might not be something that you want to do. The key here is to be aware of it.

Keep in mind that there could be more than one instance of everything. Here is often where queues becomes important.

also it's important to note that Azure's SLA only applies when you have at least 2 instances of the same role.

what to scale and by how much

We often don't need to scale up/down everything equally. A few things will be the bottle necks and we want to constantly focus on those.

Say we have a web role that does multiple things and happy to co-exist with multiple instances of itself. Without clear separation of concern, we will need to double the number of instances of everything rather than just on the bits that we need the most.

At this point cost efficiency, fault tolerance, performance often achieved by having roles that have single responsibility.

It sometimes better to have 2 extra-small roles than 1 overloaded small role.

deploy everything all the time

Azure deployment is done at the level of a role. So if you need to update a component/web app/website in a role, you still need to do the deployment for the whole role.

(the lack of) IIS isolation

from ’˜How to configure a web role for multiple web sites'

Windows Azure does not impose a security boundary between the sites and applications that are running within the role. The only configurable boundary that is available is one between Administrative and non-Administrative users. This can have implications when you are considering the security of the web sites. For example, if one user's web site is using an HTTPS certificate for the hosted service, another user's web site in the same web role would be able to access the HTTPS certificate for that site.

Don't even think of using a single web role to do multi tenancy. IIS isolation boundaries can only be done if you're using your own VM role and configure things yourself for each sites.