Many organizations are considering a move to the cloud. But when you start investigating the possibilities, you’ll quickly discover that there are many ways to accomplish that and many decisions you need to make. Public cloud? Private cloud? Hybrid cloud?

Hybrid, wherein part of the infrastructure runs on premises and part is hosted in the cloud, is a viable option — and it just got easier.

1: Windows Azure Infrastructure Services enables hybrid IT

Microsoft has gotten serious about the infrastructure-as-a-service (IaaS) market, challenging Amazon Web Services (AWS) with a commitment to match Amazon’s pricing. Windows Azure has been around for five years, and the company has had time to build a high performance service offering that it calls “one of the most thoroughly tested products we’re ever had.”

Windows Azure Infrastructure Services (Azure Virtual Machines and Virtual Network) was released April 16, and you can use it to create a hybrid cloud that works for your organization. Here are some considerations to keep in mind when deploying this hybrid model.

2: Azure virtual machines run in the cloud

You can run Azure virtual machines (VMs) in the Azure Infrastructure Services public cloud. The VMs run on Hyper-V and are stored as .vhd files. You can create new VMs from templates provided by the service or create them yourself on your own premises and upload the .vhd files to Azure.

You can connect your on-premises network to your virtual machines that are running in the public cloud as part of a hybrid IT model.

3: You can “have it your way” with Azure VMs

Microsoft’s new service is flexible, allowing you to choose the right hardware configuration (small, medium, large, or extra large) for each VM.

You can create a custom VM running Windows Server or a choice of other platforms, including Windows Server and Linux, which you pick from the platform image gallery. There is also a Quick Create feature that makes it easy to create an Azure VM by entering basic information (DNS name, platform image, password, and location).

4: Azure Virtual Networks extend your on-premises network

You can connect your internal network to an Azure Virtual Network via an IPsec site-to-site VPN through an approved VPN device and treat it like another subnet on your network. You can have multiple Azure Virtual Networks to which your on-premises network is connected from a single point of presence. However, it doesn’t work the other way around — that is, you can’t connect the same Azure Virtual Network to multiple on-premises networks. You can’t route connections between different Azure Virtual Networks through Azure, so if you want communication between them, you have to go back through the on-premises VPN to which they’re all connected.

5: Azure Virtual Networks use virtual IP addresses

In an Azure Virtual Network, the virtual IP address refers to the public IP address used by external computers to connect to the Azure virtual machines. The external computer connects to the virtual IP address and the appropriate port (UDP or TCP) and is then redirected by Azure (if necessary) to the appropriate virtual machine.

6: Azure virtual machines use dynamic IP addresses

Each of your virtual machines on the Azure Virtual Network has a dynamic IP address assigned to it. It’s called “dynamic” because it’s assigned by Azure. Unlike dynamic IP addresses assigned by ISPs, for example, that can change frequently, this IP address works like a reserved address. So the same address stays with a particular virtual machine for as long as the VM exists.

Note that if you try to give your virtual machines static addresses, Azure won’t recognize them — and worse, you won’t be able to connect to those VMs.

7: You can move VMs into Azure Virtual Networks — sort of

You can “move” a virtual machine from your on-premises network to the Azure Virtual Network. When you do this, you don’t have to worry about static addresses that were assigned to the VM because Azure will automatically create a new NIC for the VM, which will be assigned a dynamic address. Even though we refer to moving the VM, we are actually re-creating it in a new VM on the Azure Virtual Network.

Even if you have a virtual machine that was created to live elsewhere on a virtual network, you still can’t just move it onto your Azure Virtual Network. But once again, you can create a new virtual machine on the Azure Virtual Network using the .vhd file for the existing Azure VM.

8: Azure service healing restores VMs to a running state

One major advantage of running virtual machines on Azure is that it can keep your VMs available even when there are problems. When Azure detects a problem with a node, it proactively moves the VMs to new nodes so they are restored to a running and accessible state.

This does cause the virtual machine to shut down and restart, which you’ll see recorded in the event log. When this happens, the MAC address, processor, and DPU ID will be changed. (This shouldn’t affect on your servers, including domain controllers, which we’ll talk about more in the next section.) The really good news is that when your VMs are running on an Azure Virtual Network, the IP address of the VM does not change when the healing process occurs.

Also note that storage on data disks is persistent, so the files stored there will not be affected by the restart and move. That’s why, with domain controllers running on Azure Virtual Networks, you need to store the Active Directory DIT, logs, and sysvol files on data disks. Data disks can be used to store any files other than the core operating system files. OS disks use caching, and data disks don’t; in the latter case, the data is immediately written to permanent storage.

9: Virtualizing domain controllers is supported

If you’ve been in the network admin business for a while, you probably know that in the past, running domain controllers on VMs was frowned upon. One big reason for that was that restoring VM snapshots could easily result in inconsistencies in the Active Directory database, such as inconsistent attribute values, password problems, duplicated security principles, and even schema mismatch. This could create a potential nightmare.

Windows Server 2012, however, introduced a new feature, VM Generation ID, that addresses this problem. Windows Azure Virtual Networks (the general availability version, released April 16) run on the Windows Server 2012 stack, and thus will support this feature, although the customer preview version did not.

This means you can create domain controllers (or “move” them from an on-premises network) in the Azure Virtual Network. Note that sysprep won’t work in this scenario. You need to move the .vhd file for your VM into Azure storage and use it to create a new VM. You can also create a brand new DC on the Azure Virtual Network and enable inbound replication.

10: Azure is secure

Security is always a concern with any cloud implementation, and it becomes more important when some or all of your infrastructure is in the public cloud. A recent Gartner report found that most customers are disappointed about incompleteness in security-related provisions in cloud providers’ contracts.

The Azure platform’s security controls are built in from the ground up, based on Microsoft’s Security Development Lifecycle (SDL). Azure uses identity and access management, physical and logical isolation, and encryption to provide confidentiality. It also follows best security practices, such as least privilege accounts for customer software and SSL mutual authentication for communications between internal components. Integrity protection is provided through the design of the Fabric VM, and extensive redundancy provides for robust availability.

For more detailed discussion of Azure’s security mechanisms, download the PDF Azure Security Overview from the Microsoft web site.

Also read…

Automatically sign up for TechRepublic’s 10 Things newsletter!