One of the challenges developers will face when developing Windows Azure web applications is: where do I put my settings? In the ServiceConfiguration file or the web.config? There isn’t one correct answer. The challenge of keeping everything in the web.config is that it makes changes and deployment much more difficult. Because the web.config is part of the deployment, any change to the file also requires a redeployment. If you use a build system that targets your dev/stage/QA/prod environments automatically and can provide the correct settings in the web.config for you, this might mitigate the problem. The answer then is to migrate these settings to the ServiceConfiguration file as it requires no changes to our deployment package. In this screencast I’ll show you some strategies for doing that for components that are more difficult to migrate, like the SqlMembershipProvider… Link to original post and download links.
I have a few posts along the lines of scaling an Azure application, but thought I’d throw this tidbit out. You might be developing your own management system for your Azure deployments, and in doing so, having visibility into the roles running within your deployment is very handy. The idea behind this series of posts is to ultimately explore how to get visibility into roles, and then a few ways we can tackle inter-role communication. The first task is to define internal endpoints for each of our roles. If you don’t do this, you will only have visibility into the current role. So, if you have a single role solution (any number of instances) than you don’t have to do this. Let's take a pretty simple example where we want to enumerate all the roles in our deployment, and their instances: foreach (var appRole in RoleEnvironment.Roles)
var instances = RoleEnvironment.Roles[appRole.Key].Instances;
foreach (var instance in instances)
While this code will work fine, by default it will only show you the instances for the current role – other roles will show an instance count of zero. Running this in my workerrole and trying to enumerate my webroles, I see this:
What we can do is define and internal endpoint for our roles that will allow this data to be discoverable. In Visual Studio, it’s simply a matter of going into the properties of the role and defining an internal endpoint:
And we’re done. Debugging the solution again:
We can do the same for our workerroles to be discoverable by other webroles, etc.
In some future posts, I’ll build off this idea for doing some lightweight service management and role communication.