Azure - dynamically discovering service web role url in stage

Question

I'm looking into moving an existing app to Azure. It will have an MVC app in one web role and some WCF services in another web role. When live, the site will live at http://www.myapp.com and the services will be at http://api.myapp.com with the MVC app configured to point to the services at http://api.myapp.com.

The problem is when pushing the app to the "stage" configuration on Azure. My understanding is that each push to stage will cause the services to live at a new url (something random like http://4aa5ae2071324585ba5a902f4242a98c.cloudapp.net/). In this case, what is the best way for my MVC app to discover the url of the services?

One option would be to setup a dns entry like http://stage.api.myapp.com and update my DNS CNAME record to point to the new Azure staging url every time I push to stage, but... yuck.

Another option would be to push to stage, get the new urls for the services, RDC to each instance of the MVC role and manually update the configurations. Also yuck.

Is there a simple way to do this? I know I could automate some of the steps above with something like PowerShell, but I'm really hoping there's something baked into the Azure framework that makes this easy. It seems like it would be such a standard scenario.

Answer 1

The only way to dynamically discover what the staging URL will be is to have the instance check its own deploymentID. I am assuming here that the MVC website and the WCF service are in the same deployment. If you check the RoleEnvironment.DeploymentID, you will find that this corresponds exactly to the 'random' URL used in staging (i.e. http://[deploymentID].cloudapp.net).

As long as you are dynamically creating the ChannelFactory on the clientside, it should be able to take its own DeploymentID and find the staging URL.

Of course, this is only useful when deployed in staging. Why don't you simply use the Production slot? That name is stable and you can rely on it or the CNAME (more likely) that you set for it. You can always have multiple hosted services (dev, QA, prod, etc.) and just use the production slot on them.

Answer 2

Don't do what @dunnry is suggesting! Azure has a really good concept of endpoints that solve your problem. And you have access to this info from your RoleEnvironment class.

You can take a look at my blog post on how to get the endpoint from the client. The key part is to create an internal endpoint at which your WCF service is listening. Keep in mind though, you don't necessarily need a new role for this, and personally, I would rather host it in IIS alongide the original Web role & have two of these roles for improved reliability.

This way, it doesn't matter what the deployment is, because the service communication will take place inside that deployment, be it staging or production.