Windows Azure Terminology in Simple Words
Every time I start working on new technology I get amazed how many new terms we can invent as humans. From one side this is good because it demonstrates how easily we can make progress, but from other it can be an obstacle for somebody who wants to get onboard fast. In this post I will try to explain some of the Windows Azure terminology the way I understand it.
Windows Azure Services
Without going into details about the internals of Windows Azure I need to say that there are two main services that every developer needs to be aware of: Compute and Storage.
Compute is the computational part of Windows Azure, and very often it is referred to as Hosted Service. Windows Azure Fabric is the component that manages the Hosted Services - David has a very nice post explaining how this works in the datacenter (see David L's Blog - Windows Azure - What Happens in the Data Center?). Fabric takes care of the deployment of your service, restarting it if something goes wrong, managing the resources available to it etc. From now on I will refer to the computational part of Windows Azure as the Hosted Service.
Windows Azure Storage is the second service available for developers. It is also referred to as Storage Account. Storage consists of three main parts:
- Blob Service (or just Blob) – used to store and retrieve large amounts of binary or text data
- Queuing Service (or just Queue) – used to store and retrieve messages
- Table Service (or just Table) – used to store structured data (however you should not confuse it with SQL Azure)
As of last week Storage provides nice features like CDN and Custom Domain association. From now on I will refer to the Storage Service as Storage Account or just Storage.
Both Fabric and Storage are simulated in the development environment available as part of the Windows Azure SDK (also called Development Fabric and Development Storage).
Looking at Compute (i.e. Fabric) and Storage as components of Windows Azure is just one way to abstract the system and by no mean the only way or the way Windows Azure team does it. This is just a simplification I decided to use to make my life easier when I look at Windows Azure from developer point of view.
More about Hosted Services
The Hosted Service is the actual application you deploy on Windows Azure. Every Hosted Service in Windows Azure can have Web Role and Worker Role.
The Web Role is intended to provide the front end for communication outside Windows Azure, while the Worker Role’s is intended for background processing.
It is very important to understand that there are certain limits of the number of roles in a Hosted Service. The CTP (Community Technology Preview) program allows developers to have up to 5 roles in a Hosted Service; only one Hosted Service and two Storage Accounts are allowed for CTP users. Currently every Hosted Service is deployed on a separate VM (Virtual Machine).
As a developer you can mix and match the types of the roles as you want as long as you don’t exceed the limits. Going forward those limits will change in accordance to the subscription program Windows Azure team will introduce.
VIP-Swap and In-Place Upgrade
One very important term is the VIP (Virtual IP) address – this is the publicly accessible IP address used to access your Hosted Service; or this is the IP address of the Load Balancer in front of your service. Windows Azure provides the concept of VIP-Swap where you have two services with their own VIPs (and corresponding domain name), and you can swap those so that the first service uses the VIP of the second one, and the second service uses the VIP of the first one.
This is quite useful if you want to have no downtime update for your application. You can use the Staging Environment of your Hosted Service to deploy your new bits, and test those, and once you are ready you can swap it with the Production Environment. You can keep the production bits for some time in case you need to roll back your changes.
Of course more advanced technique to do upgrades is the In-Place Upgrade Windows Azure offers (In-Place Upgrade is explained very well in the Windows Azure Documentation). In-Place Upgrade uses the concept of Upgrade Domains where instances of the roles are separated in two groups, and those groups are upgraded in a sequence. In-Place Upgrade provides also more flexibility and control from developer’s point of view.
Clarifying the terms above helped me get better understanding of the Windows Azure platform. Going forward I will try to explain every new term and clarify its meaning and intended use.