10. Azure CAF as code

Overview

Governance for Infrastructure as Code projects

Based on the Cloud Adoption Framework
~~Deployed using Pulumi~~
Deployed using Terraform

POC to Production

Taking an infrastructure as code project from POC through to production.

The Customer
Professional Services Engagement
Architecture
Demo
Challenges

The key points I would like to present today are;
- Scaling an infrastructure as code project from a small team building a POC through to handing over multiple teams that are split across a large enterprise.
- This will include;
  - Doing so in a way which requires minimal re-factoring of the code
  - And, proposing a governance model that scales with the project
  - This will allow for fast iterations during development and slower, more controlled releases to production

I’d like to demonstrate these principles through the following points;

Use a hypothetical customer
Walk through the engagement process from a Professional Services POV
Discuss some high level Architecture principles and how it centers around the Azure Cloud Adoption Framework
- Apply scaling the governance and controls
I will then provide a demo of the change control workflow using GitHub Actions

And were going to try and fit this in under 1 hour.

Now I will try and get through the slides quickly, and there is a lot of content to cover, but it’s important to discuss what the design is based around before jumping right into the demo where it might not be immediately apparent.

The Customer

*Names have been replaced to protect the innocent.

Pineapple Networks
I would define Pineapple Networks as a “legacy” 36 year old networking vendor (which in no way is an analogy to Cisco)
This company has come to the realization that their existing product line is no longer fit for purpose in a modern, cloud native world.
They are very concerned about their revenue stream once some of the larger contracts start to come to an end over the next couple of years.
They board has decided the best course of action is to go through a “Digital Transformation” to bring the product lines and software development practices up to modern standards.
A bit of background on the company.
- Approximately 5000 Staff
- Geographically dispersed worldwide
- Mix of remote and on-site employees
- Acquired several companies over the years which are not presently integrated, acquired in name only but run independently with disparate systems.

Meet Mike, our Product owner and CTO of Pineapple Networks.

*R&D division.

Now because of the super-secret nature of the new product line in development Mike wants this to happen in a completely isolated manner, the submarine experience if you will.
The research division is tasked with 2 core mandates.
- Develop the new product line in isolation
- Share the new software development practices across the organisation as they are developed
- ```
  The rest of the organization can't wait three years for things to improve, they want to release early and continuously evolve the guidelines and practices overtime.
```

Professional Services

Time to phone a friend.

Guiding principles for the project

Industry best practices
Multiple environments
Entirely Automated through code
Extensible Platform
Governance that can scale
Enterprise grade security

At this stage in the project, Professional Services Inc workshops through ideas with Mike and define a set of principles that will set the direction for the project.
During this initial stage it’s important to focus on the outcomes rather than the technology.
- All too often a customer might say, I need Product X
- But early on it’s about questioning is product X really the best solution to achieve your goals.
- The customer might not know what they actually want but they do have a challenge they are trying to solve.
The principles are;
- Based on industry best practices, there is no need to re-invent the wheel.
- Supports a promotion based lifecycle across multiple environments.
  - For example;
    - Fully connected environments
      - DEV, STAGE PROD in Public Cloud
    - Partially connected or offline environments (CDS, or Time based sync)
      - DEV, STAGE PROD
The solution needs to be entirely automated through code.
- This in turn, helps to achieve other principles;
  - Easily audited
  - Easily reversible
  - And peer reviewing of changes is to a fundamental aspect to the platform
  - No single person (rogue or otherwise) should be able to make a change affecting the entire environment.
The platform needs to be extensible
- Both from the technology and governance sides
  - The platform will initially be developed by a small team from Professional Services Inc
  - Then handed over to 25 staff in the new research division.
  - Ultimately, the platform will support the full company of 5000+ staff
Security must be integrated into every step
- As a product company, Pineapple Networks regards their Patented Intellectual Property to be their most valuable asset.
Oh, and Mike has committed to a demonstration to the Pineapple Networks board of the proof-of-concept in 2 weeks. A successful demonstration to the board would result in the continued funding for the project.

The next stage is defining the specifications for what the platform will provide.
Including;
- Incorporates those High Level Design Principles that were discussed earlier
- Defining any existing services requiring integration
- The IP Addressing schemes, naming conventions and the like
- This is the time to determine anything that is set in stone
- And anything that is out of scope for the project.
This is where Professional Services Inc workshops the requirements with the client.
The sorts of roles involved,
- Product Owner (Mike)
- Customer Representatives
- Product Manager
- Business Analysts

