GCP is pleasant to start on, which is how the sprawl happens
Projects are cheap to create, so they get created. Two years later nobody can say which ones matter.
Projects created per experiment, outside any folder hierarchy, with billing attached and no owner listed.
No clear boundaryPrimitive roles granted at project level because it was quicker, service-account keys downloaded to laptops, and no idea which permissions are actually used.
Over-permissionedCommitted use discounts bought once, BigQuery on-demand queries nobody is watching, and no label policy to attribute any of it.
Growing, unattributedOne engineer knows why the Shared VPC is arranged that way and what the custom roles are protecting.
Single ownerWe run Google Cloud. Getting you onto it is a separate job.
Where this sits relative to the work either side of it, so you can tell what you are and are not buying.
Cloud Enablement
Landing zones, migration and the architecture that should exist first.
Go to the pageGoogle Cloud, operated
Day-to-day operation of a GCP estate: IAM, projects, network, patching, backup, cost and on-call. Continuous rather than scoped.
Site Reliability
Google wrote the SRE book; running to error budgets is the layer above operating the estate.
Go to the pagePlenty of clients buy one layer and run the rest themselves. That is a normal outcome, not a half-sale.
What running Google Cloud actually involves
Organisation, folders and projects
A resource hierarchy that reflects how you actually work, Organization Policy constraints for the rules you want enforced, and project provisioning as Terraform so a new environment is a merge request rather than a favour.
IAM
Predefined and custom roles instead of primitive ones, Workload Identity Federation so no service-account key ever lands on a laptop, IAM Recommender used to strip unused permissions, and short-lived credentials throughout.
Network
Shared VPC where it earns its keep, Private Service Connect for the services that should never be public, Cloud NAT and egress you can account for, and firewall rules with an owner.
Compute and workloads
GKE, Cloud Run, or Compute Engine chosen for the workload — with Autopilot where it fits, committed use discounts against observed usage, and Spot VMs where the workload tolerates them.
Data and backup
Cloud SQL or AlloyDB with a rehearsed restore, GCS lifecycle and retention policies where compliance requires them, and BigQuery with slot reservations rather than an open-ended on-demand bill.
Observability and response
Cloud Monitoring and Logging with log sinks that do not quietly cost more than the workload, Prometheus and Grafana where they fit better, and an on-call rota with runbooks during UK and EU hours.
Investigate, implement, hand over
What is genuinely running: accounts, workloads, identity, network, backups, cost, and how a change reaches production today. You get a written picture of the current state and a scope in priority order — what is dangerous, what is expensive, and what can wait.
The priority items, in sequence, as code in your repositories. Rehearsed in the lower environments first, with the rollback run rather than described. Nothing goes in that your own engineers cannot read.
Runbooks, architecture decisions and the reasoning behind them, written down. A working session per area with your team. We stay on-call afterwards only if you want us to.
Google runs the platform. Count what is left.
This is the honest version of a comparison most pages skip. The provider takes real work off you — and it takes one layer, not the stack.
Google Cloud
The physical estate, the hypervisor, the managed service control planes and the SLAs behind them. Google does this well, and it is genuinely worth paying for.
What is left
Resource hierarchy and project design. IAM roles and service-account hygiene. Network topology. Patching. Backup and rehearsed restore. Observability. Cost. And every workload running on top.
What you are actually choosing between
| Option | Left as code | Runs day to day | Actively cuts cost | Security you can evidence | No key-person risk | Best fit when… |
|---|---|---|---|---|---|---|
| Hire in-house | the work is genuinely continuous — then hiring is the right call. | |||||
| Generalist MSP | you only need the lights kept on. | |||||
| Leave it alone | nothing has broken, been audited, or been queried yet. | |||||
| OpsHero | the work comes in bursts and has to outlast us. |
Managed Google Cloud is not right for everybody
If your estate is a couple of Cloud Run services and a managed database, GCP is doing most of the operating for you already and a retainer adds little. This pays when IAM, project structure and cost stop being something one person can hold. We would rather say that on a page than halfway through an engagement.
None of it is true yet. Worth a conversation.
Your answers stay in your browser.
The ones people actually ask
We are mostly on GKE. Is this the right page?
Partly. Running the cluster is Kubernetes work and has its own page; this page is the estate around it — projects, IAM, network, cost and the managed services the cluster talks to. Most engagements touch both.
Do you resell Google Cloud capacity?
No. You keep your own billing relationship and pay Google directly. We are not in the middle of it.
How do you handle security?
By mechanism: Workload Identity Federation instead of downloaded keys, custom roles over primitive ones, Organization Policy constraints, Secret Manager, and infrastructure-code scanning in the pipeline. Google's compliance certifications belong to Google; we tell you what we implement and what it evidences.
Can you take over an estate somebody else built?
Yes, and it is the normal case rather than an exception.
Will we be locked in?
Your repositories, your projects, your organisation — documented and reproducible. Nothing we build depends on us still being here.
Talk to a Google Cloud engineer
Not a salesperson. You will get a read on your estate, the specific risks in it, and what the work would involve.
- A written picture of what is actually running, and what state it is in
- The risks in priority order — dangerous, expensive, and can wait
- What the work would involve, and in what sequence
- Everything delivered into your own repositories and cloud accounts