In part one of this series I talked about what Microsoft Azure (formerly known as Windows Azure) offers to IT pros, and how you can consume the service, including trials and production usage. In this second part I am going to discuss my early experiences with Microsoft Azure, talk about what I like, what I think needs to improve, and how I think Azure will impact your employment status.
First Experiences with Virtual Machines
The early adopters of IaaS were deploying virtual machines that were known as virtual private servers (VPS) before the term “cloud” was a twinkle in the eye of some evil marketing genius. They deployed web servers and fired up a single service or lots of resold websites. This is a pretty simple deployment, so that’s what I replicated during my initial deployment using my MSDN benefit.
The wizard for deploying any of the services within Microsoft Azure is, for the most part (not always), pretty natural to use. The terminology for virtual machines is not that different to what we’re used to on-premise. Within 20 minutes I had a working IIS server handling a sample website securely behind a firewall in Microsoft Azure.
You can do a “quick create,” but I strongly recommend that you use the wizard to customize your virtual machine to suit your needs. The first screen offers you a gallery with different virtual machine templates that you can use for your new virtual machine. This is being regularly updated; the Windows images appear to be patched pretty regularly. In here you’ll find templates with SharePoint, Windows Essentials, SQL Server, BizTalk, Visual Studio, and more. You will also find non-Microsoft software. Microsoft Azure is based on Hyper-V, so if it’s supported on Hyper-V it’s probably also supported on Windows Azure. You’ll find Ubunto, CentOS, SUSE, and Oracle Linux distributions here, as well as Oracle and Java software running on Windows.
You have a choice of virtual machine sizes. As with the cloud, the more you consume, the more it will cost. There is a pricing calculator for the virtual machine role. Note that the price includes your Windows Server license; you can choose to enable Remote Desktop Services or install software like SharePoint. Those applications will require that you supply the hosting equivalent of Client Access Licneses (CALs), which you can buy on a monthly basis through a Services Provider License Agreement (SPLA) with a Microsoft distributor or large account reseller (LAR). After this you will be asked to enter some information on your cloud service, networking, and availability set (more on those later).
The virtual machine was up and running very quickly. One of the time-saving tricks that Microsoft employs is to disable the needless plug and play part of the mini-setup when a new virtual machine is deployed.
My quick test was pleasing: I had a working web server with just the necessary network ports open. That was a quick test, though – I wanted to do something bigger.
Remote Desktop Services Farm in Microsoft Azure
One scenario that I know some people will consider is to move their entire server footprint into a public cloud such as Microsoft Azure. I don’t think that you can just pick up your non-web services, such as file servers, and move them across a latent VPN or WAN link without engineering a solution. One option for this is to deploy a Remote Desktop Services (RDS) farm (maybe Citrix or similar on RDS) and place that farm in front of your services. End users would use remote desktop clients to log into the farm over SSL and access published apps or desktops that would appear on their devices.
I decided on a fault tolerant design that might work in the real world and be able to scale out as the needs of a “customer” would grow.
Microsoft announced legal usage and support for RDS on Microsoft Azure in July 2013. In terms of licensing:
- The price of the Microsoft Azure virtual machine includes the cost of Windows Server.
- You needs Remote Desktop Services Subscriber Access Licenses (SALs) for each user that will access the farm.
SALs are similar to Client Access Licenses (CALs), but they are paid for on a monthly basis through Services Provider License Agreement (SPLA) licensing. This is not the usual OEM/Open/Select/Enterprise Agreement that you might be used to from the past. A guest post by RDS MVP Freek Berson on the Building Clouds blog spells out some of the benefits of this design, both of which leverage a key trait of a cloud: elasticity.
There are two elements of this design that can scale out as demand increases. The front end servers that are facing the Internet are the web access and gateway servers. In my design, they are load balanced based on the RemoteFX ports. Further instances of this virtual machine can be deployed to expand the connection capability of the solution.
More likely is the need to have more than just two fault tolerant session hosts. A customer could deploy a number of these session hosts and keep just two operational by default. The powered-down virtual machines won’t accrue their operational costs (just storage costs). As users log in, additional session hosts can be powered up. As users log out, hosts can be drained and powered down. When you think about it, most companies have workers operational for just a fraction of the year, and servers are needlessly operational. This solution can scale up capacity quickly – and scale down almost as quickly to reduce operational costs.
The networking in Microsoft Azure takes some getting used to. You will probably have the same reaction I did when I first deployed a virtual machine: I freaked out when I logged into the virtual machine via Remote Desktop and saw that it appeared to have a DHCP assigned address. I immediately researched the best way to assign static IPs to the virtual machine. You can do this in the guest OS as normal, but that’s not supported. You can reserve an IP address using PowerShell, but I haven’t seen the need to do this yet. That’s because Azure isn’t really doing DHCP. It’s doing something similar to System Center Virtual Machine Manager (SCVMM), but it’s surfaced in the guest OS differently. Windows Azure assigns an IP address to a virtual machine for the life of that virtual machine. The guest OS will appear like it has a DHCP address but the address will not change. Some applications (Active Directory) might complain, but it won’t be a problem.
When you create a virtual network, you are doing something very similar to Hyper-V Network Virtualization, but with the benefit of leveraging Microsoft’s investment in the infrastructure. It’s incredibly easy to create a virtual network and the contained subnets that route automatically. My RDS farm uses this concept; my backend systems are in one subnet, the middle tier are in another, and my web access and gateway servers are placed into a subnet that can route to the Internet.
You will configure endpoints to enable Internet access. By default, every virtual machine will have remote PowerShell and Remote Desktop connectivity for remote administration. This is done using a randomized port that connects to NAT-protected private port in the virtual machine. You will open additional endpoints in the Microsoft Azure firewall to open up additional services. For example, TCP 80 and/or TCP 443 would be opened for a web server. In my RDS farm, I opened up those ports. However, I wanted two load-balanced web access and gateway servers. That’s why I configured a load-balanced set for each required port. I’ve worked with high-end load balancers like an F5 Big-IP. I have never load balanced as easily as I did with Azure!
Microsoft Azure: What Needs to Improve
There are one things that concerns me as an IT pro that is coming from a career of using Microsoft’s on-premise infrastructure products.
I spent several years working in the hosting industry running physical server, virtual machine, and website infrastructures. There is an unmentioned truth in much of that industry: there are no backups. Yes, unless you pay extra, the hosting company does not back up your content. Let’s face it – if you pay $5 per month for a website then you cannot expect all the bells and whistles.
Microsoft Azure does not back up your content either. Are there mechanism? There are… kind of. There is a nasty option where you can power down your virtual machine and perform a snapshot using PowerShell scripts. That might be fine for a test and dev lab, but that is not a solution for anyone considering moving their production systems into Microsoft’s cloud.
A second option might be to use an in-guest backup solution. Microsoft would pitch Microsoft Azure Online Backup to protect your data and settings. I’m a virtualization guy, and I do not like that option. I like to back up at the host or storage level because it should simplify backup management by dealing with virtual machines as objects or files. You cannot do this with Microsoft Azure. Microsoft does not provide that kind of backup service, and you cannot deploy your own (such as Veeam or System Center Data Protection Manager) because you do not have any access to the underlying physical infrastructure.
You will need to consider what you are going to run in Microsoft Azure and how you are going to protect it from within the guest OS if you are thinking about moving production systems into Microsoft Azure. I hope that Microsoft comes up with a better solution that can protect running virtual machines with VSS support and granular recovery.
Another concern is that there is no KVM access to a virtual machine. This is probably based on the limitations of the Hyper-V connection mechanisms that are present before Windows Server 2012 R2 (Microsoft Azure is based on Windows Server 2012). Your remote access to a virtual machine is limited to:
- Power controls via the console
- Remote Desktop
I would really want to see a KVM solution. I’ve had too many scenarios (on both of the big two hypervisors) where a guest OS misbehaves and I cannot use Remote Desktop. I need KVM access to resolve the issue. That leads us to another potential issue: When you deploy to a cloud like Microsoft Azure then you have to treat it differently than an on-premise infrastructure. Microsoft expects you to leverage availability sets for each tier of your service. This is where you create multiple (ideally at least three) instances of a virtual machine to perform a function in your service. You will then engineer at the application layer, or make use of failover clustering and/or load balancing to team those instances within an availability set.
Any virtual machines in an availability set will be spread across different hosts in Windows Azure, and this increases your service’s fault tolerance. Don’t engineer for the highly available hosts that you expect on premise. Instead, build HA into your service to take account for Microsoft’s concepts of “fault domains.”
Will Microsoft Azure Take Your Job?
I attended many events in the early days of the cloud. It was clear that at least half of the attendees were there to learn how to fight the cloud because they feared that it would steal their jobs. Some of Microsoft’s mysterious actions in the past year or so, such as cancelling the TechNet subscription for IT pros, feed that conspiracy theory. With Microsoft looking to sell infrastructure hosting to your employers, does this mean that they are trying to replace you?
I have several thoughts on this. First, I think the only people who should fear Microsoft Azure are other global hosting companies (Amazon, Rackspace, and so forth) and those resellers that are dependent on selling hardware instead of services.
If you are in the services business or are an on-premise administrator/engineer, then you will likely be spending less time looking at hardware than you did in the past if your company embraces Microsoft Azure. That’s probably a good thing. Lately it seems that most problems I hear about are related to storage performance/scalability, drivers, and firmware. Imagine if you don’t have less of that stuff to worry about and you leverage Microsoft’s custom engineered data centers. You deploy multiple instances of virtual machines for fault tolerance and no longer worry about infrastructure. Your job is to deploy services.
One of the directors at my job recently made an interesting observation about Microsoft Azure. He saw that I deployed virtual machines quickly enough, but that’s where Microsoft’s involvement ended. I still needed to deploy and customize RDS. I had to create and manage users. I had to install applications. I would have had to install file servers, application servers, and so on. Microsoft gave me a running OS, and it was up to me to do the valuable (to my potential employer or customer) engineering. I would have to continue to support any deployed services because Microsoft will not support my OS.
After spending time deploying some realistic test services in Microsoft Azure, I feel pretty confident that instead of taking your job, Azure will probably make your job more interesting. You’ll spend less time deploying hosts and storage, and more time on engineering services.
There is also another consideration: Microsoft Azure will not suit every organization or even every service in an organization that loves Microsoft’s cloud. This is why Microsoft’s Cloud OS is a hybrid cloud solution. So even though all you might hear from Microsoft in the coming months is “Azure! Azure! Azure! StorSimple! Azure!”, the real solution is a hybrid cloud with Hyper-V running in Microsoft Azure, Hyper-V and System Center running in hosting companies, Hyper-V and System Center running in your computer room – and you choose where to deploy the tiers of your services.
I deliberately ignored Microsoft Azure like many IT pros because I feared what it would mean to my professional future and its relevance to my customer’s needs. After one month I’ve come around 180 degrees. Strategic Microsoft partners in Ireland (admittedly a very small market) see the potential of Microsoft Azure for themselves (internal usage, lab, demo, and hosted managed services). Customers are starting to get the hybrid cloud message. And I’m convinced that Microsoft Azure is here to stay. I’ve found Microsoft Azure easy to pick up thanks to my experience in virtualization. And I’m pretty sure that IT pros shouldn’t lose their jobs. Instead, their jobs will change to focus more on service, which is exactly what their employers originally intended when they bought their first server.