domgreen

Hosting multiple web sites in a single Windows Azure web role is much easier than it sounds, all you have to do is update the ServiceDefinition file as below to add in a new Site (unfortunatley, this can't be done via the VS associate menu item) to the Sites node and create an endpoint where it can be exposed.

In the below example I add a new web project to the solution, at the same level as the one create automatically by the VS tools.

When you then run your cloud application you will be able to see that two websites are created within IIS, and only a single node has been launched in the Compute Emulator.

 

After a previous post where I discussed the benefits of using existing tools over creating your own build tasks I have been able to reproduce exactly the same deployment script working in Rake as I had previously shown in MSBuild using the Windows Azure Tools to control the deployment and initialization of instances in the public and local cloud environments.

When deploying to the public cloud the only thing that I have changed in the scenario is to add a line to use the CSPack tool rather than relying on the MSBuild tasks supplied with the Windows Azure SDK to create the cloud package for my application.

The full Rake build, deployment and initialization script is below, showing that we can use all the same tools and concepts independent of the build engine. This script relies heavily on calling out to the command line with the exec method that I have created to pass in the command line arguments.

 

When running an automated build to deploy your application into Windows Azure you need to at some point run a packaging script, this will take all the components of your application and turn them into a .cspkg file ready to be deployed to Azure with the correct configuration.

I would have normally done this using the CSPack Tool and something like this:

This shows a CSPack command creating a web and worker role for an application (tokenized).

This gets annoying to keep updating and can actually get quite confusing especially when the SDK upgrades and you need to go and figure out what changes you need to make to your packing command to ensure the .cspkg file is created correctly.

However, there is good news coming … if you are using MSBuild you can call upon the build targets that are part of the Windows Azure SDK and allow it to do all of the packaging for you.

The targets are typically located here:

C:\Program Files (x86)\MSBuild\Microsoft\Cloud Service\1.0\Visual Studio 10.0\Microsoft.CloudService.targets

You can then add these targets to your own MSBuild targets like so:

Then call on the following targets:

• CorePublish – This packages up your application as a .cspkg file to be published into the  public cloud
• CorePackageComputeService – This packages the application so that it can be run on the local development fabric.

These two targets use the CSPack command under the hood but allows you to defer the responsibility to the Azure targets rather than having to write the CSPack command yourself.

Here is how I have used these targets on a previous project:

Then use the csrun.exe command line tool to launch the devfabric and a browser for the site to be displayed and prove that we have the site running locally:

 

Finally we can then run cspack.exe again without the /copyOnly command and altering the /out variable to generate a Windows Azure cloud service package (cspkg) to be put into the public cloud.

Whilst looking at how to scale applications in Windows Azure I have had the need to see how the nodes react when the number of cloud instances of a web or worker role change.

One way to view how the application would react and see the number of instances scale up or down is to use the development fabric that ships with the Azure SDK.

If we have a simple “Hello World” Azure application and configure it to use a single web and worker role we will have the following configuration and nodes.

ServiceConfiguration for cloud application.

WebRole and Development Fabric.

Now that the application is running within the development fabric we want to increase the amount of instances that are running for one of the nodes. We can easily go back into Visual Studio and alter the ServiceConfiguration.csfg file to identify the number of nodes that we wish to have for our Web Role.

Updated ServiceConfiguration.

The problem with updating the Service Configuration in Visual Studio is that the changes do not get applied to the running service within the developer fabric, to get these changes applied we have to update the configuration of the running service with the newly saved config. This is done by executing a update on the service with the CSRun command line tool.

We can open the Windows Azure SDK Command Prompt and browse to the application directory containing the ServiceConfiguration.cscfg for the project we are running ( ..\Projects\WindowsAzureDevFabricProject\WindowsAzureDevFabricProject ). From here we make the following call into the development fabric with CSRun:

csrun /update <deployment-id>;<new-configuration-to-apply>

csrun /update 46;ServiceConfiguration.cscfg

The deployment ID, 46 in our example can be found by looking in the development fabric simulator environment. Using this and the new configuration (updated in Visual Stuido) we have now been able to scale up our web role and add an extra node to the application.

CSRun Command and Development Fabric with added node

You will now be able to scale by increasing and decreasing the number of nodes in the development fabric, giving you the ability to debug and view how your application manages with these configuration changes.

Happy Scaling

Microsoft have made a small update to the Windows Azure Dev Portal and added the ability to configure the operating system that are running on your nodes and how they are updated.

As you can see in the below image the new magic “OS Settings…” button is now available.

Clicking on the “OS Settings…” button takes you to the following screen to configure your operating system options and how it is updated:

Hopefully, more updates will start rolling out to the dev portal over the coming months.

DDD Scotland has been a great weekend of lots of geek-ery, fun and fire. It was also my first experience of speaking at a large conference and gave me the opportunity to talk about some of the things I had learned whilst developing on the Windows Azure platform over the past year, working with the European Environmental Agency and RiskMetrics.

The Infrastructure Access Layer, or IAL for short is a simple concept, nothing new, in-fact you have all been using something similar for years when programming against your databases. I have just expanded the concept to the cloud (and the ability to create “cloud ready” applications).

Infrastructure Access Layer (IAL)

 

The Infrastructure Access Layer is simply a way to abstract away your underlying infrastructure from your business logic or processing. This means that I can easily change how my applications interact with the infrastructure just by changing a method within the IAL and the business logic would be none the wiser.

Lets take a simple example, I may be developing an applications that takes work items and processes them. I create a method in the IAL called GetWorkItem which will return to my business logic the work item to be processed. This method can then call out to Azure Queues to get a work item, or maybe in the future you will want to switch out where we are getting the work item from, maybe we want to use a web service to call another location, use blob storage to store large work items or listen for a work item to be passed onto a service bus. This can all be dealt with in a single place.

All the business logic knows and cares about is that it is going to call the GetWorkItem method and get a work item back, not where it came from or how it received it it.

Cloud Ready…

Even with more and more people are moving toward the cloud, there are still companies that aren't quite ready to make the jump, but realise that in the near future may have to and want to know how to create applications that will be able to transition easily to the cloud when they are ready.

By programming against the Infrastructure Access Layer companies will be able to make this move a lot smoother, by just replacing the needed classes so that they interact with the cloud rather than the old infrastructure.

A great example of this would be using a messaging system such as MSMQ as part of your on premise application, and then being able to easily switch this out for Windows Azure Queues or the App Fabric Service Bus when moving into the cloud. Having to make minimal if any changes to your business logic.

Keeping the cloud contained

As I talked about in my last post the cloud can end up getting everywhere and you can soon end up breaking the principle of DRY (Don’t  Repeat Yourself).

With the IAL you can easily keep the cloud contained, letting a minimal number of project have access to the cloud, making SDK upgrades and maintenance easier.

Is that it?

It is indeed. As I said at the start, the IAL is a simple concept that allows you to abstract away your underlying infrastructure from your business logic and also help create cloud ready applications for when people are ready to make that push to the cloud.

I'm sure everyone is aware of the recent volcanic eruption in Iceland and the cloud of ash that has been spewed out and more importantly the knock on effects this ash cloud has had on not just Europe but the whole world.

Clouds can Spread …

The ash cloud started out in Iceland where it eventually moved and spread out to cover the UK and Europe, even some reports say that it got as far as Canada. Grounding planes and crippling transport for a number of weeks.

This got me thinking, not all clouds are nice white clouds, some are evil volcanic clouds that actually do more harm than good especially when not contained to where we want them to be.  (the ash cloud would have been fine if it had not strayed into European airspace).

The same is true in your applications, when developing for the cloud you can find that the cloud can end up spreading throughout your applications and if your not careful touching every section of code you write.

This can then be a real problem when the underlying SDK to interact with the cloud changes and you have to go through all of your application looking where to refractor and make changes.

Contain Your Cloud

To combat this I contain any code that will access the cloud within few specialised “cloud” projects within my application.

This means that throughout the application if I want to access the Azure message queue, I call a single method from one of my cloud project that will return me a message, meaning that no other part of you application needs to know how to deal with the cloud.

Added Benefits

Containing your cloud not only allows you to keep to the DRY principles and code re-use it, makes maintenance of your application easier and can reduce code smells. One of the biggest benefits is that it also allows you to easier test your applications without having to rely on the cloud or developer fabric, as you can create your cloud methods in a mock-able way.

I have recently been asked a number of questions both internally and from customers about when you will be billed for Azure usage.

As Eric Nelson’s recent post describes, if you suspend a service you will still be paying this is due to the fact you will still have your application deployed on the server ready to start again. With your application utilizing the server others will not be able to provision its usage.

When you select delete you will stop paying as you will no longer have servers provisioned for your application and the recourses will be freed up for others to use.