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. -Lucian
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“.
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.
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:
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.
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.