To answer that we first have to look at the term ‘fabric’.
You can think of a fabric (or ‘switched fabric’) as a network of interconnected nodes. The connection is facilitated by high-speed switches through fibre-optic connections, while nodes are usually servers and other technical infrastructure.
If the network is large enough and viewable from a distance, it could look like a ‘weave’, or a ‘fabric’. This terminology is also used at the processor level describing the network of buses on the chip.
The Azure Fabric is not much different. It is made up of nodes, which are servers running Windows Server 2008 and load balancers, while the edges are the power, Ethernet, and serial communications. Each computer node might be a dedicated server, or a server petitioned for multiple virtualised environments.
When we write our Azure applications locally, there is a simulation of this fabric running on our machines, called the ‘Development Fabric’. This lets us simulate load balancing and multiple nodes for our web and worker roles.
The Development Fabric is facilitated via a series of running processes that simulate load balancing and hosting your application.
When you run a project of type ‘Cloud Service’ (the project that contains a service definition and Role links out to other projects), the development fabric is initiated (as well as a simulation of local development storage). In the diagrams below, we see the process tree as initiated by Visual Studio and the location of the files.
It is actually possible to spin these services up yourself, rather than needing Visual Studio to do it. Although I haven’t actually tried, it should be possible to copy these files to a testing server and run them up so that you can hand your application over to your testers.
Another thing you might be able to do (I have yet to try this as well) is spin up the load balancer and various services inside unit tests. Most of these executables are in managed code and trusty old Reflector can bust them open for us. Looking at the code for DFloadbalancer, we see that it is simply simulating a load balancer through usage of WCF, binding via a Named Pipe. We are given the load balancer classes in the LoadBalancer.dll so I’m confident there is some cool unit test automation to be achieved via directly calling the necessary classes. If you do go down this track, please let me know how far you get.
In a future post I will be discussing the Azure Fabric Controller.