Day 2 of Microsoft Ignite is in the books and I spent the majority of it at the Linux Academy booth (no. 2169, rear of the exhibit hall, across from the bookstore), talking to people about their enterprises.
The refrain I heard consistently from people stopping by the booth was that their companies want to move to the public cloud but don’t know how. Many attendees were at Ignite to explore the questions around exactly how to do that.
This, of course, is great news to us at Linux Academy, because we’re all about training people how to use Azure and how to use DevOps procedures and tooling. So I had lots of opportunities Tuesday to geek out on the kinds of ways you can host a workload in Azure (virtual machines, App Service, Azure SQL Database) and how you can manage getting your workloads into Azure (Chef, Puppet, Docker, Jenkins, etc.)
But many people I talked to weren’t even ready to have those kinds of discussions. A lot of them were still stuck on larger questions, like cost (including the labor costs of experienced migration assistants), governance, and the like.
To help with these kinds of issues, Microsoft has created Azure Migrate. Less a turnkey solution to these issues, it’s more of a information and assessment portal. For example, if an organization is looking to do a lift-and-shift of an existing workload to Azure, the Migrate tooling is capable of discovering the topology of a local network and translating that topology to a similar implementation in Azure.
Azure Migrate can also figure out the most cost-effective virtual machine size for an on-premises workload, which helps with cost savings. And it can help determine the correct database solution, be it Azure SQL Database or SQL Server instances running on VMs.
Migrate is in limited preview, which means you need to apply to use it.
Azure is also using Ignite to describe its new availability zones approach to ensuring high availability for virtual machines, virtual machine scale sets, managed disks and load balancers.
Today, when we want to provision Azure virtual machines in a highly available configuration, we use an availability set. This system automatically distributes virtual machines across fault and update domains.
In this diagram, we see a basic availability set of two machines. Each is in its own fault domain, which is a physical separation of the hardware, switches and power supplies, and protects the VMs from a simultaneous hardware casualty.
Each VM is also in its own update domain, which protects the machines from simultaneously restarting due to a software or OS update.
There are, by default, three fault domains and five update domains per availability set. That means running a highly available solution based in VMs can get expensive, quickly. For example, if my solution needs a minimum of two VMs to run under a normal workload, that means I have to provision 10 VMs – because there are five update domains per availability set, and as many as four of those update domains might be offline at once.
This, needless to say, is expensive.
To work around that problem, Azure is introducing availability zones, which allow you to assign each virtual machine to one of up to three zones. You can distribute virtual machines, their managed disks and their load balancers into one, two or three availability zones. You have control over which machines and disks are in which zone, and whether the load balancers in the solution balance traffic for a specific zone or all zones.
So, a “two machines available at all times” topology now looks like this:
This is an improvement over availability sets (and their VM scale set cousin, the placement group) because not only does it allow you to control which machines are in each group – thus give you control over costs – it also protects the disks for those machines, which is not something an availability set or placement group can do for you now.
Each availability zone is a separate location within a given Azure region, intended to prevent the resources in it from suffering the same natural disaster or major casualty. For example, if a given datacenter in a region lost power, it should have availability zones that incorporate datacenters on different network grids.
Availability zones are currently in preview for V2 version VMs in the East US 2 (Virginia) and West Europe (Netherlands) regions. But expect this feature to roll out aggressively, to many new regions quickly, and eventually to other VM service tiers.
You’ll note as well that this removes the concept of the update domain. In addition to availability zones, Azure is rolling out planned maintenance.
This change allows you to specify specific time periods when virtual machines should receive OS and software patches, called the “proactive redeploy” window. If you don’t choose to use these time periods to update, Azure will instead patch your machines at a different, predefined time.
This new feature allows you to control when machines restart. It allows you to also orchestrate restarts based on your demand needs; you can schedule restarts for a non-busy time or to reboot to maintain a service level agreement with a workload provider, for example.
Event alerts are also available for this service; you can receive SMS messages or emails when planned maintenance events take place or call a webhook if you need to automate additional actions around a planned maintenance restart.
Coupled with availability zones, this now gives VM operators in Azure the ability to run fewer VMs while ensuring a minimum number of VMs are running at all times.
That’s it for now. My Wednesday is booked solid with seminars on containers and DevOps. Watch here for additional news, and if you’re at Ignite, stop by booth 2169 and say “hello!”