Theoretical concepts in Windows Azure

Some useful theoretical concepts in Microsoft Windows Azure Platform. Tried to include the much needed information pertaining to Windows Azure. Also tried to present the points in a simple and easy to understand manner.

Windows Azure Platform

1. Windows Azure:

a. Consists of Compute Roles - Web Role, Worker Role, VM
- Consists of Hosting Services, Virtual machines configured via role instances.
- Role can be Web Role and Worker Role.
- Worker Role - 2008 R2 (64 bit Default) and .NET 3.5/4.0
- Web Role - All components in Worker Role + IIS
- Role can consists of:
--> Definition(STATIC, endpoints, VM size(Extra Small, Small, Medium, large, extra large - Resource to be used, Settings, local storage, etc., CODE), Repackage and deploy)
--> Configuration (Dynamic in nature, packaged separately)
- End points can be Input or Internal. Input can be public. Internal can communicate in between the roles.
- Every role inherits from class Role Entry Point.
- Lifecycle of RoleEntryPoint.
--> On Start() - Role is in busy state. Cannot pass to Load balancer.
--> Run() - Role is now in Ready state. Load balancer can communicate.
--> On Stop() - Shutdown the role. Happens while repackaging and re-deploying.
- Role code executes in WAIISHost.exe
-VM(virtual machine) gives us more control over the virtual environment where our application is deployed. We deploy our application on Microsoft Virtual Hard Drive.
b. Storage - Queue, BLOB, Table
c. Connect

2. SQL Azure

a. Database
b. SQL Azure Reporting Service
c. SQL Azure Data Sync

3. Azure AppFabric

a. Service Bus
b. Caching
c. Access Control

Fabric Controller

- Configures the VM size, endpoints, etc.
- Communicates with Fabric Agent.
- Fabric Agent is present under HOST VM.
- Fabric Agent downloads the VHD for Web Role and provides it to Fabric Controller. This process is known as Guest VM
- Our code runs on Guest VM. It can communicate with Fabric Controller via host VM only. Direct access is not provided.
- 1 node can have multiple Guest VM. Each guest VM has multiple Guest Agents.


- We must create a storage account to host our application on Cloud. The limit is 100TB.
- Storages supported are BLOB, Tables (not RDBMS), Queues, Drive(Map drives on local storage mapped to BLOB on AZURE storage).
- Avoid Read/Write Drives. It may run into problems if there are multiple instances.
-Creating a storage account will give us 3 URIS. For ex: If cgStorage is a storage account it will create the following URIs:,,
-By default, BLOB is a secured access. Set the permission level as public in the code or provide an access key.
- Cost plays an important role in architecting the CLOUD applications. Moreeinteractions with CLOUD may charge us more.

Table Storage:

- Not RDBMS. It is an entity store.
- Entities must have some properties defined. The properties are: Partition Key, Row Key, Time Stamp.
- Partition key is multiple. Row key is unique.
- Each transaction can have 100 records.


- Role(Worker Role or Web Role) can pass the request to Azure diagnostics Trace listener.
- This request will be passed on to VM storage.
- VM storage may contains IIS Logs, Trace Information.
- Roles can be configured via Diagnostics Monitor.
- Diagnostics Monitor.will take the information from IIS logs, trace information and provide it to the Azure Storage. From Azure storage we can easily fetch our record.
- Process is: Capture diagnostics, configure diagnostics monitor and put it in the Azure Storage (Blobs or Tables).


- Supports only SQL Authentication and NOT WINDOWS AUTHENTICATION.
- Cannot create jobs and run in cloud as SQL Server Agent is not present in CLOUD.
- No support for CLR.
- Only core DB Engine level features are present.
- No backup is there in SQL Azure.
- Communication Protocol is TDS.
- Protected by Firewall. Outside networks cannot access SQL Azure.
- Client request will go to load balancer. The load balancer(LB) will balance the request as per the polling mechanism and will pass it on to the Gateway server. The gateway server will then ensure that the request is passed to the appropriate database and request is sent back to the client.

CLIENT ---> Load balancer ---> choose Gateway Server 1/ Server 2/ Server 3 ----> Database
- Distributed transactions or distributed queries are not supported in Windows Azure

App Fabric

- Consists of Service Bus, Access Control, Caching.
- API is provided by caching service to read and write. caching service in turn manages and stores the data in cluster of servers.
- Windows server App fabric consists of Dublin (services for IIS, WCF, etc) and Velocity (caching).
- In Proc Session state will never work.
- Service Bus: Provides with 3 services: Naming, Discovery and Relay Messages.
- When we register a service under service bus we actually register using a namespace.
- Service register itself and makes a request with the service bus. After client connects, he will make actual message call on address register with service bus. Looking at the address of the client, service bus will send request to service. Service will process the request and pass it on to service bus which in turn pass it on to the client.
- Hence service bus doesnt do any processing, it is just used for relaying the messages and nothing else.


No responses found. Be the first to comment...

  • Do not include your name, "with regards" etc in the comment. Write detailed comment, relevant to the topic.
  • No HTML formatting and links to other web sites are allowed.
  • This is a strictly moderated site. Absolutely no spam allowed.
  • Name: