Terraform: Declarative Infrastructure Automation
Key Points
- Sai Vennam from the IBM Cloud team introduces Terraform as an open‑source, declarative tool for automating infrastructure and services.
- He contrasts Terraform’s “declare the destination” approach with imperative step‑by‑step automation, using a rideshare analogy.
- The example infrastructure includes a VM, a Kubernetes cluster, and a VPC that interconnect them, illustrating the desired vs. current (empty) state.
- Terraform workflows consist of three main phases: writing the *.tf* configuration file, running **terraform plan** to compare desired and actual states, and executing **terraform apply** to provision the resources.
Sections
- Terraform Declarative Automation Overview - Sai Vennam introduces Terraform, contrasts its declarative model with imperative scripting using a rideshare analogy, and outlines a sample setup involving a VM, a Kubernetes cluster, and a VPC.
- Terraform Apply Phase and Modules - The speaker explains how Terraform’s apply phase uses provider APIs and your API token to provision resources and generate output variables (e.g., URLs), while emphasizing Terraform’s modular, pluggable design and strong community support for cloud providers.
- Terraform DevOps-First Load Balancer Deployment - The speaker explains how Terraform’s code‑plan‑apply workflow lets you iteratively add a load balancer to an existing VPC/VM/Kubernetes setup, showcasing a DevOps‑first method that prevents configuration drift.
Full Transcript
# Terraform: Declarative Infrastructure Automation **Source:** [https://www.youtube.com/watch?v=HmxkYNv1ksg](https://www.youtube.com/watch?v=HmxkYNv1ksg) **Duration:** 00:08:44 ## Summary - Sai Vennam from the IBM Cloud team introduces Terraform as an open‑source, declarative tool for automating infrastructure and services. - He contrasts Terraform’s “declare the destination” approach with imperative step‑by‑step automation, using a rideshare analogy. - The example infrastructure includes a VM, a Kubernetes cluster, and a VPC that interconnect them, illustrating the desired vs. current (empty) state. - Terraform workflows consist of three main phases: writing the *.tf* configuration file, running **terraform plan** to compare desired and actual states, and executing **terraform apply** to provision the resources. ## Sections - [00:00:00](https://www.youtube.com/watch?v=HmxkYNv1ksg&t=0s) **Terraform Declarative Automation Overview** - Sai Vennam introduces Terraform, contrasts its declarative model with imperative scripting using a rideshare analogy, and outlines a sample setup involving a VM, a Kubernetes cluster, and a VPC. - [00:03:04](https://www.youtube.com/watch?v=HmxkYNv1ksg&t=184s) **Terraform Apply Phase and Modules** - The speaker explains how Terraform’s apply phase uses provider APIs and your API token to provision resources and generate output variables (e.g., URLs), while emphasizing Terraform’s modular, pluggable design and strong community support for cloud providers. - [00:06:13](https://www.youtube.com/watch?v=HmxkYNv1ksg&t=373s) **Terraform DevOps-First Load Balancer Deployment** - The speaker explains how Terraform’s code‑plan‑apply workflow lets you iteratively add a load balancer to an existing VPC/VM/Kubernetes setup, showcasing a DevOps‑first method that prevents configuration drift. ## Full Transcript
Hello everyone, my name is Sai Vennam
and I'm with the IBM Cloud team.
Today we're going to be talking about Terraform.
Terraform is an open-source tool
originally developed by HashiCorp,
that enables you to automate and manage your infrastructure
and platform and services as well.
It does all of this using a declarative language
and that's the first thing we're going to focus on
when we go through our example
to go through Terraform.
So, I generally like to start with an example here.
So, say you're driving in your car,
trying to get from point A to point B.
Generally you would follow a set of instructions, right?
So, going from point A to point B,
you have to take a left turn,
get on the highway, take this exit
- you end up at your destination.
Now, that's kind of an imperative approach to automation.
The way Terraform does it:
imagine you called a taxi or a rideshare service
and told them exactly where you wanted to go - point B.
The car, or the driver, then takes care of the rest
- you don't have to worry about every step of the way to get there
and that's the approach Terraform takes.
That's why it's so effective
at managing your infrastructure.
Today we'll start with an example.
Say you've got 3 different resources
that you're trying to spin up as part of your infrastructure.
We'll say you've got a VM,
we'll also say you've got a Kubernetes cluster,
and say that they're networked together using a VPC
- or "Virtual Private Cloud".
So, current state: nothings there.
Desired state is this set of infrastructure.
So, in Terraform there are going to be 3 major phases,
and we'll go step-by-step.
The first phase:
you actually have to create the the terraform file.
So, we'll start with that -
where you actually write or code up that Terraform file.
Now, in this Terraform file we're going to have
3 major resources, right?
So, we'll start with the VM
and a set of arguments to support that.
Things like the name, and networking, data center,
that kind of thing.
We'll have the Kubernetes cluster,
a set of arguments for that,
and then finally we've also got the VPC.
It's probably going to refer
to some of the network settings of the VM and the Kubernetes cluster,
but it's going to network those together
and so it has arguments to support that.
So, that's your coding phase.
Say you've got a Terraform file ("TF" file),
with these things defined.
Next up, we've got the "plan" phase.
Now, this is an actual Terraform command.
So, in the TF CLI, or "Command-Line Interface",
you can run "terraform plan",
and what it's going to do is it's going to compare
the desired state to what actually exists.
So, on day-zero it'll notice that you have
none of these resources,
so it'll say, "Hey, you have to create all of them".
So, create the VM,
create the cluster,
as well as create the VPC.
So, it has a plan -
and it tells you, the user, this is what it's going to do.
Next, if everything looks good,
you'll do the "apply" phase.
This is another Terraform CLI command.
In the apply phase you can actually
take those resources and spin them up.
So, that's exactly what's going to happen:
Terraform is going to work against the cloud providers
using real APIs - your API token -
to spin up these infrastructure resources
and it's going to output some interesting or
auto-generated variables along the way.
So, for example, maybe the Kubernetes dashboard URL,
or maybe even a URL to access your application,
but, regardless,
it's going to output a number of these output variables.
So, that's generally how the terraform workflow goes
to get you from point A to point B
in a situation where you had nothing
and now you have something.
So, that's what I wanted to start with.
Next, I want to go into the fact that Terraform
has a strong open community
and it's pluggable by design.
So, by "pluggable" essentially what I mean here
is the fact that it's made up of
modules and resources where
you put in input variables and output comes out,
as well as the community is out there,
and cloud providers are out there,
building and supporting things called "cloud providers",
or "providers" in the Terraform world,
to enable you to connect up to any cloud
and automate infrastructure there.
So, in this process,
we actually made something called a Terraform module.
A Terraform module is a way of grouping together some terraform automation.
So, we've got a terraform module here.
It actually takes a set of inputs
and also creates some output
and as part of every module,
- well, you can define this, but,
in general, when you're working with cloud providers,
and using Terraform,
you'll also define what's called a "provider".
Now, a provider can be a number of things,
but in our case, we are using it as a cloud provider
to connect up to a given cloud.
So, that's the first thing that a provider can do is
connect you up to IaaS providers
- IBM Cloud, or AWS, or Azure -
it enables you to connect up to some infrastructure provider,
spin up things like VMs,
or that kind of thing - maybe bare metal.
You can also use a provider, in the Terraform sense,
to spin up platforms as well.
So, it enables you to manage, for example,
Cloud Foundry running in the cloud.
Finally, you can even manage SaaS offerings.
Things like CloudFlare, or other software services,
can actually be managed by Terraform.
So, although Terraform is considered to be
an infrastructure automation tool,
it's expanded its role
to support other types of providers as well.
So, essentially, we've got our flow here,
our module, inputs, and outputs,
and so we've got a kind of pipeline
to be able to spin up resources.
The last advantage I want to mention here with Terraform
is the fact that it enables you to essentially
have the best practices for DevOps.
So, we'll say "DevOps first".
Now, let's take an example for this.
Now, in our example here,
we did a day-one kind of deployment,
- nothing to something.
But let's say we're going back and iterating on this.
So, we've got our VPC,
we've got our VM,
as well as Kubernetes.
Now let's say we're iterating on this and we
want to create something new on top of this infrastructure.
Let's say we want a load balancer.
So, that's our desired state.
So, we'll do our three phases,
starting with the code phase.
So, we'll say here that we want a load balancer,
and we'll have set of arguments to support that.
When we get to the plan phase,
Terraform is going to realize,
"hey we actually already have the VM, Kubernetes, and VPC",
so it checks the current state of the world
and realizes that all we need is that new load balancer.
So, it will say, "hey, let's just add the load balancer this time around",
and, as a user, you'll confirm that make sure it looks good,
go to the apply phase, go ahead and apply it,
maybe some more config variables will come out
for this new capability that you added.
So, essentially, with Terraform
you have a DevOps-first approach,
one of the key advantages to this
is that it enables you to avoid potential "config drift" -
that's when the configuration that defines your infrastructure
actually doesn't match what's actually there.
So, as long as all changes to your infrastructure
go through the Terraform file and Terraform pipeline,
you can essentially eliminate the risk of configuration drift.
In addition, since we've set up
a module where we can take input variables and have a final state,
what we can essentially do is recreate this
- maybe switch up the environment variables a bit
and then create a whole other environment
that looks just like this
but this time we can make one for Test.
And maybe this one was Development,
and we can do that again for maybe Production.
It's another advantage of taking a Terraform
approach to infrastructure automation:
it enables you to put DevOps first.
Thanks for joining us for this quick overview of Terraform.
If you enjoyed this video
be sure to check out our other video on infrastructure as code.
As always, if you like this video, or have any comments,
be sure to drop a "like" or a comment below.
Stay tuned and subscribe for more videos like this in the future.
Thank you.