A web frontend with a WCF backend in AzurePosted: 21/01/2013
So you have decided to go with a web application that communicates with a backend server? Sounds like a solid architecture! And you want to host all of this in Windows Azure? No problem! The Windows Azure SDK allows you to easily create web and worker roles. Web roles are obviously meant for web applications, and are hosted in IIS. Worker roles on the other hand are similar to windows services. It’s a process that get’s started by Azure, and shuts down when it’s complete.
Once we’ve created this web and worker role, we need to setup a hosted service in Windows Azure. This is the one and only entry point of the two roles. This means that we have only one IP address for the two roles, but we can use different ports. Off course for the web role we would use port 80 or 443. The worker role can be hosted on any other port. Besides being the public entry point, the hosted service also serves as a load balancer for multiple instances of each role.
Problem 1: Resolving address for intra role communication
When we now want to let the web role communicate with the worker role, we have to find the worker role’s address. There are two ways to do this:
- We can dynamically resolve the IP address of one of the worker role instances
- We can use the public IP address, but use the worker role port instead of the web port
Both solutions have pros and cons. The pro of the first solution is that we can access the role directly and don’t need to hit the public endpoint. This saves us a bit of bandwidth and thus money in a cloud model. The disadvantage is that we no longer use the integrated load balancer, so we will have to implement some kind of load balancing on our own when we have more then one instance of the worker role. Another one is that the DNS of the WCF service is not always the same. This can cause problems in some scenarios, for example when using Windows Identity Foundation.
The advantage of using the public endpoint is that it’s easier to configure, and you have. But you’ll have to pay for the extra bandwidth.
Problem 2: Staging configuration & VIP Swapping
Upgrading your roles with a new version, can be done through a VIP-Swap. This basically means that you upload a new package to a staging environment where you can test the deployment. And when everything is working fine, you basically swap the Virtual IP (VIP) addresses in the load balancer of the hosted service, et voila: your staging has become production and vice versa without any downtime.
A staging environment is not a Test environment. Functional testing should be done in another environment. But for testing your deployment on a real azure (which will always be a bit different from your emulated environment in Visual Studio) the staging environment is a great solution.
The problem is that your configuration in staging, will be the same as in production. So your WCF configuration also stays the same. This means that we cannot use the 2nd (easiest) option from above to resolve the worker role’s IP address. Actually when you see staging as a pre-production environment and not as a test environment it makes sense that everything is the same.
Problem 3: Cost
You have to pay for every instance you use. When you have 1 web and 1 worker and both have 1 instance, you’re paying for 2 instances. In some cases, no matter if it’s a solid architecture or not, this might be a waste of resources and money. Any out-of-the-box solution to this will affect your architecture, but is that what you really want? I guess not, so stay with me and I’ll show how we can handle this without changing your design decisions.
Problem 4: Latency
When you communicate between roles, you communicate between two machines. Weather it’s over the load balancer, or not. This means that your application will have to do some I/0 on the network level. Like it or not, but this will introduce some form of latency.
Solution: Combining the web app en WCF service applications in one web role
In Windows Azure, it’s possible to host multiple web sites in the same web role. You can even host multiple sites on port 80 and bind specific DNS names to a specific site! Combine this with the fact that WCF services can also be hosted in IIS (a web role is basically a windows server with IIS), and you can see that we’re onto a possible solution here. We can combine the web application, and the web host for the WCF services into one hosted service (one machine) and still have two separate web applications in IIS. But there are a few tasks you need to accomplish, because this is not a scenario that the Visual Studio tooling supports
- Manually edit the csdef and cscfg (cloud service definition & configuration) files
- Create a build script for the web application and WCF service host
- Create a startup task to point localhost to the DHCP-assigned IP address for that role
Manually edit the csdef and cscfg files:
In your hosted service’s configuration file, you’ll only have one Role. But you’ll have to apply the settings (if any) for both applications. Below is an example of a modified cscfg file:
In the cloud definition file, you will define the “MyProjectName” role you configured in the file above. Each instance of this role will be configured with two web sites. The site bindings and endpoints are all configured for both sites. All other settings must also reflect bot applications. And at the end we’ll define a startup task that I’ll explain later on. This is a sample of a modified csdef file.
Create the build script:
In our cloud definition file, we’ll have to point to the actual contents for the web applications. When you only define one website in the web role, you can point to a project directory. But the cloud package command doesn’t support that when multiple websites come into play. The the contents in the physicalDirectory attribute of the ‘Site’ element will be the content of your web app. No build or config transformations take place. I solved this with a custom build script, but there are other solutions. The PowerShell build script from below builds the two applications, the startup task dll and packages the cspack file using the cspack.exe command line utility. Ideally you should create a MsBuild script for this I think.
Create a startup task for the web role:
Great, our IIS in Windows Azure is now configured to run the web site and web host. We now can call the services from the web site by just using ‘localhost’ right? Not exactly. When Windows Azure creates the IIS sites, it binds the sites to a specific IP address. This address is the internal IP address of the role instance and is controlled by DHCP. Only calls from that specific network adapter are handled by IIS. So localhost which maps to 127.0.0.1 or ::1 isn’t. The solution is to modify the hosts file of this instance and point ‘localhost.be’ to that IP address. We can create a startup task that modifies our hosts file. When a role instance starts, windows azure will launch a batch file where we can call this PowerShell script. We will completely rewrite the hosts file because a role start or stop can occur multiple times, because the instance’s image is reused. The image can even be reused when you upload a new package.
Here’s the PowerShell script SetIp.ps1:
And here’s the batch file that you configured in the startup task definition in step 1 called SetIp.cmd:
Hosting multiple applications in one hosted service role is possible without changing your architecture. By doing this can also simplify your configuration and deployment. Latency benefits too because network I/O is no longer needed (only over the loopback adapter offcourse). The solution is still scalable, because when you have a web site that only needs a request/reply backend, chances are you needed to scale the backend together with the front end. You can even scale to only one instance, reducing costs even more.