Cloud Journey: Starting with Enterprise Scale — Part 2
(PART 1: Isolate cloud infrastructure for IaC Automation)
In Part 1, We have established the self-hosted agents required for Infrastructure as code automation and ensured an isolated private infrastructure setup.
PART 2: Organisation structure and hierarchy in cloud
The next important step in the cloud journey is to define the organizational structure. Organizations have an internal team structure and ownership for infrastructure which need to be applied to the cloud org structure.
- Efficiently manage access, policies, billing, and compliance.
- Multicloud consistency for landing zone provisioning and new team onboarding.
All major cloud provider has a mechanism to define hierarchies. Let's take the example of AWS, Azure, & GCP
AWS:
Entities: Organization, Root, Organization unit (OU), Account
Azure
Entities: Tenant Root, Management Group, Subscription
Google Cloud
Entities: Organization, Folder, Project
1. Efficiently manage access, policies, billing, and compliance.
If an organization has many accounts, you would need a way to efficiently manage access, policies, billing, and compliance for those accounts.
Hawkeye view at the root level would provide org level monitoring
2. Automation of account provisioning for new teams.
Once the hierarchy and accounts are logically grouped to follow enterprise guardrails and baselines, automation and future expansion and scaling out to multiple teams would become manageable.
Let's look at a sample from the real world. The organization has a primary cloud service provider Azure and supports other service providers. 3 new environments being requested by IT Admin, Data scientist, and Tech lead.
How simplified hierarchies come to the rescue and help establish conventions to efficiently manage access, policies, billing, and compliance.
PS: This article doesn't answer single management and control plane across service providers. That calls for another blog post :)
