A Memorandum to IT Pros on Cloud Computing

The IT industry is moving fast with cloud computing. And there are fundamental changes on how to approach businesses, which we must grasp to fully appreciate the opportunities presented to us.

Fabric, Not Virtualization

In cloud computing, resources for consumption are via abstractions without the need to reveal the underlying physical complexities. Ultimately all cloud computing artifacts eventually consist of resources categorized into three pools, namely compute, networking, and storage. Compute is the ability to execute code and run instances. Networking is how instances and resources are glued or isolated. And storage is where the resources, configurations, and data are kept. In current state of technologies, one approach is to deliver resources via a form of virtualization. And these three resource pools are abstracted with server virtualization, network virtualization, and storage virtualization, respectively, to collectively form the so-called fabric, as detailed in “Resource Pooling, Virtualization, Fabric, and Cloud.”

Fabric is an abstraction signifying the ability to discover and manage datacenter resources. Sometimes we refer the owner of fabric as a fabric controller which is essentially a datacenter management solution and manages all datacenter physical and virtual resources, With fabric, a server is delivered with a virtual machine (VM), an IP address space can be logically defined through a virtual network layer, and a disk drive appearing with a massive and continuous storage space is in fact an aggregate of the storage provided by just a bunch of disks. Virtualization is an essential building block of cloud computing. We must however go beyond virtualization and envision “fabric” as the architectural layer of abstraction. 

A critical decision in transforming into cloud computing is to as  early as possible establish a holistic approach of fabric management, i.e. deploying a system management solution to provide a common and comprehensive platform for integrating, managing, and operating the three resource pools. This management solution is to strategically form the fabric such that datacenter resources regardless physical or virtualized, deployed on premises or off premises are all discoverable and manageable in a transparent fashion.

Service Architecture, Not VMs 

Many may consider IaaS is about deploying VMs. In cloud computing, an IaaS deployment is nevertheless not just about individual VMs. Modern computing models employ distributed computing with multiple machine tiers while each tier may have multiple VM instances taking incoming requests or processing data. A typical example is a three-tier web application including a frontend, mid-tier, and backend, which maintains multiple frontend instances for load-balancing and multiple backend instances for high-availability of data. And an application is functional only when all three tiers are considered and operated as a whole. Although there are times, perhaps an application architecture is formed with a single machine tier, i.e. one machine instance constitutes an application instance, and operating directly on a VM is equivalent to that on the service. We must however manage the deployment as a service architecture deployment and not as an individual VM deployment.

A service in cloud computing is an application instance, a security boundary, and a management entity. One will deploy a service, start and stop a service, scale a service, upgrade a service. Service from an operations point of view is a set of VMs collectively maintaining an application architecture, run-time environment, and a running instance. No, cloud computing is not just about deploying VMs, since cloud has no concept on individual VMs. it is about the ability to deploy an application architecture followed by configuring target application run-time environment before finally installing and running an application. It is about a service, i.e. an application. And IaaS is about the ability to deploy a service architecture and not individual VMs.

Services, Not Servers

A similar concept to a service architecture vs. VMs is services vs. servers. Here a server is the server OS instance running in a deployed VM. “Service” is operationally a set of servers which forms a service, or an application, architecture. In the context of cloud computing, a service carries a set of attributes, five to be specific as defined in NIST SP 800-145 and summarized in the 5-3-2 Principle of Cloud Computing. Deploying a server (or a VM) and deploying a service denote very different capabilities. Deploying ten VMs is a process of placing ten individual servers, and it suggests little on the scope, relationship, scalability, and management of the ten servers. At the same time, deploying ten instances of a service denotes there is one service definition and with ten instantiations. The significance of the ten service instances is that since all instances are based on a the same service definition, there is an opportunity to optimize business objectives via “service” management. An example is to employ upgrade domains to eliminate downtime during application upgrade.

A service is also how cloud computing is delivered and consumed.  IaaS, PaaS, and SaaS all ended with the term, service, is a clear indication on how significant a service plays. It is “the” way in cloud computing to deliver resource for consumption. If it is not delivered as a servicer, it is not cloud.

From a customer’s point of view, a service (i.e. an application) is what is consumed. Therefore IT pros should pay attention to what is running within a server and not just the server itself. Form a system management viewpoint, what matters is the ability to look into a server instance and drill down to application level, and gain insights of application usage and health. For instance, for a database application what is critical to know and respond to is the health of databases and not just the state of the server which hosts the database application.

So for IT pros, cloud computing is more than just how a server is automatically configures and deployed, it is how the application running in the server instance is defined, constructed, deployed, and managed including fault domain and upgrade domain, availability, geo-redundancy, SLA, pricing, costs, cross-site recovery, etc.

Hybrid, Not On-Premises

With virtualization in place, enterprise IT can accelerate cloud computing adoption by hybrid deployment scenarios. Here a hybrid cloud is a private cloud with a cross-premises deployment. For example an on-premises private cloud with some off-premises resources is a form of hybrid cloud, and vice versa. A hybrid cloud based on an on-premises private cloud offers an opportunity for keeping sensitive information on premises while taking advantages of the flexibility and readiness that a 3rd-party cloud service provider can provide to host non-sensitive data. An on-premises private cloud solution is a stepping stone, the ability to define, deploy, and manage a hybrid cloud is where IT needs to be. 

