Multi-Cloud Consulting · Google Cloud
A Google Cloud organisation your teams can build on
We design the resource hierarchy, organisation policies, Shared VPC networking and Google Kubernetes Engine platform for your Google Cloud estate, in Terraform. Projects start inside guardrails, clusters are deployed by pipeline, and your engineers own every module.
The problem
Where this usually breaks down
Projects without a hierarchy
Projects created directly under the organisation, or under ad hoc folders, get IAM, billing and policy one project at a time. Nobody can say what a new project inherits.
Networks that multiply per team
Each team builds its own VPC with its own firewall rules and routes to on-premises. Address ranges collide, and connectivity is negotiated again for every new service.
Clusters configured by hand
Google Kubernetes Engine clusters created from the console differ in version, node configuration and access, and applications are deployed with credentials that live on individual laptops.
What we do
What we set up, and how each part works
We work in your repositories and through your change process, so everything we set up can be reviewed, run and changed by your engineers after we leave.
Folders and projects that mirror ownership
We design the folder structure beneath your organisation node around business units and environments, with IAM granted to groups at the folder level. A new project inherits access, billing and policy from where it is created.
Organisation policies as guardrails
Organisation policy constraints restrict resource locations, external IP addresses, service account keys and public access. They are set at the organisation or a folder, and tested on a sandbox folder before they are enforced more widely.
Google Kubernetes Engine clusters as code
Clusters are defined in Terraform, with private nodes, workload identity federation and release channels chosen deliberately. Applications reach them through a GitOps controller such as Argo CD, not through credentials held by people.
Secrets and releases kept out of Git
Secrets come from HashiCorp Vault at deploy time, and Helm charts or plain manifests describe each release, so Git holds the desired state of every environment and nothing sensitive.
Posture reporting and audit logging
Security Command Center reports misconfigurations and threats across the organisation, and audit logs are routed to a central logging project that workload teams can read but not change.
What you keep
What stays with your team when we finish
Everything is committed to your repositories or written into your documentation, under your access controls. Nothing depends on us to keep running.
Foundation Terraform in your repository
Modules for the folder structure, organisation policies, Shared VPC and cluster baseline, reviewed as a plan on every merge request.
An IAM and policy register
Which groups hold which roles at each folder, every organisation policy constraint in force, and every exception with its reason and owner.
A cluster and release baseline
The Google Kubernetes Engine cluster configuration, the GitOps setup and example Helm charts, ready for the next application team to follow.
Runbooks and decision records
Written decisions on hierarchy, networking and cluster design, and runbooks for project requests, break-glass access and cluster upgrades.
How we work
How an engagement runs, phase by phase
Each phase ends with something your team reviews and signs off before the next one starts. We work inside your change control, not around it.
01
Assess the current organisation
We review the existing projects, IAM bindings, networks and clusters, and agree with you which of them move under the new hierarchy and which stay where they are.
02
Design hierarchy and network
We agree the folder structure, the policy set, the Shared VPC layout and the address plan with your platform and network teams, and record each decision with its alternatives.
03
Build the foundation in code
Folders, policies, networking and a first cluster are written in Terraform and applied to a sandbox folder, where constraints are tested against real workload patterns first.
04
Move workloads and hand over
Existing projects move into their folders in agreed batches, and the first applications release through the GitOps path with your engineers doing the work. They keep every module and runbook.
Technology
The tools this work runs on
Each group says whether a tool appears in our published work, so you can tell what we have shown from what we offer.
Run in production
- Google Cloud
- Google Kubernetes Engine
- Terraform
- Argo CD
- Helm
- HashiCorp Vault
Offered, not in published work
- Security Command Center
- Cloud Interconnect
Evidence
Published work behind this service
Each statement below points to a write-up you can read in full, with the architecture and the stack as they were delivered.
On a DevSecOps platform, we set up Argo CD to release each tested image to Google Kubernetes Engine for SIT, UAT and production, with secrets issued from HashiCorp Vault.
Questions
What teams ask before we start
Can existing projects be moved into a new folder structure?
Yes. Projects can move between folders, but the IAM and organisation policies they inherit change when they do. We check each project against its target folder in advance and move them in batches you approve.
Is the Google Kubernetes Engine work separate from the foundation?
It can be. Some teams need the hierarchy and networking settled before any cluster exists, while others want a first cluster running early to test the pattern. We sequence the work around whichever constraint binds you first.
What access do you need to our Google Cloud organisation?
Viewer roles at the organisation level for the assessment. During the build, we propose changes as Terraform merge requests, and your pipeline applies them with a service account you control, under your own change process.
Who owns the platform once you step back?
Your team. The Terraform, the GitOps configuration, the Helm charts and the runbooks live in your repositories from the first commit. Your engineers make most of the changes, with us alongside them.
Related services
What teams often need alongside this
Azure landing zones
Azure landing zones in Terraform: management groups, policy at scale and a hub-and-spoke network that every subscription inherits.
Cloud-native DevOps on Kubernetes
One image built per change, Helm charts per service, and a GitOps controller that promotes it from SIT to UAT to PROD on Kubernetes.
Infrastructure as code with Terraform
Terraform modules, a plan reviewed on every merge request, applies only from the pipeline, and drift reported before it becomes an incident.
Next step
Plan your Google Cloud foundation with us
Tell us how your projects, networks and clusters are laid out today. We will come back with the decisions that matter most for the hierarchy.