Recently I've been thinking about roles and what makes the most sense for a deployment, mainly around the size of the role to pick. If you look at pricing and capabilities of the medium or larger roles you'll notice something interesting; two small roles cost the same as a medium role. Here's a copy of the table size from http://www.microsoft.com/windowsazure/features/compute/:

Compute Instance SizeCPUMemoryInstance StorageI/O PerformanceCost Per Hour
Extra Small 1.0 GHz 768 MB 20 GB Low $0.05
Small 1.6 GHz 1.75 GB 225 GB Moderate $0.12
Medium 2 x 1.6 GHz 3.5 GB 490 GB High $0.24
Large 4 x 1.6 GHz 7 GB 1,000 GB High $0.48
Extra Large 8 x 1.6 GHz 14 GB 2,040 GB High $0.96

Note that the CPU speed is the same from small to extra large, the only differences are in memory, local (instance) storage, and IO (which unfortunately isn't defined in hard numbers.) If you're not running into any bottlenecks in memory, local storage or IO performance, then you can allocate two small worker roles to host your application for the same price as a medium role. This price/core ratio remains the same even up to extra large; 8 small roles = one extra large role.

Since Ruby and Node.js are single threaded, going with something larger than a small role means you're going to have either wasted cores or that you're going to use something like SmarxRole (http://smarxrole.codeplex.com/) with Application Request Routing or run Node.js under IIS with IISNode.exe (http://tomasz.janczuk.org/2011/08/hosting-nodejs-applications-in-iis-on.html). These allow you to run multiple instances of your application in one role instance to advantage of the extra cores. But since the SLA for Windows Azure Compute is only guaranteed if you have 2 or more role instances, you may end up paying a much greater monthly fee over going with a small role size in order to meet SLA. For example, going with two medium instances costs $0.48 per hour while two smalls satisfy the same SLA requirement but only cost $0.24.

The takeaway from this is that you need to carefully consider how many instances of your application you need to service requests, and what resources your application needs during normal operations before determining what role instance size you should use for your application. It may turn out that you are better served by many small roles than a few medium or larger.