September was Ignite month – I will get to that in a moment. That means there should be lots of news. And this should be a post full of Azure announcements. But will it be?
I went to my first big Microsoft Conference in 2004 – TechEd Europe 2004 in Amsterdam, Netherlands. I’ve been to a few TechEd Europe events, the final few TechEd North America conferences and all but the second Microsoft Ignite. For me, TechEd, and then Ignite, was an important time of the year where I take a week to focus on learning. I find out what’s new and what I need to spend time on or dive a little into something new.
We all knew that COVID-19 was going to mean that Microsoft would have to do something different. But unfortunately, they went and repeated what just-has-not-worked in previous online attempts at Build and Inspire. The sessions are just 30 minutes long, meaning that the presenter has no time to deliver technical information. I can tell you, as a very experienced presenter, that a short session is a nightmare to deliver compared to a longer one. Give me 60-75 minutes and I can prepare for it in no time and guarantee that people leaving the room will learn something. Give me 30 minutes where I’m forced to do the conference stock content, and after all that, I’m left with 20 minutes to deliver a technical session? Mission impossible.
Yes, there is a “book of news”. You’ll be challenged to find many of the announcements that I’ve dug up in that book. The core audience for that book isn’t the techie – it’s members of the media that don’t care much about the detail.
And that is why, for me, a techie looking to learn more about Microsoft’s cloud services, Microsoft Ignite 2020 was a fail.
OK – maybe it’s my history with Hyper-V that made me write a slightly disingenuous heading. But the news at Microsoft Ignite that Azure VMware Solution is now generally available made me smile. But first, a quick refresher.
Way back in 2017, Microsoft let the world know that they were co-developing a physical capacity to host VMware in Azure with then-undocumented VMware ISV and hardware partners. A VMware quickly responded with “that won’t be supported!”, to which Microsoft replied “we’re using supported hardware implemented by certified partners”, and the VMware stance changed … to the point where VMware is now running in several hyper-scale clouds.
Microsoft did release Azure VMware Solution “v1.0”. That was co-developed by a partner. That company was subsequently acquired by Google, so Microsoft decided to do their own thing. At Ignite, Microsoft announced Azure VMware Solution (v2.0) which is built on physical servers and storage, running in Azure. It’s all certified and supported by VMware – a VMware employee even spoke at Ignite!
You can connect to your VMware farm via VPN or ExpressRoute (preferred) and manage it using the same VMware tools that you normally use. Virtual machines can be migrated or even moved by vMotion to/from Azure. Your services running in Azure VMware Solution can integrate into the rest of Azure. Management is possible via Azure Backup, Azure Security Center, Azure Sentinel, Azure Monitor, Azure Traffic Manager and more. Networks can be connected using ExpressRoute Global Reach.
Why would you consider VMware in Azure?
· Data center evacuation, such as end of contract or compliance issues.
· Hardware obsolescence
· Speed up cloud migration projects (vMotion)
· As a first step to cloud transformation
It’s that last one that VMware needs to be careful of. Once a VMware customer has migrated to Azure, they are not exactly going to be growing their license purchases or even planning on keeping them for long. You migrate to VMware in Azure because it is the first step to something else – it speeds up the first step of the process: getting into the cloud. And then what? Why you redeploy your services in some other fashion, whether it’s a lift’n’shift, a re-factor, or you redevelop it, as something else in Azure. And what hypervisor will be running underneath the refactored services at that point? Yes; you guessed it: Hyper-V.
If you work with Azure either at scale, doing repetitive tasks, or doing DevOps, then you should be deploying and configuring resources using infrastructure-as-code. Azure Resource Manager (ARM) offers a native platform to do IaC using ARM templates written in the JSON language. I work with ARM templates on a daily basis, deploying/configuring large enterprise systems. For noobs, JSON is a nightmare. For those of us working with complex or huge deployments, the complexity of the language can be a huge challenge. For example, doing simple decisions in ARM can make C++ programming look easy.
This complexity, even for ARM veterans, has led some to consider other “higher-level” languages that eventually become JSON deployments. The selling point of these languages is that they are easier to work with and can work (in theory) across different clouds. But there are always going to be some level of zero-day feature support and tech support issues with non-native solutions – but for some, the benefits outweigh the negatives.
Microsoft has heard the feedback and started work on a new higher-level language that van be compiled into JSON templates. The new language, codenamed Bicep (ARM!), was announced in the Spring and a very early version was released on GitHub for community testing, review, feedback, and contributions.
I have not worked with it yet – my hours are focused on what billable work I can do for customers and this “alpha” release isn’t production-ready. I have attended webinars and heard comments from colleagues. On the face of it, Bicep looks easier than JSON. But that’s it – it’s a littler easier, but not all that much. I don’t see any other big advantage, such as solving chicken & egg state management issues for more complex deployments. The team is very serious, so, hopefully, there will be more to Bicep than “it’s a little easier”.
Here are other Azure IaaS headlines from the past month:
I couldn’t find any of the below in written announcements, but some content was scattered through Ignite sessions and videos that were shared on other Microsoft platforms outside of the Ignite session catalog.
· You will be able to create site-to-site VPN connections over ExpressRoute for an encrypted channel.
· ExpressRoute Standard will support connections to Virtual Hubs in Azure Virtual WAN.
· The preview for third party appliances in Azure Virtual WAN hubs is adding Cisco Viptela.
· Azure Bastion has a private preview with support for VNet peering (do you hear the cheers of all those poor admins that have been forced to run Remote Desktop Gateway?)
· Azure DDoS protection has increased capacity to handle 45 Tbps attacks.
· ExpressRoute gateways will handle up to 16 circuit connections (up from 4).
· Site-to-Site VPN will support FQDNs as well as IPv4 addresses.
· BGP will support APIPA addresses, primarily for connections to AWS or GCP.
· Azure Load Balancer can support load balancing across public endpoints in different regions using a single anycast IP address.
· Azure Front Door will support wildcard domains.
· WAF has per-URI WAF policy in preview.
· CDN has a preview fir multi-origin support.
· Application Gateway has a preview for URL rewrite support.
· Wildcard listener support is in preview for Application Gateway.
· You will be able to select a Dedicated Host for a new virtual machine.
· VMSS can be used with Dedicated Hosts
· Support is being added for Fs_v2 virtual machines in Dedicated Hosts.
· Spot VMs have preview features to show you price history and eviction rate.
· A NC_v3_t4 VM for deep learning is in public preview.
· A ND_rv4 VM is in limited preview as an “AI supercomputer in the cloud”.
· A NV_av4 VM with Radtion GPU for accelerated visualization workloads is GA.
In my day-job (when I’m being Bruce Wayne), I work for a consulting company that focuses 100% on the cloud. I haven’t touched an on-premises, or even a hybrid cloud, service/feature/machine in years. Recently, I found myself in a project where we were playing a rare role in handling what is going on inside the virtual machines in a “greenfield customer” (one with no infrastructure at all because of an IT divestiture), so I decided that we should deploy Windows Admin Center in a virtual machine. I remember thinking “wouldn’t this be so much easier if it was an Azure service”.
Before there was Windows Admin Center (WAC), Azure did briefly run a preview service to manage Windows Server virtual machines either on-premises or in the cloud. The timing was probably wrong – the messaging of Nano Server left a bad taste in many mouths and many IT pros were still fearful of The BIG SCARY Cloud. So along came WAC.
WAC did some great things:
· The messaging was focused on on-premises machines but you could use it with Azure machines.
· It was “developed in public”, Microsoft’s Jeff Woolsey’s demo-fest sessions were always packed at conferences. He would show of the latest stuff and what was coming and is regularly updating people on social media.
· WAC is updated frequently. All too often, these next-great-features die off within a Windows Server release cycle. Microsoft has a bad habit of pushing new management tools or accelerators, and the small teams only have a temporary mandate to exist.
At Ignite, my wish was answered; Microsoft announced a private preview for Windows Admin Center running in the Azure Portal. This is a preview release of a v1.0 deployment method so it will not be perfect. But eh possibilities of Windows Admin Center, especially if clean integrations with Azure Monitor (and Log Analytics), Azure Security Center and Azure Sentinal can be implemented, could be freakin’ amazing.