Azure Deployment Demystified: Key Considerations and Best Practices.

Consultant’s Corner

Welcome to Quorum’s Consultant’s Corner, a place where our Consulting team can share knowledge, discuss current issues on their minds, provide insights into their passions, or simply have a good old rant.

Alistair Laing

Senior Cloud Solutions Architect

Today, Alistair Laing returns to Consultant’s Corner, continuing with his theme of the Azure Cloud Adoption Framework. In the second of his Azure articles, Alistair covers Azure deployment strategies (you might find it useful to check out his previous article on the importance on Azure Landing Zones!)

Over to Alistair…

Azure Deployment Strategies

There are several valid and, above all, secure choices in Azure deployment. After that, the decision is a matter of reliability and consistency. Finally, some methods are easier than others!

Conveniently Quick

The quickest way to implement an Azure Landing Zone is to find the “Deploy to Azure” button in the Azure Landing Zone accelerator and fill out a series of boxes. This will create all the Azure resources you require for the shared components and structure these in management groups, subscriptions, resource groups, and connect them to hub networking.

The downside of this approach is that you may or may not understand what just happened, and this may turn out to be a problem for you in the future. If your risk management dictates that you must take responsibility for it, then you may wish to examine the scripts you just obtained or review what it has deployed for you. It depends on the level of trust you have in whoever or whatever provided the materials you just made use of, and this extends beyond the scripts to the various usage policies.

This brings with it a skilling challenge – understanding the scripts and templates, which on face value look like “code,” and then embracing these to develop your own takes work. Ideally, you need more than one person with this capability.

What I Recommend

The skilling challenge is worth accepting, and I thoroughly recommend deploying your Azure infrastructure using Bicep templates. Bicep is a layer over the JSON (JavaScript Object Notation)-based ARM (Azure Resource Manager) templates and is a lot easier to use than the former. Even better (from a Cost Optimisation perspective), it does not cost any more to use.

You will have to spend time and potentially money on the resourcing cost of learning how to create and maintain the scripts. You should really have a corresponding version control system built to manage code. The investment in establishing and maintaining Infrastructure as Code (IaC) skills is an important consideration in standardising your approach for deploying to Azure – it does not come for free and takes effort to maintain your scripts, and you must balance the effort with the return.

Why Define Infrastructure as Code?

Potential return on investment comes from the ability to rebuild your environment in the event of a disaster or other significant restructuring events using the scripts that you used to build the environment or scaling up to other workloads if you have established a reusable approach. Less quantifiable but still tangible is configuration drift – it is harder to track configuration changes that have been made manually via the Azure Portal, and any effort to keep in touch with this could be well-directed towards the discipline of having a bank of templates for deployment and maintaining them and the environment in check.

The key thing is to make a conscious decision on an approach and align this to business goals and strategy; business decision-making is a series of compromises based on context. Ideally, but not always possible, is to keep options open for when the operating context changes in the future. Again, understanding the pros and cons of a particular approach can be helped by working with specialists who understand the technical approaches and can work with you as the SME (subject matter expert) on your business.

Balancing Act

For the combined reasons of cost optimisation and skills management, I have seen some “inspired by landing zones” approaches that scale down the implementation to the thematic core of Azure Landing Zones implemented manually through the Azure Portal. These may take more manual effort in lieu of off-the-shelf templates being available but guarantee that costs are matched appropriately to benefits and that complexity is at an appropriate level for the skills available to manage and maintain them.

You may even choose to implement your management groups, subscriptions, and resource groups manually. Ideally (from my perspective), the negative experience of doing this manually will encourage you to learn how to use one of the free methods of automation!

The small bit of good news is that because the Azure Portal, ARM Templates, and Bicep Templates all talk to the same underlying Azure Resource Manager API, it keeps everything coordinated on your behalf.

The Measured Approach

It’s clear that it is easy to build up “technical debt” from avoiding the complexity that seems to come from the cloud and, in a sense, unwinding the benefits of public cloud. Again, it comes down to an appropriate understanding of the business reasons for considering public cloud for your solution and ideally having a comprehensive understanding of your existing arrangements.

The Microsoft Cloud Adoption Framework for Azure includes several “antipatterns” which are helpful in bursting a bubble or two when considering moving to public cloud. It may be that your goals do not stand up to adequate scrutiny, or that you uncover additional more compelling goals. The challenge, as mentioned above, is to give each aspect the right level of examination without spending too long.

I would always recommend heading towards a full or close to full definition of your environment in script so that you can scale or recover the environment as quickly as possible, and to capture a definition of the environment in something “offline,” i.e., separate from the running environment itself. This allows an element of scrutiny for standards and issues without touching your production systems and introducing potential security issues by over granting permissions.

A few source control options exist to store your scripts while providing more appropriate features than a version-controlled documentation management option like OneDrive/SharePoint. Microsoft themselves offer two Git-based management solutions in Azure DevOps and GitHub. Again, good practice in secret management should ensure you do not inadvertently advertise your logins and passwords in a public repository.

Can I (we) Help You?

In this and the previous article on Azure we have considered how to organise your approach and what tools to execute that approach with.

If this is all becoming a bit troublesome or confusing within your organisation, reach out and one of Quorum’s consultants can give you a hand. We have been building secure solutions for 25 years and we have seen it all; the good the bad, and the downright ugly.

Or if you would just like a bit more information on the Microsoft best practice for Azure Landing Zone Implementation, you can have a look here.