The idea of a hybrid cloud surfaces an immediate challenge: how to enable a user to self-serve resources in a cross-premises deployment. Self-servicing is an essential characteristic in cloud computing and plays a crucial role in fundamentally minimizing training and support cost while continually promoting resource consumption. For a hybrid IT environment, there are strategically important considerations including consistent user experience with on-premises and off-premises deployments, SSO maturity and federated identity solutions, a manageable delegation model, and inter-op capabilities with 3rd-party vendors. To ensure IT agility, a management platform to manage resources not just physical and virtualized, but also those deployed to a private cloud, a public cloud, or a hybrid cloud is increasingly critical.

Closing Thoughts

Transitioning into cloud computing platform is critical for enterprise IT to compete in the emerging economy which is driven by emotions and current events and intensified by social media. IT should institute a comprehensive management solution while the first opportunity arises to facilitate and converge fabric construction with cloud computing methodology. Keep staying focused on constructing, deploying, and managing:

  • Not virtualization, but fabric
  • Not VMs, but a service architecture
  • Not servers, but service instances
  • Not on-premises, but hybrid deployment scenarios

For enterprise IT, the determining factor of a successful transformation is the ability to continue managing not only what has been established, but what is emerging; not only physical and virtualized, but those deployed to private, public, and hybrid clouds; not only from one vendor’s solution platform, but vSphere, Hyper-V, Citrix and beyond.


Resource Pooling, Virtualization, Fabric, and Cloud

One of the five essential attributes of cloud computing (ref. The 5-3-2 Principle of Cloud Computing) is resource pooling which is an important differentiator separating the thought process of traditional IT from that of a service-based, cloud computing approach.

Resource pooling in the context of cloud computing and from a service provider’s viewpoint denotes a set of strategies for standardizing, automating, and optimizing resources. For a user, resource pooling institutes an abstraction for presenting and consuming resources in a consistent and transparent fashion.

This article presents key concepts derived from resource pooling as the following:

  • Resource Pools
  • Virtualization in the Context of Cloud Computing
  • Standardization, Automation, and Optimization
  • Fabric
  • Cloud
  • Closing Thoughts

Resource Pools

Ultimately data center resources can be logically placed into three categories. They are: compute, networks, and storage. For many, this grouping may appear trivial. It is however a foundation upon which cloud computing methodologies are developed, products designed, and solution formulated.


This is a collection of all CPU-related capabilities. Essentially all datacenter physical sand virtual servers, either for supporting or actually running a workload, are all part of this compute pool. Compute pool represents the total capacity for executing code and running instances. The process to construct a compute pool is to first inventory all servers and identify virtualization candidates followed by implementing server virtualization. And it is never too early to introduce a system management solution to facilitate the processes. Which in my view is a strategic investment and a critical component for all cloud initiatives.


The physical and logical artifacts putting in place to connect, segment, and isolate resources from layer 3 and below, etc. are gathered in the network pool. Networking enables resources becoming discoverable and hence possibly manageable. In this age of instant gratification, everything has to be readily available with a relatively short windows of opportunities. This is an economy driven by emotions and current events. The needs to be mobile and connected at the same time are redefining the IT security and system administration boundaries. Which plays a direct and impactful role in user productivity and customer satisfaction. Networking in cloud computing is more than just remote access, but an abstraction empowering thousands users to self-serve and consume resources anytime anywhere with any device. Bring your own device, bring your own network, and consumerization of IT are various expressions of the network and mobility requirements of cloud computing.


This has long been a very specialized and sometimes mysterious part of IT. An enterprise storage solution frequently characterizes as a high cost item with significant financial and technical commitments on specialized hardware, proprietary API and software, a dependency on direct vendor support, etc. In cloud computing, storage solutions are becoming very noticeable since the ability to grow and shrink resource capacities based on demands, i.e. elasticity, demands an enterprise-level, massive, reliable, and resilient storage solution at scale. While enterprise IT is consolidating resources and transforming existing establishments into a cloud computing environment, the ability to leverage existing storage solutions from various vendors and integrate them into an emerging cloud storage solution is a noticeable opportunity for minimizing the cost.

Virtualization in the Context of Cloud Computing

In the last decade, virtualization has proved its values and accelerated the realization of cloud computing. Then, virtualization was mainly server virtualization. Which in an over-simplified description means hosting multiple server instances with the same hardware while each instance runs transparently and in isolation, namely as if each consumes the entire hardware and is the only instance running. Now, with so many new technologies and solutions emerging, customers’ expectations and business requirements have been evolving. And we should validate virtualization in the context of cloud computing to fully address the innovations rapidly changing how IT conducts business and delivers services. As presented below, in the context of clod computing, consumable resources are delivered in some virtualized form. Various virtualization layers collectively construct and form the so-called fabric.

Server Virtualization

The concept of server virtualization remains as: running multiple server instances with the same hardware while each instance runs transparently and in isolation, as if each instance is the only instance running and consuming the entire server hardware.

In addition to virtualizing and consolidating servers, server virtualization also signifies the practices of standardizing server deployment, switching away from physical boxes to VMs. Server virtualization is the abstraction layer for packaging, delivering, and consuming a compute pool.

