KATIE MCLAUGHLIN: I came out and I have to ask,
what exactly is going on?
MARTIN OMANDER: Well, Katie, I think
I made the perfect chocolate chip cookie recipe,
but I'm having issues with portioning and assuring
each cookie will bake and taste the same.
KATIE MCLAUGHLIN: I mean, the dough looks pretty good itself.
I'd love to get the recipe.
But as for portioning, I have some tools here
that might be able to help you get consistency
with each cookie.
MARTIN OMANDER: Oh, that would be great.
[MUSIC PLAYING]
KATIE MCLAUGHLIN: I didn't know you were an amateur baker as
well as being a software dev.
MARTIN OMANDER: That's right.
When my code is done, I turn it over to the customer.
They then deploy it in their cloud project,
according to a long list instructions that I've written.
But the problem is that these deployments often
turn out like my cookies--
uneven and not very good.
KATIE MCLAUGHLIN: That does sound frustrating.
MARTIN OMANDER: Yeah.
It makes the customer unhappy and makes me look bad.
I know my code is correct, but if it's deployed incorrectly,
it won't work.
KATIE MCLAUGHLIN: Have you considered using
an infrastructure as code tool?
Instead of your documentation, you could write it all as code.
Then you get repeatable deployments
in a machine-readable language.
MARTIN OMANDER: Oh, sounds great.
What's the tool?
KATIE MCLAUGHLIN: There are several.
But one that's widely used right now is called Terraform.
It supports many major cloud platforms,
including Google Cloud.
Let me give you an example of some
of the benefits of infrastructure as code.
This gcloud command will create a Cloud Storage bucket for you.
But if you run it again, you'll get an error
that the bucket already exists.
You could add manual checks around this command to ask
if the bucket already exists and create it if it doesn't.
But when you start adding these checks around all your scripts,
it gets complex and unmaintainable.
MARTIN OMANDER: So with Terraform,
I won't have to write so much shell code?
KATIE MCLAUGHLIN: Exactly.
In Terraform, you describe your desired state--
a bucket exists in your project.
Applying the Terraform manifest will
check if the desired state has been met.
If the bucket already exists, Terraform will take no action.
If the bucket doesn't exist, Terraform
will take the steps required to create it.
MARTIN OMANDER: But what if I have
things that are different between deployments,
like Google Cloud project ID?
KATIE MCLAUGHLIN: You write Terraform manifests in HCL--
HashiCorp Configuration Language--
which allows for such complexities,
like variables and calculated fields.
Terraform will also work out the dependency graph
itself when working with multiple resources.
Some resources have to be created before others,
and some resources create data that will
be used by other resources.
For example, if you have a Cloud Run service that
relies on a Cloud Storage bucket,
the bucket has to exist first and Terraform
will work that out.
If you have, say, a deployment of five Cloud Run
Functions that are independent of each other,
Terraform will run those creations
in parallel, which will be much faster than creating
each of those one by one.
MARTIN OMANDER: Can I configure other Google Cloud products
with Terraform?
KATIE MCLAUGHLIN: Of course.
It isn't just limited to serverless products.
With the Google Terraform provider,
you can deploy virtual machines, networking,
and other complex infrastructure that
would be downright annoying and frustrating to have to manually
deploy over and over again.
MARTIN OMANDER: Oh, nice.
So could Terraform also help me with setting up
test environments?
KATIE MCLAUGHLIN: I mean, sure.
Just consider what needs to be different in test.
You may want to add some variables to, say, create
a smaller Cloud SQL instance, rather
than a production spec one.
But with Terraform, you can easily create duplicate setups,
much like a cookie cutter in your baking adventures.
MARTIN OMANDER: That sounds great.
Can I also tell Terraform to build my containers?
KATIE MCLAUGHLIN: Well, Terraform deploys existing
assets, like containers or compiled code.
It presumes these resources already exist.
There are a couple of ways that you can get around this.
You could have your existing artifact creation process
and then manually run Terraform when required.
That works well if, like you said,
you deliver your code to a customer.
Or you can add Terraform to your existing automation,
for example, as a step in your Cloud Build configuration.
This works well if you're doing in-house development
with continuous deployments.
MARTIN OMANDER: So I should convert the long list
of installation instructions in my readme file
to a Terraform manifest?
KATIE MCLAUGHLIN: It's probably a good idea.
Not only will your deployments get more reliable,
you can store your live infrastructure
configuration settings along with your code
in source control.
I've left some links in the description for you.
MARTIN OMANDER: All right.
I will read up on that.
So could you show me an example of a Terraform
manifest for a serverless web application?
KATIE MCLAUGHLIN: How about we catch up next week,
and sit down and work with some Terraform code,
and try deploying a few things?
MARTIN OMANDER: Yeah, that would give me a better
idea of how Terraform works.
Let's do it.
KATIE MCLAUGHLIN: Great.
[MUSIC PLAYING]