Everything You Need to Know About Azure Infrastructure – May 2020 Edition

Microsoft Azure

Aidan Finn | Jun 01, 2020

As you might notice below, there were a lot of announcements in the world of Azure Infrastructure last month. That’s because Microsoft Build, the developer-focused conference, happened and it is one of the inflection points for new releases in the Azure calendar. Sure, Build is developer-focused, but in the modern world, developers and operators are closely linked, and developers are the ones building on the infrastructure that we IT pros build.

ARM at Build

Azure Resource Manager (ARM) is going through some growing pains at the moment. More Azure customers are using ARM than ever, their projects are getting bigger and more complex, and customers are demanding the ability to completely automate the delivery of a new service. For example, the deployments that I work with can take nearly 3 hours to execute … if they run cleanly! Microsoft announced some new features for ARM at the Build conference.

Some service delivery or configuration can only be automated by the execution of some script after the core deployment of resources. Our deployments at work make thousands of configurations. But as big as one of those deployments is, we still need to do some follow up work. Microsoft is addressing this with a new preview to execute scripts during an ARM deployment. A script within your template can complete the last mile of the delivery/configuration of the service that you are deploying. A public preview for this has begun with support for CLI and PowerShell scripts.

The ARM Testing Toolkit (ARM TTK) provides testing (or linting) of your ARM template code and is available on GitHub. You can add ARM-TTK to your DevOps pipelines using PowerShell to automate testing.

A major new preview feature in Azure PowerShell and CLI that Microsoft shared was what-if. What-if will allow you to test an ARM deployment before it executes. The purpose of what-if is to see what will happen as a result of executing the template, that is, what will change. The results of the execution can be formatted into JSON. Maybe you use it as a part of change control/rollback. Or maybe you might use it (in a large deployment pipeline) to see if you should even bother to deploy an ARM template at all – some of us use modular templates that are combined to deploy large solutions.

The Visual Studio (VS) Code ARM Tools extension rolled out another update This contains:

Schema updates for nearly all resource types.
IntelliSense for the resourceId() function.
Autogenerated parameters files – very useful.
Support for linking parameters files for validation during editing – very noisy and a total pain while modifying a complex template. It currently appears to have problems with object parameters.

I was delighted to hear that Microsoft had announced Template Specs, a new way to share ARM templates inside of an organization through Azure. The goal is that you can deploy a new resource through the Azure Portal using an organization-provided template – not everyone does DevOps and some people want a simple next-next-click-click experience.

Resources are rarely deployed as islands; typically they are deployed together as a service with a shared lifecycle. Resource Lifecycle management, a preview is coming in H2 2020, allows you to define groups of resources that should be treated as a single logical unit, even across different resource groups or subscriptions. The goal is to simplify lifecycle management tasks such as locking or deleting resources.

Microsoft has gotten a lot of feedback about the ARM language. Some find it quite hard to learn – to be honest, it has a huge learning curve and doing even simple decision making during a deployment is painfully complex. There is also a challenge for those of us on the other end of the curve where we are dealing with many templates touching many resources, and even tweaking existing resources that are owned by other deployments – making the wrong change in the wrong order can erase a complex set of configurations that were built up over time. To address these issues, Microsoft has started developing a new ARM desired-state language, codenamed as “Bicep”:

Readability is a top priority.
You will no longer need to write JSON although it will still compile to JSON under the covers – no; it’s not YAML! The compiling layer opens up the doors that future enhancements might include JavaScript, C#, or other implementations.
Modularity will be first-class (it’s hard to do in JSON) so templates will be able to exist as atomic modules
While the language will be an abstraction of Azure, the goal is to still have day 0 support for new properties and features.
It will be open source.
The ambition is that a preview 0.1 release will happen in 2-3 months.

Private Link Support Continues To Grow

Microsoft is following through on its promise with Private Link. At the last Microsoft Ignite conference (November 2019), Microsoft announced that Private Link would provide a service for easily connecting Azure resources to a virtual network for compliance and security reasons. It was also promised that each Azure resource type would eventually support Private Endpoint – the actualization of Private Link where the resource instance connects to a subnet of your choice to get a private IP address. Over time, more and more resource types have been added, and in May we saw the addition of the below:

Azure Monitor is an example of a less obvious resource type. When enabled, you get private access to Azure Monitor Logs (Log Analytics Workspaces) and Application Insights. No longer can these services be accessed over the Internet; instead you will require a private network connection.

At this time, it’s safe to say that Private Link has overtaken Service Endpoints in terms of supporting resource types.

Other Announcements from Microsoft

Here are other Azure IaaS headlines from the past month:

And Now for Something Different

I am part of a team working on a large project for a client. We’re building an entire IT and service infrastructure for this client that is exiting from a multitenant outsourced service. It is a complete green site build and only data will be migrated. That means the customer requires everything. We are going cloud-first and cloud-native where we can, but there are legacy requirements and that means services such as Active Directory Domain Services are still required – yes, domain controllers. My M365 colleagues wanted rid of the domain controller concept in this project but there are just too many reasons why the good old DC is still required. Azure Active Directory Domain Services is single region-only and I design for resilience, not single points of failure (see The Great Texan Azure AD Failure of September 4^th, 2018 – and the impact on Europe). Legacy systems that can only run in Windows virtual machines will also expect to find a domain.

As a Principal Consultant, it’s my job to teach the next generation of my colleagues. My employer has a healthy attitude of hiring a mixed level of experience, including college graduates. Those young “talents” can bring fresh ideas and enthusiasm, but they are inexperienced, so they need supervision and guidance; part of that is learning on the job. One of our younger consultants is assigned to work with me on Azure platform deployment. We hit a critical path point of the project where we needed to deploy some domain controllers.

I have deployed countless virtual machines for customers using ARM, but I deliberately do not log into them for security reasons. This time, I had no choice, so Azure Bastion was deployed, and we logged in to do a “DCPROMO”. I offered my colleague the chance to do the promotion and there was a realization – he knows almost nothing about Active Directory. In a couple of years, college graduates will be younger than Active Directory! Oh my, I’m getting old! So I let my colleague “drive” while I supervised, taught, and did some other tasks that required my attention. He got to learn a little about ADDS and he got to build the forest/domain for this organization. And I got to feel old.

But here is the key point. We still have these old techs out there that are relatively unchanged in the last 10 years, have been “replaced” (not really) by cloud alternatives, but are still at the heart of every IT infrastructure in mid-to-large enterprise. These legacy techs are not taught anymore – if they ever were! My young colleague explained that Active Directory was mentioned in college. Even Microsoft has stopped certification on Windows Server (there are no 2019 exams). IT pros that know this stuff are more valuable than ever because there are fewer replacements for you with each passing day, even in these cloud-first days because there is no viable alternative.

Microsoft Azure