There are a few important considerations of virtualizing servers. IT needs the ability to identify and manage bare metal such that the entire resource life-cycle management from commencing an employment to the decommissioning of server hardware can be automated. To fundamentally reduce the support and training cost while increasing the productivity, a consistent platform with tools applicable across physical, virtual, on-premises, and off-premises deployments is essential. The last thing IT wants is one set of tools for managing physical resources and another for working on those virtualized; one set of tools for on-premises deployment and another for those deployed to a service provider; one set of tools for infrastructure development and another for configuring applications. The essential goal is one skill set for all, namely one platform for all, one methodology for all, and one set of tools for all. This advantage is obvious when, for example, developing applications and deploying Windows Server 2012 R2 on premises or off premises to Windows Azure. The Active Directory security model can work across sites, System Center can manage resources deployed off premises to Windows Azure, and Visual Studio can publish applications across platforms. IT pros can operate all based on Windows system administration skills. There is minimal operations training needed since all provides a consistent Windows user experience on a common platform and security model.

Network Virtualization

Similar idea of Server Virtualization applies here. Network virtualization is the ability to run multiple networks on the same network infrastructure while each network runs transparently and in isolation, as if each network is the only network running and consuming the entire network hardware.

Conceptually since each network instance is running in isolation, one tenant’s 192.168.x network is not aware of another tenant’s and identical 192.168.x network running with the same network infrastructure. Network virtualization provides the translation between physical network characteristics and the representation of a logical network. Consequently, above the network virtualization layer, various tenants while running in isolation can have identical network configurations. This abstraction essentially substantiates the concept of bringing your own network.

A great example of network virtualization is Windows Azure virtual network. At any given time, there can be multiple Windows Azure subscribers all allocate the same 192.168.x address space and with identical subnet scheme, 192.168.1.x/16, for deploying VMs. Those VMs belonging to one subscriber are however not aware of or visible to these deployed by others, despite the network configuration, IP scheme, and IP address assignments may be all identical. Network virtualization in Windows Azure isolates one subscriber from the others such that each subscriber operates as if the subscription account is the only one employing 192.168.x address space.

Storage Virtualization

I believe this is where the next wave of drastic cost reduction of IT post server virtualization happens. Historically, storage has been a high cost item in IT budget in each and every aspects including hardware, software, staffing, maintenance, SLA, etc. Since the introduction of Windows Server 2012, there is a clear direction where storage virtualization is becoming a commodity and an essential skill for IT pros since storage virtualization is now built into Windows OS. New capabilities like Storage Pool, Hyper-V over SMB, Scale-Out Fire Share, etc. are making storage virtualization part of server administration routines and easily manageable with tools and utilities like PowerShell which many IT professionals are familiar with.

The concept of storage virtualization remains consistent with the idea of logically separating a computing object from the hardware where it is running. Storage virtualization is the ability to integrate multiple and heterogeneous storage devices, aggregate the storage capacities, and present/manage as one logical storage device with a continuous storage space. And it should be apparent that JBOD is a visualization of this concept.

Standardization, Automation, and Optimization

Each of the three resource pools has an abstraction to logically present itself with characteristics and work patterns. A compute pool is a collection of physical hosts and VM instances. A virtualization host runs VMs which carry workloads deployed by service owners and consumed by authorized users. A network pool encompasses network resources including physical devices, logical switches, logical networks, address spaces, and site configurations. Network virtualization can map many identical logical/virtual IP addresses with the same physical NIC, such a service provider can host tenants implementing identical network scheme with the same network hardware without a concern. A storage pool is based on storage virtualization which is a concept of presenting an aggregated storage capacity as one continuous storage space as if provided from one logical storage device.

In other words, the three resource pools are wrapped with server virtualization, network virtualization, and storage virtualization, respectively. Together these three virtualization layers forms the cloud fabric which is presented as an architectural layer with opportunities to standardize, automate, and optimize deployments without the needs to know the physical complexities.


Virtualizing resources decouples the dependency between instances and the underlying hardware. This offers an opportunity to simplify and standardize the logical representation of a resource. For instance, a VM is defined and deployed with a VM template which provides a level of consistency with a standardized configuration. 


Once a VM characteristics are identified and standardized with configurations, we can now generate an instance by providing only instance-based information such as the VM machine name which must be validated at deployment time to prevent duplicated names. With a deployment template, only minimal information at deployment time us needed. Which can significantly simplify the process and facilitate automation. Standardization and automation are essential mechanisms so that a workload can scale on demand, i.e. become elastic, once a threshold is specified from a system management perspective.


Standardization provides a set of common criteria. Automation executes operations based on set criteria with volumes, consistency, and expediency. With standardization and automation, instances can be instantiated with consistency and predictability. In other words, cloud resources can be operated in bulk with consistency and predictability by standardizing configurations and automate operations. The next logical step is then to optimize the usage based on SLA.

Optimization is essentially standardization and automation with intelligence and objectives. The intelligence is why we need to have analytics designed into a cloud solution. With self-servicing, ubiquitous access, and elasticity, technically a cloud resource can be consumed anytime, by any number of users, and with capacities changed on demand. We will need a mechanism to provide us insights of the usage including when it is used, by whom, how much, to what degree, etc. A consumption-based chargeback or show-back model is what the analytics must provide so system management can optimize resources accordingly and timely.

Integrating resource pooling and virtualization concepts into OS has happened since Windows Server 2012 R2 and System Center 2012. Server virtualization, network virtualization, and storage virtualization are now integrated into Windows platform and part of the Server OS.


A significant abstraction in cloud computing this is. Fabric implies the discoverability and manageability. Which denotes the ability to discover, identify, and manage a datacenter resource. Conceptually fabric is an umbrella term encompassing all the datacenter physical and virtualized resources supporting a cloud computing environment. At the same time, a fabric controller represents the system management solution which manages, i.e. owns, fabric.

