Consultant’s Corner

Welcome to Quorum’s Consultant’s Corner. A place where our Consulting team can drop knowledge, talk about the issues that are currently on their minds, give us an insight into their passions, or just have a good old rant.

Understanding Landing Zones

The term “landing zone” appears to have originated in the United States military where they like to shorten it to LZ. Originally coined to denote the designated area for helicopter landings, they can range in permanence and typically involve thorough preparation to ensure a seamless landing process.

To stretch the metaphor…in the Azure context, it serves as the structural bedrock for workloads to ‘land,’ offering a clear roadmap for placement, necessary resources, and smooth operation throughout their lifecycle. The focus is on achieving a balance—enough to ensure proper functionality with minimal friction.

Are they “a bit much”?!

Technology adoption curves are fascinating things and a great benefit of working at Quorum is observing which customer sectors are adopting what technologies. This is borne out in the “bits” of Microsoft Cloud e.g. Microsoft 365 vs Azure and the sizes of organisation adopting them.

Many businesses embark on their cloud journey with ubiquitous services like email before venturing into Azure. As workloads diversify, complexity increases, requiring careful guidance.

Architecture could be explained as a balancing act between salient factors at a point in time and one must avoid falling into the trap of attempting a perfect design which will take too long to create and miss the opportunity of the moment. The other side of that coin is not creating artificial limitations meaning future rework is increased or that a solution must be thrown away and replaced.

Of course, certain techniques make tearing down and rebuilding cloud environments amazingly easy, but this also needs investment and brings with it the same architectural design challenges within the unit of deployment. (More on that in my next article)

The answer is that Azure Landing Zones are the way to go if you want to be organised in your implementation of Azure and provide a solid foundation.

Evolution and Frameworks

Progress in organisation of Azure is a recent development. For instance, since I started working with Azure it has switched from Classic to Resource Model. Then Management Groups and Policy came along which provided a scalable foundation for a lot of what is seen in Azure Landing Zones.

We do well to remember that Azure Landing Zones are part of the Microsoft Cloud Adoption Framework for Azure – this ensures that the foundations of a good IT project are in place. It seeks to ensure that the reasons for using Azure are solid. Alongside this we have the Well Architected Framework which has important pillars that must be tracked throughout the process. These pillars give a handy perspective from which to examine whether Azure Landing Zones are a bit too much.

Microsoft Azure Well-Architected Framework

One needs to be pragmatic with every framework and a skilled architect will attempt to judge how much or how little time and effort needs to be spent on each of the five pillars of architectural excellence. In fact, at the time of writing Microsoft refers to “guiding tenets” which should be relied on to help in getting the job done rather than providing an opportunity to get bogged down in doctrine!

The Microsoft Azure Well-Architected Framework consists of the following five pillars of architectural excellence:

It is also telling that the other cloud platforms also have similar frameworks. Although the wording and order may differ, the principles follow naturally from services that facilitate similar function and that deserve the same consideration in their construction, operation, and decommissioning.

To reiterate my opening comment on frameworks, I would argue that an SME using public has the same considerations as a multinational enterprise and that the resource devoted to those considerations is scaled appropriately. I would also argue that the measure of “appropriate scale” is harder for an enterprise and is likely to overshoot (which is why I like that AWS call out sustainability as a pillar).

This is where I think that working with an experienced Partner makes the difference – the agility to scale a project as appropriate is important, as is an in-depth knowledge of a particular public cloud platform to ensure that the engineering is up to scratch. The process is most definitely a partnership as the organisation looking to move to the public cloud must consider their appetites around risk management and the knock-on consequences of business that ally to the architectural pillars above

Implementation in Practice

If you are of a mind to “get on with it” which I think is a necessary, part of project planning then you will want to get some resources deployed to Azure and “do stuff.”

To this end you will need to establish what your requirement needs from the infrastructure and a sense of the roadmap you face. The latter is a balancing act between planning for the future and getting things done.

Then it is a process of trying to split out platform and application zones. Both types of zones will experience change, but platform zones tend to host shared services such as connectivity and monitoring and application zones are used for separate applications that have their own lifecycle and consume shared services.

Microsoft publish several landing zone accelerators for both platform and application landing zones; for instance, there are application landing zones for AKS (Azure Kubernetes Service), HPC, SAP, API Management, Red Hat OpenShift, and many others.

There is also a platform landing zone accelerator called the “Azure landing zone portal accelerator” that covers an entire architecture for an organisation.

Pragmatism

The combined considerations of cost optimisation and skills management have led some to adopt an “inspired by landing zones” approach that scales down the implementation to the thematic core of Azure Landing Zones as created through the Azure Portal. This will take longer to deploy but guarantees that costs are matched appropriately to benefits and that complexity is at an appropriate level for the skills available.

I would recommend making the most of multiple subscriptions to provide a clear demarcation between workloads – at its most basic it adds subscription level to your RBAC granularity and invites good consideration at the beginning to what shared services you may need. This should lead to cost reduction and again through the pillars of the well architected framework. If you identify beforehand what your shared services are then you automatically inherit a common approach (because there is only one approach…). A common approach should mean operational excellence.

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!

Cost Optimisation

The final caution of deploying straight from the accelerator is the cost implication of the included resources. The structural elements of Azure such as Management Groups, Subscriptions and Resource Groups do not cost any money to use and there is a lot to be said for using these as far as possible to implement policy and to support a robust RBAC (Role Based Access Control) model.

The resources that are deployed into those resource groups vary in charging model, and in particular resources like Azure Firewall come with an hourly charge which starts as soon as the resource is deployed. It is important to understand the resources that are required and what the cost structure is (Cost optimisation). This is not to say that these should be avoided; it is that a conscious decision should be made to understand the implications of a particular approach and what the associated commitment in spend is likely to be.

This is why cost optimisation is one of the pillars of the well architected framework alongside security, operations, and reliability because these are the primary areas in which compromises must come. As one would expect, the “best” options for Reliability, Security and Operational Excellence are typically the most expensive (which is why the other two pillars are Performance Efficiency and Cost Optimisation!).

Although Azure Policy is not charged for, the areas in which it takes effect may have a cost implication and often for a good reason as policy is a valuable tool in making “guard rails” work in practice.

Final Thoughts

If this is all becoming a bit troublesome or confusing within your organisation, reach out and one of Quorum’s consultants can assist. With 25 years of experience, Quorum specialises in building secure and resilient identity solutions. Whether clarifying complexities or securing your business, our expertise covers the entire spectrum. For more information on Azure Landing Zones’ best practices, visit here.

Stay tuned for the next article in the series, focusing on various approaches to deploying Azure Resources. It will provide valuable insights into Azure Deployment, offering a comprehensive guide for stakeholders.

Articles

CONTACT INFO

Quorum

18 Greenside Lane Edinburgh

UK EH1 3AH

Phone: +44 131 652 3954

Email: marketing@quorum.co.uk