The joy of the web farm framework

Project A rumbles ever closer to its release date, and now more than ever the team is pulling together and all the loose threads are starting to tighten and a very classy looking product is emerging from the dust.

This frenetic pace however leaves little time for my primary projects at the moment, both the distributed testing and the integrated workspace projects are effectively on hold until we've gone live in October.

But, there's still plenty to talk about in the automagical world of build and deployment.
Today, the Microsoft Web Farm Framework really pulled it out of the bag for us.

Our new front-of-house website is based on SiteFinity, which like any CMS can run like a bit of a dog until you enable caching and throw some more hardware at it. Today, using WWF2, we scaled-out  SiteFinity over two hosts.

What was remarkable is how incredibly easy this happened. After my recent experiences with  AppFabric I was less than keen to get involved with WFF, but it turns out, my fears were baseless.

In a matter of seconds, with the aide of the wizard...
  1. Created a new server farm
  2. Added the two machines that were to play host to SiteFinity
  3. Configured the load balancing profile
  4. Configured the client affinity
  5. Added a simple rule to match the HTTP_HOST to the new Server Farm
  6. Sitting back to watch the management statistics
I thought about posting snapshots, but it really isn't required. WFF just works! :)

Where's the automation?

Good point,  using a wizard doesn't really count.

The good news is, yes, this is scripted. In fact, the WFF/ARR services have been scripted for quite some time as Project A relies heavily on both WFF and ARR to deliver much of its traffic to the right endpoints.

Today however, was the first time that WFF had been used for something more than a simple routing container, today it became a load balancer!

I need to genericise my scripts a little before I post them online, as they perhaps give away a little bit of information as to how Project A is structure, and that won't do. Equally, these are scripts in the truest sense, very long, very procedural, and not very pretty, so before I show them to the world, a little bit of a code-tidy is required I think :)

This is definitely something I'd like to share, WFF is extremely neat, and I'd like to hear more people are using it.

What about the application itself?

Well, that's a good question, setting up a load balancer is one thing, but the application itself needs to be installed on two separate locations also. 

The good news here is that our existing deployment scripts are configured in such a way that they permit a package to be deployed to multiple hosts, so this part of the work was so trivial. 

   packageName = "SiteFinityWebsite"
   deployment = @{
      servers = "Host-A","Host-D"
      httpBindings = @{ipBinding = *; hostHeader = "sitefinity.{host}"}

This is a severely paired back example of our platform configuration object, there are almost a hundred of these package definitions. However, all that was required to publish this package to two servers, was to add the new destination to the packages servers property.

Thanks for reading, and I promise, there will be code posted.

Update #1: Notes to myself

WFF2 was actually a complete nightmare to install. I seem to recall that it existed in some kind of twilight zone, where in the end, I could only install it with the WebPICmd. It was too new for the Web Installer, too old for the previous incarnation, and it could not be installed outside of the WPI. 

I've got this little gem scripted in my provisioning scripts, so I'll be sure to add that to the next update of this post.