More and more people realize that Microsoft Azure can be a huge benefit in their day to day business. The scalability of services and speed with which you can run your business on a global scale is unprescedented to anything you would be able to accomplish in your own datacenter.
The Azure web interface looks straight-forward enough, but after working with it for a few days, weeks, months or after following one of my Azure classes, people soon realize that Azure really consists out of a lot of “moving parts”. This blogpost I’ll focus on all moving parts surrounding a Virtual Machine in Azure. Lots of readers will surely think:”Come on, it’s not that different from an on-prem VM, is it?” I could just give you the answer right away, but that would make for a really short blog post, wouldn’t it?
Part 1: What is “the planned way”?
To start off, I always ask people to plan their deployments, instead of just clicking everything together. What things to consider? Well there’s the sheer size of the Virtual Machine just to name one of the things… Networking is another thing you might want to “design” before you provision a VM. And then of course the number of data disks the vm will need, which is directly related to the T-shirt Size of the vm you chose before.
Why size matters in Cloud Computing:
Size matters in cloud computing and I’ll give you one, hopefully very clear example why… Let’s say your company is taking advantage of the scalability of services / vm’s in the cloud. This means that at a certain point you defined, which in Azure can be queue depth in Web Services or CPU load in VM’s, your service starts to scale out. What’s the amount it will scale out to? To another VM/Service with the same size. Whenever you host your “normal workload on an A6 machine, the Azure service will in fact spin up another A6 machine to scale out the affected service. That could just be a little overkill. So it might be a better idea, when your application supports scaling out, to offer those services on a couple of smaller virtual IaaS servers, so you can scale out on a more granular basis. This is a scenario most often used in scaling out front-end servers of web-applications.
Networking is somewhat different from the experience on-premise.
How come? Well there are no cables involved for starters… It’s all about Software Defined Networking (SDN). You can imagine that all network operations you initiate in your part of the Azure cloud could have a major impact on the performance of the global service, so some choices are limited / made for you… One of the things you’ll hear me say over and over again… “When you use Azure, plan ahead….”
The same goes for networking in Azure;
- Yes, it’s currently possible to create a Virtual Machine with multiple NIC’s, but only with Powershell…
- Yes, we can use static ip addresses in our Vm’s on Azure, but only set by Powershell….
- Yes, we can change the Virtual Network on a deployed VM in Azure, but only with….. (you’ve guessed it)…. Powershell.
Did I already mention NOW is the time to get your Powershell knowledge up to par? Well, I should have, and it is….
The main use of virtual networks is not only to create connectivity within the Azure Platform, but even more so to create a gateway to the outside world. This is where you start your connectivity through the Point-to-site and site-to-site VPN’s towards your clients or on-premise environment.
How much data storage do you need? And with deduplication?
I know the sizes of larger virtual machines might seem a bit out there, but there are use cases for them, only think of burst-workloads where you only need a vm for a couple of hours to do some hard labor. That’s the ideal workload for your Azure subscription… Peaks and test/dev work… So there’s another thing to consider next time you renew the hardware in your on premise datacenter… Size your datacenter for the average workload, instead of the peak workloads we’re accustomed to sizing our datacenter for. I’ve heard a lot of criticism of people stating they can’t upload their VHDX files to Azure without converting it to VHD first… I get that when stating that the VHDX format is better equipped to handle failures and corruption. But from a sizing perspective on the other hand, we currently have a (support) limit on VHD’s in Azure of 1TB each. With a maximum of 16 data disks in the larger VM-sizes (A7-A9), you can accomplish a maximum of 16TB in available gross storage capacity in a single VM. When creating redundant volumes on top of this available pool of storage you’ll also want to consider using the deduplication features inside the VM. Another thing to realize is that the current supported limit on a storage account is 20.000 IOPS. So place your workloads and vhd’s wisely according to the limits discussed above…
In this post we’ve unveiled just a couple of “moving parts” on which a VM is greatly dependent on and I’ve hopefully provided you with some extra pointers to consider when deploying “just” another virtual machine on Azure.
Check back soon for the next phase in our mini-build in part 2 of these series….