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.
Previous: 
Next: 
Comment Meta:
XHTML:
More Options ...
Categories
Tag Cloud
Blog RSS
Comments RSS
Last 50 Posts 
Back
Void 
Life 
Earth 
Wind 
Water 
Fire 
7:59 am - March 23rd, 2009
[...] What Is: The Azure Fabric and the Developer Fabric – Steve Nagy [...]
8:44 am - March 23rd, 2009
[...] I’ve helped define the word ‘fabric’ and in specific, discuss the details of the Azure Fabric and the Development Fabric. The Azure [...]
12:58 am - March 24th, 2009
[...] Azure Fabric Controller - read What Is: The Azure Fabric and the Development Fabric [...]
8:54 am - April 19th, 2009
[...] few weeks ago I discussed the concept of what the Azure Fabric really is, and then followed with a discussion about how the Azure Fabric Controller works to [...]
7:06 am - May 14th, 2010
This one line snagged me, “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.” and brought up a few questions.
What is a good way to not only unit test application code in and for the cloud, but what would be a good way to setup integration tests. Have you seen, or maybe you would want to do a blog entry (maybe a joint one as I’ll be researching this too) of how one should or could test their respective cloud application and roles based on unit testing ideals and integration testing?
8:02 am - May 15th, 2010
That’s a good question. Typically I separate my code into testable projects. For example, a worker role is really about processing units of work. Those units of work and the handlers are typically in a class library project. The actual worker role is just a harness at the end of the day. Unit testing a worker role should be identical to unit testing the code for a windows service; the concepts are pretty much identical. Web roles are the same; imagine I have an MVC web role. When I do MVC projects I move my model and controllers into a separate class library project where they are more easily referenced and tested from test projects. Only the views stay in the web role. In summary, the approach to unit testing is really identical.
Integration testing is harder. I guess you have to ask yourself; is there any point integration testing local versions of the app? Would you actually want to do your integration tests up in Azure? I have a fair number of ideas about this. I’m also waiting for a response back from MS about IoC and where we can hook into RoleEnvironment. I’m thinking a large post/article about dependency injection, IoC, and testability all in one. Happy to do a joint blog post about it. Hit me up on email or twitter to discuss.
1:04 pm - May 16th, 2010
[...] with the Windows Azure Platform and certainly makes life difficult in conversations. Runs on the Azure Fabric and includes management components such as the Fabric [...]
9:15 am - January 15th, 2011
[...] algumas coisas. O Development Fabric é iniciado quando executamos uma aplicação Azure local(veja mais aqui nesse post). E confira aqui no MSDN como usar o Development [...]
8:38 pm - January 11th, 2013
kliknij tu…
Above The Cloud » Blog Archive » What Is: The Azure Fabric and the Development Fabric…