Azure - dynamic discovery of a web service role url in stage

Question

I am looking at porting an existing application to Azure. It will have an MVC application in one web role and some WCF services in another web role. When you live, the site will live at http://www.myapp.com , and the services will be at http://api.myapp.com when the MVC application is configured to provide services at http://api.myapp.com .

The problem is that pushing the application to the "step-by-step" configuration on Azure. I understand that every click on the scene will cause the services to live at a new URL (something random, for example http://4aa5ae2071324585ba5a902f4242a98c.cloudapp.net/ ). In this case, what is the best way for my MVC application to open the services URL?

One option is to set a dns entry, for example http://stage.api.myapp.com , and update the DNS CNAME record to point to a new url to create Azure every time I click on a scene, but ... yuck.

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

Is there an easy way to do this? I know that I can automate some of the above steps with something like PowerShell, but I really hope that there is something in the Azure infrastructure that makes this easy. It looks like this will be such a standard scenario.

Answer 1

The only way to dynamically discover what the intermediate URL will be is to check an instance of its own deployment identifier. I assume that the MVC website and the WCF service are in the same deployment. If you check the RoleEnvironment.DeploymentID, you will find that it exactly matches the “random” URL used in the stage (ie Http: // [deployment identifier] .cloudapp.net).

While you dynamically create a ChannelFactory on the client side, it should be able to use its own deployment identifier and find an intermediate level URL.

Of course, this is only useful when deploying in a stage. Why don't you just use the Production slot? This name is stable and you can rely on it or the CNAME (rather) that you set for it. You can always have several hosted services (dev, QA, prod, etc.) and just use the production slot on them.

Answer 2

Do not do what @dunnry offers! Azure has a really good endpoint concept that solves your problem. And you have access to this information from your RoleEnvironment class.

You can see my blog post on how to get an endpoint from a client. The key part is creating the internal endpoint on which your WCF service is listening. Keep in mind that you don’t need a new role for this, and personally, I would prefer to place it in IIS along with the original web role and have two of these roles to increase reliability.

Thus, it doesn’t matter what the deployment is, since the communication will take place inside this deployment, whether it be production or production.