Front matter

Foreword

Rick asked me to write the foreword to his giant GCP book.

So here we are.

I've worked with Unix and Linux systems for a long time. Servers, storage, networks, automation, clusters, things breaking, things that were definitely not supposed to break, and things somebody swore had been fixed three weeks ago.

Now we have cloud.

Which is still computers.

There are just more APIs involved.

That sounds like I'm being dismissive of it. I'm not. GCP can do an enormous amount of useful stuff. You can build infrastructure in minutes that would have taken weeks or months to put together not that long ago.

That's pretty great.

It also means you can build something completely ridiculous in minutes.

Also pretty great, depending on who has to support it.

Cloud Is Not Magic §

This is probably the most important thing to get out of the way.

Cloud isn't magic.

Compute Engine is still compute.

A VPC is still a network.

Cloud Storage is still storage.

Cloud SQL is still a database.

IAM is still figuring out who gets to do what, except now there are approximately nine thousand ways to get it wrong.

Kubernetes is Kubernetes.

Sorry.

The names change. The interfaces change. The underlying problems don't change nearly as much as people like to pretend they do.

You still need to know:

• Where the traffic goes;
• Who has access;
• Where the data lives;
• What happens when something fails;
• How you're going to recover it;
• Why somebody gave that service account Owner.

Especially that last one.

This Book Actually Treats GCP Like Infrastructure §

There are plenty of books that explain what Google Cloud services are.

That's useful.

Google also has documentation.

Lots of documentation.

What Rick is doing here is a little different.

The book is more interested in how the pieces fit together when you're building something that has to keep working after the tutorial is over.

That's the part I care about.

Making a VM is easy.

Making a VM that belongs in a sane network, has the right permissions, gets patched, gets monitored, doesn't have SSH open to the planet, can be replaced, and doesn't contain six years of undocumented manual changes is the interesting part.

Same thing with Kubernetes.

Same thing with databases.

Same thing with basically everything else in here.

IAM §

You will notice there is a lot about IAM.

Good.

IAM is one of those things everybody understands right up until they don't.

Then suddenly some application has permission to administer an entire project because getting the permissions right was annoying and somebody wanted the deployment working before lunch.

Yeah well, Now it's in production.

Rick spends a lot of time on service accounts, workload identity, federation, least privilege, and not leaving permanent credentials lying around.

Read that stuff.

A service account key sitting in a repository is not "automation." It's a surprise for later.

Networking §

Same deal.

Cloud networking can look deceptively simple because Google has done a very good job of hiding a lot of the ugly parts.

You still need to understand the network.

If you don't know why traffic can get from A to B, eventually you're going to discover that traffic can also get from C to B.

Wat.

Know your routes.

Know your firewall rules.

Know what is public.

Know what is private.

Know what "private" actually means in the context of whatever service you're using.

And please stop putting management interfaces on the public internet just because you can.

Automation §

A big part of this book is Terraform, OpenTofu, Ansible, CI/CD, and infrastructure as code.

Good.

I've spent enough time around systems to know what happens when the infrastructure documentation is:

Ask Steve

or:

I think Dave built that

or:

Don't touch it

or my personal favorite:

Nobody knows what that does, but if you shut it off everything dies.

Infrastructure as code doesn't automatically fix bad infrastructure.

It does at least give you a fighting chance of figuring out what somebody intended.

You can review it.

You can version it.

You can reproduce it.

You can see who changed it.

You can hopefully rebuild it without finding a fifteen-year-old shell script named final2-fixed-new.sh.

This is progress.

Security §

Security is also all over this book instead of being stuck in one chapter near the end.

That is how it should be.

Security isn't something you bolt onto a system after everybody finishes building it.

Permissions are security.

Network design is security.

Where secrets live is security.

Who can deploy is security.

Where logs go is security.

Whether anybody notices that somebody changed a firewall rule at 2:17 in the morning is security.

Whether you can restore your data after somebody destroys it is also security.

A lot of security problems are really infrastructure problems that nobody wanted to call infrastructure problems.

Production §

The book also spends time on what happens after everything is deployed.

Also good.

Architecture diagrams are very optimistic.

Production is less optimistic.

Production has:

• expired certificates;
• full disks;
• broken DNS;
• quotas;
• weird latency;
• credentials that stopped working;
• credentials that unfortunately did not stop working;
• somebody changing something manually;
• databases with too many connections;
• containers restarting for reasons nobody understands;
• one region behaving differently from the other region;
• a thing marked "temporary" from four years ago.

This is normal.

Not good.

Normal.

The important part is whether you built the environment in a way that lets you figure out what happened.

Can you see it?

Can you explain it?

Can you fix it?

Can you undo the fix if the fix makes it worse?

Can you rebuild it?

Do the backups actually restore?

Not "are there backups," Do they restore? Different question.

You Do Not Need to Memorize GCP §

GCP is huge.

Nobody knows all of it.

If somebody claims they do, ask them about some obscure service and enjoy yourself.

The point is to understand the common pieces well enough that when you encounter something new, you know what questions to ask.

What does it do?

What does it talk to?

What identity does it use?

Where does its data go?

What can access it?

What does it log?

What does it cost?

What happens when it dies?

If you can answer those questions, you're most of the way there.

If you can't answer those questions, knowing what button to click isn't going to save you.

Rick §

I've known Rick for a long time.

We have had a lot of conversations about computers. Some of them were even useful.

He has strong opinions. I have strong opinions.

This works about as well as you would expect.

One thing we generally agree on is that technology should make sense, Not necessarily be simple.

Some problems are complicated, but you should be able to explain why the complexity exists.

You should be able to explain why you picked the thing you picked.

You should be able to explain what happens when it breaks.

And "because that's how Google does it" isn't really an explanation.

That attitude is all through this book.

Rick isn't trying to convince you that GCP is the answer to every problem.

He's explaining how to use it without creating a giant expensive mystery.

That seems useful.

So §

Read the book.

Build some stuff.

Use a sandbox.

Break it.

Break it again.

Look at the logs.

Remove permissions until something complains.

Figure out why it complained.

Restore a backup before you actually need the backup.

Run the Terraform plan and actually read it.

Do not just type yes.

Please.

And remember that underneath all of the product names, dashboards, APIs, YAML, Terraform, containers, managed services, and whatever new thing Google announced this week:

It is still computers.

They still break.

Have fun.

Stephen Brock
New York Genome Center