In cloud architecture, fabric consists the three resource pools: compute, networking, and storage. Compute provides the computing capabilities, executes code, and runs instances. Networking glues the resources based on requirements. And storage is where VMs, configurations, data, and resources are kept. Fabric shields a user from the physical complexities of the three resource pools. All operations are eventually managed by the fabric controller of a datacenter. Above fabric, there are logical views of consumable resources including VMs, virtual networks, and logical storage drives. By deploying VMs, configuring virtual networks, or acquire storage, a user consumes resources. Under fabric, there are virtualization and infrastructure hosts, Active Directory, DNS, clusters, load balancers, address pools, network sites, library shares, storage arrays, topology, racks, cables, etc. all under the fabric controller’s command to collectively form the fabric.

For a service provider, building a cloud computing environment is essentially to establish a fabric controller and construct fabric. Namely institute a comprehensive management solution, build the three resource pools, and integrate server virtualization, network virtualization, and storage virtualization to form fabric. Form a user’s point of view, how and where a resource is physically located is not a concern. The user experience and satisfaction are much based on the accessibility, readiness, and scalability of requested resources and fulfillment of SLA.


This is a well-defined term by NIST SP 800-145 and the 5-3-2 Principle of Cloud Computing. We need to be very clear on: what a cloud must exhibit (the five essential attributes), how to consume it (with SaaS, PaaS, or IaaS), and the model a service is deployed in (like private cloud, public cloud, and hybrid cloud). Cloud is a concept, a state, a set of capabilities such that the capacity of a requested resource can be delivered as a service, i.e. available on demand.

The architecture of a cloud computing environment is presented with three resource pools: compute, networks, and storage. Each is abstraction provided by a virtualization layer. Server virtualization presents a compute pool with VMs which supplies the computing power to execute code and run instances. Network virtualization offers a network pool and is the mechanism to allow multiple tenants with identical network configurations on the same virtualization hosts while connecting, segmenting, isolating network traffic with virtual NICs, logical switches, address space, network sites, IP pools, etc. Storage virtualization provides a logical storage device with the capacity appearing continuous by aggregating the capacity of a pool of storage devices behind the scene. The three resource pools together form an abstraction, namely fabric, such that despite the underlying physical infrastructure may be intricate, the user experience above fabric is presented with a logical and consistent fashion. Deploying a VM, configuring a virtual network, or acquiring storage is transparent with virtualization regardless where the VM actually resides, how the virtual network is physically wired, or what devices are included in the aggregate the requested storage.

Closing Thoughts

Cloud is an all consumer-focused approach. It is about enabling a customer to consume resources on demand and with scale. And perhaps more significant than the need to increase capacity on demand is the ability to release resources when no longer required. Cloud is not about products and technologies. Cloud is about standardizing, automating, and optimizing the consumption of resources and ultimately strengthening the bottom line.

Why Private Cloud First

Some IT decision makers may wonder, I have already virtualized my datacenter and am running a highly virtualized IT environment, do I still need a private cloud? If so, why?

The answer is a definitive YES, and the reason is straightforward. The plain truth is that virtualization is no private cloud, and a private cloud goes far beyond virtualization. (Ref 1, 2)

Virtualization Is No Private Cloud

Technically, virtualization is signified by the concept of “isolation.” By which a running instance is with the notion that the instance consumes the entire hardware despite the fact that multiple instances may be running at the same time with the same hosting environment. A well understood example is server virtualization where multiple server instances running on the same hardware while each instance runs as if it possesses the entire host machine.

A private cloud on the other hand is a cloud which abides the 5-3-2 Principle or NIST SP 800-145 which the de facto definition of cloud computing. In other words, a private cloud as illustrated above must exhibit the attributes like elasticity, resource pooling, self-service model, etc. of cloud computing and be delivered in a particular fashion. Virtualization nonetheless does not hold, for instance, any of the four attributes as a technical requirement. Virtualization is about isolating and virtualizing resources, while how a virtualized resource is allocated, delivered, or presented is not particularly specified. At the same time, cloud computing or a private cloud, is visualized much differently. The servicing, accessibility, readiness, and elasticity of all consumable resources in cloud computing are conceptually defined and technically required for being delivered as “services.”

Essence of Cloud Computing

The service concept is a center piece of cloud computing. A cloud resource is to be consumed as a service. This is why these terms, IaaS, PaaS, SaaS, ITaaS, and XaaS (everything and anything as a service), are frequently heard in a cloud discussion. And they all are delivered as a service. A service is what must be presented to and experienced by a cloud user. So, what is a service?

A service can be presented and implemented in various ways like forming a web service with a block of code, for example. However in the context of cloud computing, a service can be captured by three words, capacity on demand. Capacity here is associated with an examined object such as cpu, network connections, or storage. One-demand denotes the anytime readiness with any network and any device accessibility. It is a state that previously takes years and years of IT disciplines and best practices to possibly achieve with a traditional infrastructure-focused approach, while cloud computing makes “service” a basic deliver model and demand all consumable resources including infrastructure, platform, and software to be presented as services. Consequently, replacing the term, service, with “capacity of demand” or simply “on demand’ brings clarity and gives substance to any discussion of cloud computing.

Hence, IaaS, infrastructure as a service, is to construct infrastructure on demand. Namely one can provision infrastructure, i.e. deploying a set of virtual machines (since all consumable resources in cloud computing are virtualized) to together form the infrastructure for delivering a target application based on needs. PaaS means platform as a service, or a runtime environment available on demand. Notice that a target runtime environment is for running an intended application. Since the runtime is available on demand, an application deployed to the runtime will then become available on demand, which is essentially SaaS, or software available on demand or as a service. There is a clear logical progression among IaaS, PaaS, and SaaS.

