[Music]

All right, let's start with a quick

reality check. According to the latest

2025 developer survey conducted by Stack

Overflow, developers report being

blocked

not by their own skills but by delays in

access, broken environments,

delays in provisioning or endlessly

chasing approvals.

This is the kind of friction that they

face week after week in their workflows.

And these are costs that typically don't

show up in budgets but one every

developer feels

but also the kind of pain points we are

talking about are the one that are

leading to transformation in the way

organizations work.

According to Gartner by 2028 85% of the

organizations that have platform

engineering teams are going to expose

services to developers through internal

developer portals.

The good news is that um you already

have the foundation for it. It's your

existing Terraform setup. The primitives

that you're building on top of like

providers, modules, no code modules are

going to be the building blocks of

building an entire self-service platform

by itself. Today uh we're going to walk

you through how you can extend your

existing Terraform and empower your de

developers while keeping governance

intact.

>> Absolutely.

>> To introduce ourselves. So my name is

Barat Baratram Ramanatan and I am an

engineer turned seller turned marketer

and I will live I live in San Diego,

California. And a couple of fun facts

about me are one, I'm big into pickle

ball. Like so much so that I carry a

couple of paddles everywhere I go,

right? So if somebody is into pickle

ball and want to take me for a open play

this night, absolutely up for it. Two,

I'm also big into frozen yogurt. Like if

not speaking here, you might spot me in

one of the fro yo bars around the city.

Take a cup, pick the flavor, pull the

handle, and put my top in. And nothing

beats that uh level of self- service

that I like.

>> Yeah. Interesting. Let me go along the

same lines as well. Uh I'm TJ Raju. Um I

very similar to Barat started off as an

engineer transition to product. More

recently, my biggest focus has been to

make sure uh developers have a much

easier self-service experience. So

obviously focusing more on simplifying

that. Um, let me see what is Oh, I love

my uh espresso machine, right? It's a

morning ritual. I wake up in the

morning, make a shot or a double shot of

espresso.

Ooh, the um my steam wand where I can do

whatever and like grind. Obviously, a

lot of options. That's a whole separate

conversation or a whole separate talk.

Interestingly, uh if you look at the fro

yo and the frozen yogurt and the

espresso, we kind of get that

self-service experience, right?

>> Um what would it look like if that kind

of self-service experience uh was not

available to developers in

organizations?

>> You asked a good great question there,

TE, right? So, what happens when

developers don't have self-service?

Here's what happens. Companies end up

with ghost teams.

>> Mhm.

Since it's almost Halloween, uh, let's

actually talk about ghosts. Every

company has one, you won't see them in

the arcshot. You won't see them in the

budgets, but you have your ghost teams,

aka the developers that wait endlessly

for approvals or for environments.

So these are the kind of friction that

developers face week after week as the

stack overflow survey talked about.

Let's do the math here, right? So let's

take a midsized organization with around

800 developers with platform and

security team supporting the developers.

If you take roughly a couple of hours a

week per developer of idle time, it

quickly adds up to thousands of hours of

developer productivity lost.

Add on top of that your platform

engineers and the security engineers

trying to support the developers. It

leads to several thousands of hours of

engineering productivity lost which is

the equivalent of two or three full

capacity engineering teams that exist

but just don't deliver.

Now this waiting cost right the hidden

cost of waiting isn't random.

It actually comes from how organizations

typically typically work today. What I

call as the producer consumer and the

approver triad. On one hand you have the

producers who are the platform engineers

that are drowning in tickets are

building the same infrastructure over

and over again and again. On the other

hand, you have the consumers who are the

developers that are endlessly waiting

for en environments or approvals. But

right in the middle are the approvers or

the security and compliance people that

are babysitting approvals or rubber

stamping requests and often seen as the

people that delay everything in the

pipeline.

According to the Hashiarp cloud

complexity report that we just released,

if you haven't read it, totally

recommend it. Amongst the,100

respondents that responded to the

survey, 73% of them say their

developers, platform engineers, and

security engineers don't work in unison.

>> Yeah, honestly, we've talked to a lot of

customers where uh this has nobody's

happy in this situation. engineers feel

like the platform engineers feel like

they're constantly getting orders and on

the other side developers are constantly

frustrated and blocked because they're

not getting what they want. And

irrespective of how your organization is

structured, there are this compliance or

approvers that kind of feel like they're

bottlenecks overall. From a product

perspective, it just looks like a

complete ticketing black hole than like

any usable product.

>> Sure. So we have seen the triad is now

broken, right? So how do we fix it? The

good news is you don't have to start

from the scratch.

You already have Terraform the

foundation for your infrastructure

already today. Terraform is consistent.

It's codified and it's repeatable,

right? Which already are huge steps in

the right direction.

But Terraform by itself

doesn't deliver developer self-service,

