Hello, Steve Weaver here with a demo

that shows how Terraform and IBM

Turbonomic can be used together to

reduce infrastructure cost while

maintaining performance across your

organization.

As cloud usage scales, so does cost,

often in ways that aren't efficient.

Many organizations provision virtual

machines based on guesswork or peak

demand, but then fail to scale down when

demand decreases. This results in

performance risks, wasted compute

resources, bloated cloud bills or

underutilized infrastructure. The

Turbonomic provider for Terraform is a

plug-in that enables Hashikop Terraform

to interact with Turbonomic, which in

turn communicates with cloud services

such as AWS, Azure, and GCP to optimize

your cloud infrastructure.

By integrating the Turbonomic provider

for Terraform into your infrastructure

as code, you not only gain intelligent

optimization recommendations, but you

can also apply those changes

automatically either using Terraform

runs or safely in Turbonomic.

So let's begin the demo by viewing our

Terraform code in GitHub. We specified

the Turbonomic provider and we're using

it to both provide recommendations on

sizing for our EC2 instances and to

allow continuous validation checks in

HCP Terraform. We're also using the AWS

provider to define and manage AWS

resources. In this case, to launch and

configure an EC2 instance in AWS.

Before we define our AWS resource

though, we're going to add a Turbonomic

data source. The Turbonomic Cloud Entity

recommendation is a specific type of

data source provided by the Turbonomic

provider. It's designed to get scaling

recommendations for cloud entities from

your Turbonomic instance which will then

be applied during a Terraform apply

command.

When the provider does not find an

entity with a specified name, it returns

a null value. In such cases, the default

value T3 nano is used. So this typically

occurs during the first run of a

Terraform apply. The AWS resource block

is then used to define and provision the

actual EC2 instance using the

recommendation from Turbonomic defined

in the data source above to identify the

instance type.

In our case, since we haven't run a

Terraform apply yet, we can expect a T3

nano to be provisioned.

Finally, you can use the HCP Terraform

continuous validation feature to ensure

resource configurations are consistent

with Turbonomic recommendations.

The health check runs periodically every

24 hours and it can be run from the

continuous validation page in HTTP

Terraform.

Because we've configured the turbonomic

provider to fetch turbonomic

recommendations using the data source we

defined earlier in the script. We can

add a check block in our code to perform

an assertion check on the EC2 instance

using turbonomic recommendations.

So here you can see we've added a

turbonomic consistent with

recommendation check assertion. Okay,

let's take a look at the result of our

initial run in HTTP Terraform. In the

Terraform plan section of the run UI, we

can see that we are indeed creating an

EC2 instance in AWS and it's defaulted

to a T3 nano as expected based on the

behavior of the Turbonomic provider.

With the Terraform apply finished, we

can see that the resource has been

created in the apply stage. We can

verify that the EC2 server has been

created by checking in the AWS console.

And there it is. And again, as expected,

it's a T3 Nano. Jumping over to the IBM

Turbonomic dashboard, we can see that

Turbonomic has discovered all of the

resources in our AWS account and is

actively managing them to see if they

can be optimized based on real-time and

historical data. We have three virtual

machines active and we can click on the

chart to drill down to see the details.

Immediately, we can see that we can

achieve savings by changing the instance

type of our example virtual machine from

a T3 nano to a T3A nano. We have two

options here. We can execute the action

from Turbonomic to update the instance

type or we can go back to HCP Terraform

and initiate the Terraform apply from

there. In either case, we'll bring our

instance in line with Turbonomic

recommendations and avoid any potential

drift that may have occurred from

updating the instance type manually.

Looking into the data in a little more

detail, we can see that the T3A Nano

provides the same level of performance

as the T3 Nano, but at a reduced cost.

Let's go and perform the Terraform plan.

and apply from HCP Terraform. Drilling

into the Terraform plan this time, we

can see that the Turbonomic provider has

automatically updated the T3 nano

instance type to a T38 nano in line with

the recommendation we saw in Turbonomic.

Okay, we've applied the change. Let's go

and take a look at our AWS console to

make sure that the change has been made.

And yes, it's there. The T3 Nano EC2 VM

has been upgraded to a T3A Nano. Let's

verify that the change has been picked

up by Turbonomic.

Drilling down into our virtual machine

inventory, we can see that there's no

action for our example VM this time. And

taking a look at the details reveals

that the VM has been updated to a T3A

Nano as expected. Finally, let's go back

to HTCP Terraform to check on the

assertion we added to the code. This

will show up in the health section of

HCP Terraform under continuous

validation. Our assertions will be

checked automatically every day by

default, but we can also run them on an

ad hoc basis by clicking on the start

health assessment button.

As expected, our check passes

successfully. We've optimized our

infrastructure.

And so that's it for this demo. We've

seen that leveraging the Turbonomic

Terraform provider with HCP Terraform

provides significant benefits by

embedding continuous optimization

directly into our infrastructures code

workflow. It transforms the way

resources are sized and managed from a

manual guesswork process to an automated

intelligent one. Thanks for watching.