Azure reference architecture

tl;dr

• What is a reference architecture
  • My definition of a reference architecture
• I stop using the word architecture after the first 3 paragraphs – word overkill
• What are some important topics to cover in said document
• Is it easy to write? NO
• Final words – don’t jump into Azure without a reference architecture

---

I’m not going to lie to you. This is not a quick topic to write about. When it comes to Azure, you absolutely, 100% cannot dive straight in and consume services if you’re planning on doing that for pretty much any size organisation. The only way this could be averted is in a development environment, or a home lab. Period.

Without order nothing exists.

-someone awesome

This is where an Azure reference architecture comes in. Let’s define a reference architecture, or most commonly a reference architecture document (or series of documents);

Within IT: A reference architecture is a set of standards, best practices and guidelines for a given architecture that architects, consultants, administrators or managers refer to when making decisions on future implementations in that environment.

Since I think I’ve reached the word quota limit for “architect” or “architecture”, I will attempt to limit the use of those from this point forward. If necessary, I’ll refer to either of those as just the “a-word“.

So, what makes up a reference architecture?

This can be a subjective question. Any one consultant or architect working in IT may develop their own strategy, their own style or template when it comes to writing up a reference a-word. Typically though, I would come up with a single, large, mostly (i’ll be honest here) not very interesting document of all the components you would need to set-up a given environment from scratch. Expanding on that, include all the patterns that would constitute a valid design for your organisation. Finally, rather than looking at it from a physical or detailed technical point of view, mostly though, it’s written from a logical, orderly, OCD-ish higher level viewpoint.

The Azure reference a-word document will always be long. I’m talking 50+ pages! (depending on the size of your organisation); and that’s not an over exaggeration either. The larger the enterprise, likely, the longer the document.

What are some important topics in an Azure reference a-word?

I thought I’d share some of the key areas of a reference a-word as putting a document together of this scale, given the vastness of Azure services nowadays, can be an overwhelming proposition. There’s many aspects to Azure that need a definitive and agreed upon standard, or rules and policies to govern choice.

Sidebar – If anyone believes that choice is a good thing, should read The Paradox of Choice by Barry Schwartz. Great book and changed my perspective on choice.

I’m going to assume that the strategy has been set by the CIO or senior management and you’re now looking to use Azure. Whether this be on a whim (cloud is the buzz word, let’s start using it!) or a logical decision (cloud is now the default standard for infrastructure), moving onto the requirements and then design phase of any environment needs to have a reference a-word. The following are the key considerations for a reference a-word that will lay the foundations moving forward:

Requirements_

• Understand these
• Gather all requirements and ensure that any standard or policy adheres to these requirements
• Look at legacy infrastructure and a-word and learn from that

EA / accounts / subscriptions_

• Is there an enterprise agreement with Microsoft?
• How will the agreement, the department, the account and subscription be laid out
• Will there need to be multiple of any of these components?
• Will it be streamlined and under a single umbrella?
• What are the naming standards for these components?
• What geography and regional configuration will be used? Single region vs multi-region

Identity and access management_

• How is identity handled? Where is the source of truth?
• Will there be Federated Identity of Cloud Identity in use?
• Is there any third-party identity integration at all?
• Is there multi-factor authentication enabled and to what standard?
• Will role based access control be enabled? Who fits which roles?

IaaS_

Network

• What are the requirements?
• What are the naming standards for the VNET, network security groups, etc. ?
• Will there be any TAGs used and what is the standard for TAGs?
• Will there be a single VNET or multiple?
• What will the address space look like?
• How will subnetting be completed?
• Is there any security zones? Logical definition of network boundaries (eg. controlled, restricted and secured zones).
• Are there any trust boundaries in the design?
• Is there policies or governance around traffic traversing trust boundaries?
• What does connectivity look like to the VNET? ExpressRoute vs VPN
• What reporting will be configured on the various levels of network design?

Compute

• How will compute be administered?
• What is the naming standards for instances and workloads?
• Will there be any TAGs used and what is the standard for TAGs?
• Windows domain allows for 16 characters (15 usable) for host names, this needs to be considered.
• Are there standards for baseline images for instances?
• Will any SOE be leveraged from existing on-premises or legacy environments?
• Will any sizing criteria be set for specific types of workloads?
• What standards for IP address allocation are there?
• What are the HA, DR and backup solutions for compute?
• Will there be any encryption at the OS level?

Storage

• How will storage be logically administered?
• What are the naming standards for storage accounts?
• Will there be any TAGs used and what is the standard for TAGs?
• Will there be auditing and security standards for storage accounts?
• Will storage level encryption (currently in preview) be used ? (in preview: no guaranteed SLA or support from Microsoft)
• What is the HA, DR and backup strategy for all data residing in storage?

 PaaS_

• Will PaaS be available to be used?
• Who can use PaaS and what are the standards for usage?
• What are the security controls around PaaS?
• What is the naming standards for PaaS?

Hybrid_

• Will there be any requirement for hybrid a-word?
• What governance is there for hybrid a-word?

Operational management_

• Will any infrastructure as code or ARM templates (or equivalent) be used for streamlined provisioning and automation?
• What does the separation of duties look like for administration?
• What are the standards for remote connectivity for administration?
• What does the logging design look like? Will this integrate with on-premises tools?
• What are the standards for 3rd party tools usage for various environments?

Is it easy to write?

Writing a-word and design documents is never something that is easy. So no, this is not a walk in the park. Every requirement is mostly different and therefore needs careful consideration. Every legacy environment is also mostly different and therefore copying exactly the same principles and standards from on-premises will likely result in a badly designed Azure environment.

Final words

Azure is effectively a website. You logon, subscribe and are given keys to the kingdom. There is a wealth of choice, and a wealth of cost if you’re not careful, to build infrastructure (sorry, had to use it one last time), applications and services.

Before you jump in though, stop, breathe, take a few weeks and set a reference architecture so you have a well running machine in the end and not some hodgepodge that’s stuck together with hopes and dreams.

Best, Lucian