right? You need additional layers on top

of Terraform to deliver end to end

developer self-service.

>> Of course, so the additional layers look

something like this, right? So we have

guardrails where we define uh enforce

policy as code and compliance baked in

so engineers can move faster while also

staying on the lanes on their own lane.

Uh governance by itself making sure your

uh approvals audit auditability and cost

controls are in place so that

infrastructure obviously is like easy to

use but at the same time more

accountable. And finally we have the

workflows itself. basically how

developers are consuming uh the

infrastructure that you were providing

be it backstage service now

waypoint or god forbid even github

actions we just want to make sure it's

absolutely easy for a developer to have

an idea and start running the

application

in a much more accelerated way

>> absolutely right so this is where the

magic happens where you have uh

terraform being the foundation

for your developer self-service.

>> Yeah, we want to use those guardrails so

you can take your existing

simplified even though I'm

oversimplifying it infrastructure is

code to the next level as a self-service

platform overall.

>> Absolutely. So when we talk about

self-service, right, it's easy for me to

stand here and lecture to you saying,

"Hey, like drop everything you do today

and buy X and Y to have self- service."

But that's not how engineering

organizations work. That's not how real

progress is made. Every platform, tool,

workflow or process that you're using

today, it didn't land by accident,

right? You had individuals or teams

doing due diligence to validate it,

doing P, and then you embraced that uh

decision.

So it's very unfair for me if I were to

say, "Hey, like drop everything and buy

this X and Y." What I've also seen work

is or what I've seen work is the concept

of meeting teams where they are in their

tools, in their products, in their

workflows, right? And you all have a

fantastic foundation in Terraform

and self-service itself is there's no

one path to self-service, right? Uh some

organizations may use uh developer

portals like backstage or other

commercial developer portals for

achieving self-service or some

organizations are deep into ticketing

systems like service now or Jira right

and they might be using self-service in

their own ways or some teams may demand

that uh self-service stay within the

terraform construct right irrespective

of which path you're going to take

terraform remains that foundation that's

tying all of those self-service together

whether it's developers clicking on

portals or submitting tickets through

ITSM based workflows or staying within

Terraform we are ready to show you how

you can achieve self-service by

extending Terraform from where you are

today so with that enough talking we

want to shift to demos and show you

multiple paths what we demonstrated here

in terms of a flowchart

in real action.

The first path we are going to talk

about here is developer portals.

When I say developer portals, one of the

names that is synonymous with the

developer portals is backstage.

It's a household name, right?

We have talked to a lot of customers and

customers love backstage because it's

open source and it's very flexible. You

can do whatever you want with it.

But also we have heard on the other side

customers complain saying hey like using

backstage is like shopping at IKEA. You

buy a big box millions of parts and it

takes endless time to assemble it. On

the other side of the spectrum you have

commercial uh developer portals. One of

the examples being Red Hat developer hub

right which is built on top of backstage

but it's batteries included or there may

be other developer portals right which

are also available in the market. The

point is to say not one is better than

the other. Each one's journey is

different as I said and depending on how

much you want to build versus buy again

it's going to be different.

So in this example, we are going to show

how Terraform acts as that orchestration

layer taking a developer portal to a

full-fledged self-service platform and

TA would talk us through the demo here.

>> Yeah, let's do it. Um let's actually

discuss about why this kind of makes

sense, right? So we have

organizations where developers are going

through multitude of tools and the ask

from platform engineers is pretty

simple. I don't want them to go through

all these tools. Can you give me a

solution that's exactly one portal by

itself? That way the it's much more

easier for developer to get started. So

let's actually jump in and look at an

example where a develop an AI engineer

is wanting some resources um and we will

provision it with uh Terraform.

So we are actually um the example by

itself goes through oh sorry I should

play it goes through um identifying the

provider we want to use. Um think about

creating some uh machine pools. Machine

pools are some a group of EC2 instances.

So I'm looking at the provider as a

platform engineer looking at the

provider in my private registry. Making

sure that you know I know all the inputs

and outputs necessary to set it up with

the developer hub by itself and making

sure everything is ready. Let's actually

switch back to the view with the

developer itself. So this is Red Hat

developer hub. So obviously we're only

going to look at self-service today. I

as a developer I'm focusing more on

cluster automation. Almost everything

here uh runs Terraform behind the

scenes, but we're f going to focus more

on creating that machine pool. So what

this template does is creates a machine

pool on an existing Rosa cluster. Um and

Rosa stands for Red Hat Open Shift uh

specifically on AWS. So I'm going in uh

providing my inputs. I'm choosing a

cluster name obviously uh uh machine

pool name. I'm choosing the instance

type. I'm choosing an ARM node. So my

machine pool name is also an ARM node.

I'm enabling autoscaling and making sure

I give uh the minimum and maximum