INTERESTING IDEA: A Workshop from Web forms to JSON and beyond

The workshop results have come in and there is;
- Mix of legacy and cloud native workloads
- Multiple operations and software development teams
  - Who have varying skills and ownership levels of deployed resources
- And, the CFO is very concerned about tracking cloud spend
  - Wants a clear billing reporting chain
- They have provided services and application workloads
  - from which it was determined that an Azure based platform is the best approach
- IAM integration is out of scope of now

Architecture

The Microsoft Cloud Adoption Framework is defined as follows.
- Definition: Proven guidance to help create and implement business and technology strategies necessary for your organisation to succeed in the cloud.
- In short, it provides best practices, documentation and tooling that assists decision makers with both short-term and long-term objectives.
- No one knows Micrsoft’s products better than Microsoft. The Cloud Adoption Framework is how Professional Services can utilise Microsoft’s expertise.
Broken down into 5 Key areas.
- Create an overarching strategy
- Put a plan in place and define your backlog of work
- Get ready, deploy small and then scale the deployment
- Continuous Improvement (adopt new services, migrate workloads and innovate)
- And then there is the Govern & Manage pieces which envelop multiple areas
Now it’s where we drill down a bit further into some of those practices within the Cloud Adoption Framework.
Customer Update
- Mike, the Product Owner, has now advised he’s going on leave for a few days and wishes the team good luck!

By breaking up the environment into levels, we can leverage landing zones to scale governance.
The benefits are;
- Control the blast radius: minimise the impact to the landing zone and don’t compromise the entire environment.
- Enforce a standard configuration: compose complex environments fast from pre-defined templates.
- Enable autonomy: different landing zones can be developed independently at different development life cycles.
- Least privilege: Each level is protected by its own identity preventing unwanted modifications.
- Teams: Large organizations are often split across multiple teams. Each levels or landing zone might be owned, maintained and managed by a different team.
- Allows us to start small with Professional Services Engagement working from a single repo and then scale large by breaking out the levels into multiple repositories managed by separate teams.
Level 0: Launchpad (Management Zone)
- Subscriptions
- Terraform State
- Bastion Hosts for management zone
- Service Principals
- CI/CD used for management
- IAM and Active Directory Groups
Level 1: Security and Compliance (Audit Zone)
- RBAC enforcement
- Azure Management Groups
- Azure Policies
- Azure Monitor
- Azure Analysis
- Azure Event Hub
Level 2: Shared Services (Shared Services Zone)
- Azure Site Recovery Vault
- Azure Monitor configuration
- Azure Automation patch management
Level 3: Application Infrastructure (Application Zones)
- Azure Kubernetes Service
- Azure AppService
- API Management
- Azure Application Gateway
- Web Application Firewall
Level 4: Application Layer
- Deploy applications
- Kustomized manifests

An example deployment might contain;

One “Level 0” Landing Zone (per isolation boundary)
- Infrequent changes 6 months
A couple of “Level 1” and “Level 2”.
- Change frequency of around 1 month
A few more of “Level 3”.
- Change frequency weekly
Many “Level 4” applications will exist.
- Change frequency daily

Avoiding monolithic composition.

Delivery

Go On, Git!

This is where we talk about how the Lego blocks fit together.

Inner feedback loop: Provides quick feedback to DevOps engineers, offering the ability to test fast and iterate.
- May be local or sandbox subscription (MSDN) development
- Once the code change is complete, and has passed the pre-commit hooks, a pull-request is then raised for review and merger.
Secrets: Secrets for the environment
Terraform Config repositories: Storing the environment configuration separately from the logic.
Terraform Logic repositories: The core logic which is promoted through the environments once tested.
GitOps pipeline enforcing Landing Zones: Uses git as the single source of truth for the environment deployment and configuration.
Key Point
- There are 3 items that are fed into the CI/CD system, the output of which represents the DAG of the environment.
  - Logic
  - Config
  - Secrets
- Config and Secrets never leave their own environment.
- The logic however can be promoted and re-used
Graph Theory
- Directed Acyclic Graph
  - Nodes
  - Edges
  - Spines

Demo

Holiday Snaps

Mike at the beach with the wife.

Mike attending a birthday party.

Mike helping to flatten the curve.

Challenges

A sample of technical challenges.

Bootstrap

The chicken or the egg?

Data Transport

Securing data traversing environments.