March 5, 2010 Leave a comment
In May of 2009, I wrote a blog posting that covered the basics of Azure Service Configuration Options. When I was looking through my blog statistics lately, I noted this posting is seeing a significant amount of traffic. This is tragic because the November release of the Windows Azure platform broke much of what I discuss in that posting. So I figured it was time to do right by that topic and make an update.
So here we are!
First the good news
So the good news is that some things haven’t changed. Our Azure hosted roles still have their own individual configuration files. These files still get deployed to the Azure cloud in the cspkg (cloud service package). We also still have the ServiceConfiguration and ServiceDefinition files and like before, they behave exactly as you would expect.
The best news IMHO is that we finally have published schemas for the cloud service definition and configuration files. Woot! The MSDN pages will do a better job then I could of explain the details of these schemas so I just want to call out a couple important changes.
In the service definition file, we can now specify the size of our VM instance using the new vmsize attribute of the WebRole node. The size controls if you have a small (aka single core) (1.6ghz CPU and 1.75gb of RAM) instance or larger. Each instance above small is just double the size before it (1,2,4,8).
Full details on adjusting VM size can be found at: http://msdn.microsoft.com/en-us/library/ee814754.aspx
Next up is that we can control the version of the Azure VM’s operating system we want to run. This is important because folks (like myself) had concerns about automatic upgrades to the VM’s breaking code and not being able to test our applications before we make the transition. With the new osVersion attribute of the ServiceConfiguration node, we can now control this. Imagine if you will having an already deployed service that is running smoothly on version 1.0 of the Azure OS. Along comes 1.1 and we want to test it. So we deploy our service into staging with the osVersion set to 1.1. We can then run our tests and ensure things are still running smoothly. Once we have verified the service behavior, we can swap the staging and production instances. We’re golden.
Accessing our Service Configuration Settings
In that post 10 months ago I talked about using the GetConfigurationSetting method of the RoleManager class to retrieve customer settings from the service configuration file. It was a simple enough approach. Problem is, the entire Microsoft.ServiceHosting.ServiceRuntime namespace was deprecated in the November release, thus removing four classes contained there-in including RoleManager. The functionality previously contained in that namespace has now been split and expanded into Microsoft.WindowsAzure.ServiceRuntime and Microsoft.WindowsAzure.Diagnostics.
So in the post November 2009 Azure world we get our configuration settings like this:
string tmpMySetting = RoleEnvironment.GetConfigurationSettingValue("myValue");
Still simple enough, and just scratching the surface of what we can do with the the classes of the ServiceRuntime namespace.
But… but… what about… ???
Admittedly, this is pretty short. There’s a significant amount of functionality that I’m only brushing by with this update. But heck, the Diagnostics namespace alone contains enough functionality to write entire chapters about. And the ServiceRuntime namespace gives you a slew of new ways to find out more about the individual service. I’m already in the process of exploring both of these in more detail so look for additional articles once I have some solid information to share. I’ve got a project I’m starting just next week where I’m porting some traditional WCF services to Azure and as part of this, I’ll be spending a non-trivial amount of time focusing on how to make sure that the Azure instances are logging sufficient information to allow for monitoring of the migrated services and even integrating them with on-premise monitoring solutions.
So until next time!