So what is cloud exactly?

Cloud, as I define it here, is a concept, a state, a set of capabilities such that a targeted business capacity is available on demand. And on-demand denotes a self-servicing model with anytime readiness, on any network and with any device accessibility. Cloud is certainly not a particular implementation since the same state can be achieved in various implementations as technologies advancing and methodologies evolving.

Logically, building a private cloud is the post-virtualization step to continue transforming IT into the next generation of computing with cloud-based deliveries. The following schematic depicts a vision of transforming a datacenter to a service-centric cloud delivery model.

Once resources have been virtualized with Hyper-V, System Center builds and transforms existing establishments into an on-premises private cloud environment based on IaaS. Windows Azure then provides a computing platform with both IaaS and PaaS solutions for extending an on-premise private cloud beyond corporate boundaries and into a global setting with resources deployed off premises. This hybrid deployment scenario is emerging as the next generation IT computing model.

To Cloud or Not to Cloud, That Is Not the Question

Comparing apples to apples, there is few reason that a business does not prefer cloud computing over traditional IT. Why one would not want to acquire the ability to adjust business capacity based on needs. Therefore, to cloud or not to cloud is not the question. Nor is security the issue. In most cases, cloud is likely to be more secure managed by a team of cloud security professionals in a service provider’s datacenter, than implemented by IT generalists wearing multiple hats while administering an IT shop. Cloud is to acquire the on-demand capability, and for certain verticals, the question is more about regulatory compliance since the cost reduction and increasing servicing capabilities are very much understood. Above all it is about a business owner’s understanding and comfort level with cloud.

IT industry nevertheless does not wait, nor can simply maintain status quo. Why private cloud? The pressure to produce more with less, and the need to instantaneously become ready and respond to a market opportunity are not for pursuing excellence, but a matter of survival in today’s economic climate with ever increasing user expectations and driven by current events and emotions. One will find out that a private cloud is a vehicle to facilitate and transform IT with increasing productivity and reduced TCO over time as discussed in the Building a Private Cloud blog post series. IT needs cloud computing to shorten go-to-market, to promote consumption, to accelerate product adoption, to change the dynamics by offering better, quicker, and more with less. And for enterprise IT, it is critical to first convert existing on-premises deployments into a cloud setting, and a private cloud solution is a strategic step and a logical approach for enterprise IT to become cloud friendly, cloud enabled, and cloud ready..

