Back matter
Afterword
Cloud computing did not eliminate systems administration.
It distributed it.
The machines became APIs. The network became software. Identity became part of application architecture. Load balancers, message queues, databases, key-management systems, schedulers, deployment systems, and logging platforms became things we can create with code.
That is enormously powerful.
It also means we can create a bad architecture faster than ever.
A few lines of infrastructure code can expose a service to the internet, grant an identity access to an entire project, delete a database, open a firewall, or create resources in three regions before anybody has finished explaining why.
Automation does not make judgment unnecessary.
It makes good judgment scalable.
The job is not to know every service §
Nobody carries all of Google Cloud in their head.
That is not the goal.
The more useful skill is recognizing the shape of the problem.
What is the trust boundary?
Who or what needs access?
What is the failure domain?
Where does state live?
What happens when a region fails?
How is the service deployed?
How is a change reviewed?
Where is evidence recorded?
What is the blast radius of a compromised identity?
Can we rebuild it?
Can we restore the data?
Can we prove that we restored the data?
Those questions survive product renames.
They survive Console redesigns.
They survive cloud vendors.
Security belongs in the architecture §
For a long time, organizations treated security as something applied to a finished system.
Scan it. Review it. Put a firewall in front of it. Send the logs somewhere. Write a policy.
That model does not fit infrastructure that can be recreated continuously from code.
Security decisions now exist in the same repositories as infrastructure decisions.
An IAM binding is code.
A firewall rule is code.
A Kubernetes policy is code.
A build pipeline is code.
A deployment approval is configuration.
That is why SecDevOps is not simply DevOps with a scanner added to the pipeline.
The security model and the operating model are the same architecture viewed from different directions.
Infrastructure as code changes responsibility §
Terraform and OpenTofu are useful because they automate provisioning.
That is the least interesting thing about them.
The bigger change is that infrastructure becomes something we can:
- review;
- diff;
- test;
- version;
- reproduce;
- audit;
- roll through environments;
- discuss in a pull request.
That creates the possibility of better infrastructure engineering.
It does not guarantee it.
A repository full of unreviewed modules and permanent administrative credentials is still a bad environment. It is simply a bad environment with excellent repeatability.
The discipline matters more than the tool.
Managed services are not outsourced responsibility §
Managed platforms remove work.
They do not remove ownership.
Google can operate the physical infrastructure behind Cloud SQL. Your organization still owns the decision to expose the instance publicly.
Google can manage the GKE control plane. Your organization still owns workload identity, network policy, container provenance, application configuration, and the deployment pipeline.
Google can preserve Cloud Storage objects. Your organization still owns access policy, retention, classification, and whether the data should have been there in the first place.
Shared responsibility is not a contractual phrase to memorize.
It is an architectural boundary.
Know where it is.
Production is where assumptions become facts §
The cleanest diagram in the world does not survive contact with production unchanged.
Traffic is bursty.
DNS gets cached.
Permissions propagate.
Certificates expire.
Teams leave.
Dependencies fail.
Quotas appear at inconvenient times.
Logs cost money.
People bypass controls because the approved path is too slow.
An emergency fix becomes permanent.
A "temporary" public endpoint survives for three years.
Good operations are largely the practice of making those realities visible before they become incidents.
Keep the system explainable §
Complex systems naturally become more complex.
Every exception has a reason.
Every workaround once solved a real problem.
Every extra role, project, route, firewall rule, service account, and deployment path adds another thing future engineers must understand.
Fight for explainability.
A production environment should not require folklore.
You should be able to point to the repository, architecture, policy, owner, monitoring, and recovery process and explain why the system exists in its current form.
When that stops being possible, complexity has become risk.
Keep rebuilding §
Cloud platforms reward people who are willing to rebuild their understanding.
The commands in this book will age.
Some services will change.
Some recommendations will improve.
Some of my conclusions may eventually be wrong.
That is fine.
The goal was never to freeze GCP in place.
The goal was to give you a way to reason about it.
Build the environment.
Break the sandbox.
Read the plan.
Watch the logs.
Remove the credential.
Close the port.
Restore the backup.
Question the default.
Automate the boring parts.
And when somebody tells you the system is production-ready, ask them how they know.