replicas. Okay, everything looks good

and I create. So now you can see the

progress of what's happening with

respect to the Terapform run by itself.

I can switch back to Terapform cloud and

look at um the plan being applied

within um developer hub. I get notified

as soon as the um machine pool pits gets

created on AWS. You can see how things

have been very simple. Developers don't

have to leave the platform by itself and

everything is readily available. The

good thing about developer hub is um

it's not just about bringing Terraform.

You can connect absolutely anything to

it. So think about developers wanting

VCS, bring it to developer hub.

Developers wanting like Jira, bring it

to develop hub. It's going to be one

singular portal where developers can

pick and choose everything that they

need.

>> All right. So that that was a very neat

demo, right? Like where a developer

expanded their machine pools on Red Hat

Open Shift on AWS, right? Very easy or

looked very easy because Terraform was

the orchestrator that was actually doing

everything behind the scenes.

And one of the key things that Terraform

brought to the table was taking the

concept of a developer portal and

extending it to a full-fledged developer

self-service platform. Right? So that's

what HCP terraform in that instance did

and developers got the speed and

simplicity without learning to use

Terraform or learning HCL.

platform teams remained in control and

keeping governance intact and which

results in faster, consistent and

scalable delivery if the teams

standardized on developer portals as uh

t showed an example being developer hub

but can be any flavor of backstage or

any commercial product that can

integrate with terraform through APIs.

Now that we have seen that, let's shift

lanes to the next path that we had in

the flowchart. Here we're shifting to

enterprise lane where uh one of the

examples that we want to demonstrate is

a ticketing system, right? Like service

now where um it's seen as the system of

record for governance and compliance.

It's the front door for it where all of

the requests, approvals, and incidents

live.

And the key thing Terraform brings to

the table is one of the key things that

the ITSM applications don't have is a

sophisticated

uh orchestration or automation system on

the back end which is exactly what

Terraform brings to the table taking

this ticketing system to a whole new

level of developer self-service

experience. And again switching back to

TA to demonstrate that.

>> Yeah, let's uh quickly talk about why

this makes sense. Right. So we we always

find it hard when we're pitching

self-service as a concept to

organizations especially when they're in

highly high highly regulated

environments

because the governance and the approvals

cannot be completely removed. So

self-service kind of needs to run in

parallel with the guardrails that

they've already set in place. So Service

Now is a natural partner here for us.

And let's actually go through a very

good example of how um it's helping some

of the organizations today. So we're

going to our Terraform catalog. We're

choosing our catalog items. Think about

catalog item as a template itself. I'm

providing some variables. So basically

what I'm trying to do is create an RDS

um resource. I give them a workspace

name and um I provision the workspace by

itself. But obviously we can go and see

how things are working on the terraform

side. But the good thing about service

now as it is is it doesn't stop there.

It also goes to day two oper ops of

things. So if say I decide to make a

change to the existing resource or just

the infrastructure itself. Let's

actually go to the module and you know I

decided to add a load balancer. So I

basically commit the changes. Um, I'll

go through the basic VCS process. I

create I cut a new release and obviously

that's what's happening. And once that

is done, it doesn't stop there. I think

sometimes we've hear this a lot. You

have to make sure you go to your

registry and you pin the right version.

If it's your latest version, you should

do that so that anything that's pulling

the no code module itself make sure it's

um using the version that is intended.

So now when I go back to um service now

I can update the existing workspace. So

I just give the workspace name I get

updated and it goes back to the existing

workspace and we can see that um the

load balancer gets added to the existing

workspace.

come here.

Let's actually like what while this is

going on, let's actually also look at

how things look like from the developer

perspective, right? So, this is how um a

developer gets started. So, until now,

we saw how like platform engineer sets

everything up. Obviously, we try to like

speed up a few things, but the process

is pretty much the same. So, the catalog

item exists. the developer can go in and

provide some input variables and then

things get started behind the scenes.

You can see how the no code module by

itself provides that a much stronger uh

ecosystem for service now.

>> Awesome. That that was a very neat demo

of how developers can still attain

self-service within the construct of IT

self-service management systems, right?

where the governance, the audit trails

and the controls remain intact and

Terraform powers automation, consistency

and visibility to the whole teams.

So this actually sort of wraps up the

path two that we wanted to show you and

the third path we wanted to show you is

where teams are huge in Terraform,

right? So they want to stay within the

construct of Terraform and expose

developer self-service to teams from

within Terraform and which is where HCP

Waypoint comes in. HCP Waypoint is a

Terraform native developer self-service

that standardizes and abstracts away

infrastructure from developers.

And

it comes in with a very neat simple GUI

or API access for developers

and the platform teams maintain the

guardrails that they need and stay in

control with security also weaved in.

So let's see the last demo here. Paige

