Enterprise Scale Azure Landing Zones Azure DEVOps using Terraform and CAF Modules: Structure

TL:DR The configuration and logic separation is not clear, you can only change things directly in one of the many source code repositories without hurting yourself.

This series of stories is a practical set of written instructions for Microsoft Cloud Adoption Framework for Azure documentation — Cloud Adoption Framework | Microsoft Docs.

This story carries on from Enterprise Scale Azure Landing Zones Azure DEVOps using Terraform and CAF Modules: Start Here.

DEV before Ops

I come from a DEV background not an Ops background so I tend to think in terms of software layers, calling mechanisms and encapsulation. I have found it handy to map my understanding of how a software project would be structured to how components are used to implement the Cloud Adoption Framework.

Working with people who have an Ops background I find they do not have this ‘layered’ approach and tend to ‘just knock things up’ in as simple a method as possible, so one big script, and some cryptic notes on the manual procedures. Sorry if that’s a biased view its one that comes from observing other people. So if I am teaching the art of egg sucking, I apologise now.

As the procedural elements are hidden away the overall feel of implementing the Cloud Adoption Framework via Terraform is more like Functional Programming than Procedural Programming. The encapsulation does give it an Object Orientated feel especially as you are effectively passing messages between encapsulated representations of ‘virtual’ items.

Working Components

These components are actually used during a deployment, any changes to them will alter what is deployed.

Open Working Components

These components belong to you, think of them as your ‘program’, its your job to write and maintain them.

You can freely change them as no-one else is using them other than you, or your organisation. They belong in your source code control system.

• caf-terraform-landingzones-<org>, you need to name this yourself as its yours, start by copying an appropriate existing starter project.

Closed Working Components

These components belong to other people, typically Microsoft or Hashicorp, they write and maintain them. You can’t change them. Copying them is a really bad idea because once you no longer benefit from new functionality and bug fixes.

However you may need to change them and so you will ‘fork’ them and work with the fork rather than directly with them. This will allow you to periodically update them, rather than them changing unexpectedly, and also make changes for new or broken functionality and then ask the people who look after them to include your changes, via a ‘pull request’, so we can all benefit from your smarts. I’ll cover the practicalities of this in a couple of later posts.

• LandingZones, maintained by Microsoft, the rover module will download a specific branch of this project, interestingly different parts of your deployment may need to use different branches as they reference different modules.
• Enterprise Scale, maintained by Microsoft, this is a terraform provider which supplies the standard configurations for Azure Resources as Terraform files.
• Cloud Adoption Framework for Azure — Terraform Module, maintained by Microsoft, this is a terraform provider which supplies the standard configurations for Azure Resources as Terraform files.
• Enterprise — Scale — Reference Implementation, maintained by Microsoft, this is a reference implementation but the Enterprise Scale project uses a GitHub action to copy parts of it into itself.

How they Fit Together

Understanding how each of these components gets called is critical to being able to find out what is going on during a deployment.

• When you invoke caf-terraform-landingzones-<org>, your code, you reference a specific LandingZones branch.
• LandingZones references a specific Enterprise Scale branch
• LandingZones references a specific Cloud Adoption Framework for Azure — Terraform Module branch
• Enterprise Scale contains parts of a specific branch of the Enterprise — Scale — Reference Implementation

Rover

Critical to the understanding of how things get invoked is Rover, which I’ll go into in detail in my next post.

Rover is a virtual environment that downloads and uses the various components to change the state of your Azure environment into the desired state.

When you invoke it you specify which LandingZones branch to use, which then specifies which branches to use for the other sources.

Reference Components

These components are never actually used but you may find yourself referring to them to see how other people have done things.

• Starter Project, maintained by Microsoft, the go to place to find out how to configure your desired functionality.
• LandingZones, maintained by Microsoft, parts of this project, e.g. the ‘scenarios’ are never actually used but act as a set of reference implementations.

TL:CR The configuration and logic separation is not clear, you can only change things directly in one of the many source code repositories without hurting yourself.