Azure Infrastructure Services with PowerShell Quick Start Kit (http://aka.ms/QSK) Release Note


This quick start kit is available for download at http://aka.ms/QSK for self-studies of Microsoft Azure Infrastructure Services and Microsoft Azure PowerShell. It deploys a simple, yet well-structured, Microsoft Azure Infrastructure Services instance including: 1072.qsk[1]

  • Affinity Group
  • Storage Account
  • Cloud Service
  • VMs with attached data disk
  • Availability Set
  • Load-Balancer

Additional information of Windows Azure IaaS deployment methodology is available at:

The conceptual model of a Windows Azure Infrastructure Services deployment with QSK is showed as below:


Notice since the storage account is auto-created with PowerShell in QSK, by default Windows Azure optionally enables geo-replication of a storage account. Therefore the synchronization may take a little bit longer for creating or deleting a VM and its attached disks.

For each deployment, the RDP files of each deployed VM is also automatically downloaded to a designated local folder. Namely a VM user can access a deployed Windows Azure VM using the RDP file and VM user credentials, and without the need to log in Windows Azure management portal or acquire the Windows Azure subscription information. Further, accessing a deployed Windows Azure VM will be based on a self-signed certificate, if no PKI has been pre-configured for the VM.

QSK uses a user-specified prefix and a timestamp as a tag to eliminate any possible naming conflict within Windows Azure. This tag also makes resources in one deployment unique and easily identifiable by matching the tag. Hence, a user can execute the script multiple times to deploy multiple services and consume resources within what the subscription allows and without a naming conflict.

The following are additional resources and the history of a sample PowerShell session where I deployed two services by executing the script twice.


In Windows Azure Management Portal, the following shows what were deployed.









And the RDP files of deployed VMs were also downloaded to the local SQL folder as shown here.qsk.session.10.local.folder

To remove all deployed resources, the 4-step clean up routine as included in the script was run in sequence and one step at a time.



Azure IaaS Deployment Methodology with PowerShell (Part 2 of 2): Processing NetworkConfig.xml File


In Part One, I showed you important artifacts in Windows Azure IaaS. Why they are needed and the sequence to create and deploy them. To better manage all resources in a deployment, my best practice is to tag all deployed. I normally create a tag based on the current timestamp and add the tag as a prefix to all resources associated with a deployment.

Below as an example is a function I wrote to process and add a prefix to the Affinity Groups appear in a NetworkConfig.xml file which defines the virtual network configuration of a Windows Azure subscription. An Affinity Group is an artifact to be created and associated with a virtual network such that all VMs deployed to the virtual network will be in the region specified by the Affinity Group. I use this function as a template for processing a node in NetworkConfig.xml or other xml files.


To test this function, you can simply use the NetworkConfig.xml you downloaded form Part One or will need to first export the NetworkConfig.xml file from an intended Windows Azure subscription, and provide it as a parameter of this function which you can download from here.

The Tag should be something which once is added to a resource name will make the resource identifiable with a deployment. This will help and drastically simplify, for example, decommissioning resources of a deployment where by removing all resources with the same Tag. Particularly for demos, pilots, test runs, etc. it becomes very easy to process/delete a deployment as a whole. A sample call of the function while putting a target NetworkConfig.xml file in the root of c drive and using a timestamp as the Tag is like:

Tag_AffinityGroup –theNetcfgFile ‘c:\myNetworkConfig.xml’ –Tag (get-date –format ‘mmss’)

Here the Tag is a 4-byte string indicating the current minute and second. Since this Tag is to prefix an AffinityGroup name which in Windows Azure has a limit of 15 characters, the Tag can not be too long in size. The following shows a sample result that after calling the function, the Affinity Group is prefixed with a 4-character tag.


In Windows Azure Infrastructure Services (IaaS) Quick Start Kit (QSK), I will provide a routine for cleaning up deployed Windows Azure IaaS resources based on a specified prefix or pattern.

Windows Azure Infrastructure Services Deployment Methodology with PowerShell (Part 1 of 2)


[Part 2]

This blog post series is to examine key Windows Azure Infrastructure Services, (i.e. IaaS) concepts and deployment methodology. Part One presents the artifacts which together constitutes an IaaS deployment by walking through a scenario to configure a virtual network and deploy a VM to a target virtual subnets. Upcoming posts will introduce the considerations for automating a Windows Azure IaaS deployment with PowerShell. The content assumes a reader has and does not cover basic operations of PowerShell.

The samples presented in this post are for demonstration. A similar PowerShell script is available at http://aka.ms/QSK which is easier to run and without the dependency of virtual network.

Cloud Computing and IaaS Concept


  • To carry out the labs requires a Windows Azure subscription to deploy VMs. A free trial subscription is available at http://aka.ms/R2. Click the dropdown list to select “Windows Server 2012 R2 Datacenter on Windows Azure.”
  • The PowerShell script examples shown in this post require Windows Azure PowerShell Cmdlets configured. Follow the instructions at http://aka.ms/AzureCmdlets to set up Windows Azure PowerShell Cmdlets and establish the connectivity between Windows Azure and the local device.

Windows Azure IaaS Artifacts and Deployment Methodology

There are a number of artifacts in Windows Azure IaaS to be considered for an deployment. The follow highlight the significance and presents a recommended sequence of creating and configuring them for a deployment. Not discussed in this post is how to decommission a deployment which should follow the sequence in a reverse order to remove the resources.

Affinity Group

This is a logical construct associated with a geo-region and defined at the subscription level. An Affinity Group is to keep specified services running in the same specified data center to minimize the latency, potentially lower the costs while achieving optimal performance. In Windows Azure Management Portal, go to SETTINGS workspace, as shown below, to configure Affinity Groups.


An Affinity Group has a fundamental impact on the performance of a deployment. For instance, associating an Affinity Group with a virtual network will ensure that all VM instances deployed to the virtual network are placed in the same data center of the region specified in the affinity group. Meanwhile, associating a storage account (which is where the VHDs are kept) with an Affinity Group will ensure that all resources using the same storage account are stored in the same data center in the region specified in the Affinity Group.

In the above examples, both a virtual network and a storage account are linked to the same Affinity Group. Which ensures both the VM instances deployed to the virtual network and the VHDs which the VM data are stored are in the same data center to optimize the performance.

image An Affinity Group is a geo-location setting with performance implication and should be first planned in a deployment effort. Windows Azure PowerShell module provide four cmdlets relevant to managing an Affinity Group as shown on the left.

In a deployment project, create an Affinity Group first so all subsequently configurations and placements can reference the Affinity Group throughout the lifecycle. The next step is to ensure all deployment resources will be stored in the same data center of a region specified by the Affinity Group. When deleting an Affinity Group, must first delete the associated storage accounts.

Storage Account

A storage account provides the access to Windows Azure storage within a geographic region. There are three types of storage: Blob, Queue, and Table in Windows Azure. For Windows Azure IaaS, a VM must be stored in Page Blob which has a maximal size of 1 TB. By default, geographically redundant storage (GRS) is optional and enabled at a storage account creation time. GRS replicates data to a data center in a secondary location of the same geo-region. When turning off geo-replication, a storage account then becomes locally redundant storage (LRS) which stores data in a single data center location. 

Windows Azure creates two 512-bit management keys at a storage account creation time. An application will use one of the two keys to access the storage account. The monitoring and logging of a storage account will need to be enabled before activities are monitored and data is collected. Only then the charts on the dashboard and monitor page will present usage information . The following is a screen capture of the user experience of operating on a storage account with Windows Azure Management Portal.


image On the right are the four Windows Azure PowerShell cmdlets frequently used in managing a storage account. Notice before deleting a storage account can be removed, first delete all VMs instances and disks deployed with this storage account.

Cloud Service

This is a logical container presented as a single URL to include application code and configurations, while together form a cloud service or simply a service. For Windows Azure IaaS, each VM is deployed to a service, however a service can contain multiple VMs. Placing multiple VMs into a service makes these VMs connected and visible to one another. Considering a multi-tier application, a cloud service can therefore be employed to host multiple tiers of VMs which form the application architecture or architectural component, while manage all VMs which are connected as one entity. This concept is revisited when examining VM deployment later in this post.

Notice when deploying a VM, one can choose to have Windows Azure create a cloud service which by default inherits the FQDN of the VM as the service name, or add the VM into an existing service which connects all VMs in the same service to form a target application/service architecture. One particular is worth mentioning that when there is only one VM in a cloud service, this cloud service will not be listed in CLOUD SERVICES workspace of Windows Azure Management Portal. A cloud service becomes visible in CLOUD SERVICES workspace when the service contains either no VM at all, or two or more VMs. And when deleting the only VM in a service, it takes a moment for the service to surface in CLOUD SERVICES workspace due to the synchronization of al the bookkeeping within Windows Azure.

The following screen capture depicts an application or service architecture formed with four cloud services while the frontend service is with two VM instances configured in separate upgrade and fault domains to minimize downtime.

imageimage From operational point of view, for better housekeeping and to avoid phantom services, i.e. those services with no resource deployment and no longer referenced, do delete a service after removing the last VM. There are also programmatic approach to manage a cloud service using Windows Azure PowerShell cmdlets including those shown on the right.

Two important artifacts of cloud computing are the so-called Fault Domain and Upgrade Domain. A fault domain is a single point of failure of hardware, while an upgrade domain is a logical grouping where an application is upgraded one upgrade domain at a time. Additional information is available at http://aka.ms/FaultDomain. Both will minimize, if not eliminate, the down time due to hardware outage or application upgrade. When a service are deployed with more than one VM instance, the SLA become effective and Windows Azure IaaS automatically configure fault domains and upgrade domains to ensure no single point of failure and minimize possible downtime. In a Windows Azure PaaS deployment, using service definition (.csdef) file a cloud service deployment can have up to twenty upgrade domains, while if not explicitly specified, a cloud service is defaulted to five upgrade domains.

With Affinity Groups, storage accounts, and services in place, the architectural components are in place and it is now to decide which servers goes where and how these components are connected, i.e. design the network topology which brings the process to deploying a virtual network.

Virtual Network

Windows Azure employs a configuration file, NetworkConfig.xml, to define the settings of a virtual network. A Windows Azure virtual network is essentially a customized set of network configurations implemented on demand at a data center of a geo-region explicitly specified or implied by an Affinity group. A virtual network is as the name suggested virtual and this network virtualization is isolated at a subscription level.

One productive way to acquire a NetworkConfig.xml file is to first in Windows Azure Management Portal interactively create a sample virtual network with Windows Azure Management Portal followed by exporting the configurations as shown below.


This NetworkConfig.xml file can be edited offline and later either interactively imported while creating a new virtual network or use PowerShell cmdlets to upload into an intended Windows Azure subscription.  A virtual network configuration encompasses a  name, DNS servers, cross-site connectivity, address space, subnet, name and masks, and gateway information. A sample NetworkConfig.xml without gateway connectivity is shown below:


Notice in the above configuration, the DNS server, foodns, is assigned with The DNS settings are to be finalized at virtual network creation time, while no VM has been deployed yet. Here the address,, is specified since a DNS is planned to be the first VM deployed to 10.2.1.x subnet. Note that for a brand new subnet, Windows Azure IaaS reserves the first three IP addresses and is the first IP address valuable for a VM deployment. This behavior is consistent with all virtual subnets. For instance, the first IP address available for a VM deployment in 192.168.x.x will be 192.168.x.4 since the first three applicable IP addresses are reserved by Windows Azure. The following screen capture illustrates a virtual network design based on the address, with four subnets while in each subnet the first available IP address for deployment is 10.2.x.4.


Prior to any VM deployed to a virtual network, the associated DNS settings are changeable. Once a VM has been deployed to a virtual network, the DNS settings of the virtual network are no longer editable. Should there be a change needed the DNS settings, the virtual network will need to be recreated. Much planning does need to put in before deploying a virtual network. This is just like deploying a physical DNS, once in production with resources deployed, it can be very costly, if feasible at all, to change the DNS’ IP address.

The virtual network shown above employs the address space,, and is with 4 configured subnets: infra, data, collab, and service. This network is a simple branch office or business unit environment where: infra subnet holds infrastructure servers like domain controllers, DNS, DHCP Servers, Update Servers, etc.; data subnet hosts data stores like Microsoft SQL Servers; collab subnet is for placing collaboration servers like SharePoint; and service subnet runs the frontend IIS servers to receive and process incoming HTTP requests. A virtual network with various servers (i.e. VMs) deployed into target subnets and grouped into services can be automated using Windows Azure PowerShell. The following screen capture illustrates a partial deployment of an AD forest to a virtual network with six servers deployed into four target subnets. A Windows Azure PowerShell script carries out the deployment from zero to all in about thirty five minutes. An upcoming post will present the script used for this deployment.


Importing a NetworkConfig.xml and managing virtual network are fairly easy by employing the following Windows Azure PowerShell cmdlets below. Note that the Remove-AzureVnetConfig will delete the configuration from the current Windows Azure subscription.

imageA user can interactively or programmatically construct  a virtual network and deploy VMs to target subnets in minutes without the need to pull a single cable, nor be concerned with any server hardware. All needed is a browser, Internet connectivity, and a Windows Azure subscription. The requirements and time needed for an infrastructure deployment have been minimized to a unforeseen level by Windows Azure IaaS, while the capabilities have become global and exponential with cloud computing.

Windows Azure Virtual Network is a powerful feature and a crucial skill to have. For training, prototyping, or short-term networking needs, Windows Azure virtual networking offers tremendous capability and flexibility. For businesses of all sizes, branch office, and business units, Windows Azure IaaS and site-to-site or point-to-site connectivity introduces many new scenarios and exciting opportunities to extend, integrate, and transform an on-premises deployment into a hybrid cloud scenario. There is much information readily available in Windows Azure IaaS documentation and is not repeated here. IT professionals however must recognize that there is no other way to master Windows Azure IaaS without practicing, practicing, and practicing more on creating a virtual network, deploy VMs, and build an application architecture.

Virtual Machine

In this post-virtualization era, a VM has been come a baseline for constructing infrastructure. For deploying VMs, Windows Azure IaaS supports both Microsoft Operating Systems and non-Microsoft ones. The VM image gallery in Windows Azure Management Portal, as shown below, includes the latest releases and previews of  Windows Server, SQL Server, SharePoint, BizTalk Server, and many non-Microsoft workload like openSUSE, SUSE Linux, Ubuntu, OpenLogic, etc.


The creation of a VM with Windows Azure IaaS is a rather straightforward process and http://aka.ms/AzureVM outlines the tasks and operations. In general, a VM can be deployed in a matter of minutes. Deploying individual servers from hardware requirements to a running VM instance in minutes is now a reality and will soon become a new normal of IT server deployment.

One interesting observation of a Windows Azure IaaS deployment is that multiple VMs can be included in the same cloud service. This offers an opportunity to logically group specific VMs to form an application architectural component or architecture itself. For instance, a three-tier web application architecture like frontend, mid-tier, and backend can be all included in a cloud service such that all VMs are connected via the service to deliver the application. Alternatively each tier can be a service such that the frontend VMs are in a frontend service, mid-tier VMs are placed in a mid-tier service, and the backend are organized into a backend service while all three services collectively form the application/service architecture. The following schematic illustrates this concept.


imageOn the right, this is a list of Windows Azure PowerShell cmdlets relevant to operating on VMs. Some perhaps need more practices are New-AzureVMConfig and Add-AzureProvisioningConfig. The former is for creating a VM configuration object which can be part of a new deployment or used for adding a VM to an existing deployment, while the latter provisions a configuration of a VM. A the end of this post, a Windows Azure PowerShell sample script is included to demonstrate the usage of these two statements.

From training, assessment, prototyping, development, to production, Windows Azure IaaS can shorten the go-to-market of an infrastructure deployment literally from months and weeks into hours and minutes. An application architecture can now be deployed as a service. And infrastructure deployment is becoming a facilitator to fast-forward an infrastructure project.

Availability Set

This is an essential part of a cloud deployment. An Availability Set is a logical group to signify the need for Windows Azure to prevent a single point of failure for all VMs included in the set. A single point of failure of hardware is the so-called Fault Domain. In Windows Azure a Fault Domain is a server rack. Those VMs instances added into an Availability Set in essence demand Windows Azure to deploy those instances to at least two or more fault domains, i.e. two or more server racks. Windows Azure IaaS makes configuring an Availability Set a very simple interactive mouse-clicking process while configuring a VM or after a deployment. The following is a screen capture depicting the user experience to configure a new service and an Availability Set during an interactive session of a VM deployment.


An Availability Set is an effective tool to ensure service availability. For instance, two Domain Controllers, DC1 and DC2, are paired as a backup to each other. At least one of the two servers should always be available for user authentications. Placing DC1 and DC2 into an Availability Set will guarantee there is no single point of failure of hardware between DC1 and DC2.

With Windows Azure PowerShell module, an Availability Set can be specified as part of the VM configuration as shown in the example at the end of this post. To create an Availability Set after a VM deployment, one can use Set-AzureAvailabilitySet.

Load Balancer

imageTypically a production web application will place a load balancer before the frontend web servers to distribute the incoming traffic for better server utilization and more predictable performance. In a traditional deployment, adding,  maintaining, and scaling a load balancer is a significant part of a web application since it adds additional hardware, software, complexities, security, maintenance, vendor dependency, etc. besides just costs.

Windows Azure IaaS offers a basic load balancer with a round robin algorithm. The process to create a load balancer is to first specify/open a standalone endpoint, i.e. a port and mark the checkbox to also create a load-balanced set with this endpoint of a VM followed by configuring the load-balanced set. The above right shows Windows Azure PowerShell cmdlets for adding a load-balanced set which is part of the operations of adding an endpoint. While shown below is the user experience to configure a load-balanced set.


Later when configuring additional VMs to be added into the load-balanced set, for each VM add an endpoint and specify this endpoint to be added to an existing load-balanced set.


And the result as shown below is a load-balanced set created in minutes by a few mouse-clicks. The process and operations are almost too simple and quick to believe.


Windows Azure PowerShell Skeleton for IaaS Deployment

The following is a sample script to demonstrate the methodology of deploy a Windows Azure IaaS VM. The script is supplemented with the NetworkConfig.xml shown earlier in this post. Before executing the script, I first established connectivity between My PowerShell ISE session and Windows Azure by following the instructions at http://aka.ms/AzureCmdlets.

Of the script, the first 19 lines are simply to assign values to variables. I separated out all variables from the main program to make it easier to test what-if scenarios. The main program starts from line 21 to line 51 following the methodology outlined in this post from creating an Affinity Group, a storage account, a service, to configuring and deploying a VM from line 35 to line 51. The VM configurations include an Availability Set at line 38 and a Load-Balanced Set at line 48. And finally, at line 53 the RDP file of the VM is also downloaded for accessing the VM remotely.


An execution of the above Windows Azure PowerShell script deployed the following resources. And notice the script configures and deploys a VM with dependency of the virtual network defined in the NetworkConfig.xml file. This script is a skeleton for demonstrating the deployment methodology.