being the product manager for Waypoint.

Uh she's going to be super passionate

about it and we're gonna uh take it home

with this.

>> Yes. Yes. Obviously my favorite um I I

don't want to repeat the same things. So

yes, the ask from the developers is

pretty same. They want to be able to get

started. They want to be able to have

like a single central place to get

started. But the ask for Waypoint by

itself is more about from the platform

engineers. So they have their existing

infrastructure already in Terraform.

They've heavily invested in Terraform.

They don't want to worry about new

products, new tools, setting everything

up. they want to get started as quickly

as possible and provide value to their

developers. Let's actually go through an

example of waypoint by itself.

So here waypoint also uses no code

modules as um as a starting point. So

this this example goes through um using

a no code module to create a template

that is going to deploy an ECS cluster.

So here's a template. When you create a

template, um, you get to see all the

developer instructions, the inputs and

outputs. Some of the inputs are already

defined by your platform engineer, but

you as a developer can provide some

inputs um, if it's requested by your

platform engineer. You can see that this

a template by itself has no action

associated to it. Once that template is

provisioned, this is how it would look

like as an application. And obviously,

the application has its own inputs and

outputs. So now let's go and pick an

action and associate it to an

application. This is what a platform

engineer would do. Provide the ability

to do one-click actions on top of the

existing applications. So I'm going and

applying these changes and my existing

application it sorry ex action is

associated with an existing application.

Let's actually go to the I'm quickly

showing you a private repository for

that um that we will be using. But let's

switch back to the action itself. The

the application itself within the

application once I go in as a developer

I have an action tab and obviously I

have an action that deploys to ECR. So

what it does is I as a developer have an

application. Think about it and as

simple as a to-do application that I'm

packaging and deploying to ECR. Um, this

is going to take a few minutes, but

let's actually wait and see if um, the

image shows up in the registry by

itself. Once that is done, we go back to

the ECS that we already deployed and

make sure it pulls the latest version of

it. Now you can see the task is uh,

running. So, we'll switch back to our

application, pick the URL endpoint, and

voila, we have the to-do application.

>> There you go.

>> So, just a quick recap of the demo

itself. So it's absolutely easy for

developer to get started because your

infrastructure already lives in

Terraform and we leverage primitives

that I told you that creates both golden

patterns and golden workflows that take

you from day zero to day two. Plus the

overall takeaway is it's it's much more

simpler Terraform native way to get

started with self-service without you

having to figure out new tools, new

services,

new integrations. So it's uh absolutely

easy to get started.

>> Over to Barat.

>> All right.

So when we started this session, we

started talking about the reality of the

status quo, the pain points developer

face, the ghost teams hiding within the

organizations

and the producer consumer and the

approver triad which wasn't working.

And we also saw the answer wasn't in

ripping and replacing tools, platforms

and processes rather extending the

foundation that you already have.

Terraform

we showed you through the demos that

self-service is possible through

multiple paths as there is no one

standard way to achieving self-service.

It can be through developer portals. It

can be through IT service management

applications or from the constructs of

Terraform itself.

different paths, different entry points,

but the same outcome being standardized

self-service without sacrificing

guardrails and governance.

>> But overall, this is the synergy that we

want, right? So producers get the

governance built in and on the other

side, consumers get self-service and the

approvers uh get everything god rails.

They're not being bottlenecks. They're

providing the ability to get started as

quickly as possible and Terraform

overall delivers this alignment across

team without compromise.

>> Absolutely. And all of these benefits

are not only qualitative, right? So

there are serious quantitative benefits

to achieving self-service using

Terraform.

Like we saw there were several thousands

of hours that were wasted because of

developer and engineering weight times

right with ghost teams and we all talked

about it.

>> Yeah. But it's not like the hours are

going away. It's just they just come

back as features shipped value delivered

developers moving faster. So it's going

to take minutes to get started for your

developers instead of days and the

overall toil is reduced.

>> Absolutely reclaim

almost all of those several thousands of

hours. It's like getting again as I said

two or three full capacity engineering

teams without hiring a single headcount.

Think about it. Think about all the

bonuses you would unlock

if you were to deliver that. Right?

to take us home, right? Terraform is

already the standard for your

infrastructure today

and it can be through the demos and the

talk track that we talked about today,

the standard for your self-service as

well. The shape it's going to take, it

depends on your tools, your platforms,

your workflows.

But rest assured, we are here to meet

you where you are and take you along

every step along the way.

>> Yeah, one of one of Barretts and my

important job is to always listen. So if

you're ever passing by, please stop us.

We would love to know where you are,

what's working, what's not working,

where you're seeing the friction. It'll

give us all that information so we can

take and build it and build a better

product that works for you.

>> Thank you so much. Thank you. Thank you.

And have a great rest of Kashikon. Thank

you.

[Music]