Episode 12: CDK for Terraform and two pizza teams

Published: Tuesday, Dec 16, 2025 • Duration: 61 minutes • Season 1

CDK for Terraform and two pizza teams

Download MP3 | Watch on YouTube

https://github.com/hashicorp/terraform-cdk/commit/a0c56138e2b4c7b6c128bd7ba08a8e317df852af

Trying to plot the changing Infrastructure landscape.

Watch on YouTube

summarize "https://youtu.be/rM2pj0JKc0g" --timestamps --slides

This discussion explores the volatile state of the Infrastructure as Code (IaC) ecosystem following IBM’s acquisition of HashiCorp and the subsequent sunsetting of the CDK for Terraform (CDKTF). The speakers analyze the technical and organizational shifts driving developers away from traditional configuration-based tools toward programmatic frameworks like Pulumi and AWS CDK. They examine the trade-offs between developer experience and operational control, the rise of platform engineering, and how modern “two-pizza teams” are redefining the boundary between application code and infrastructure.

Slide 1

The Fall of CDKTF and the Rise of Alternatives

The conversation begins with the news that IBM decided to sunset CDKTF, a project that was a collaboration between AWS and HashiCorp. The speakers note that the repository had been neglected for some time, remaining pinned to Terraform version 1.6 while the main project advanced to version 1.13. This lack of maintenance occurred despite the project being positioned as a way to bring the benefits of the AWS Cloud Development Kit (CDK) to the broader Terraform ecosystem. The sunsetting event triggered significant reactions on platforms like Reddit and Hacker News, where many users expressed that the tool was “half-baked” or simply not being used. Pulumi is identified as a primary beneficiary of this fallout, having launched years earlier with a more mature programmatic approach to infrastructure. The speakers suggest that for those still tied to the Terraform ecosystem, the move toward OpenTofu is becoming increasingly logical following HashiCorp’s shift to the Business Source License (BSL). Terraform Hashikorp language is a horrible way for developers to manage their infrastructure. This sentiment reflects a growing frustration with the limitations of HCL (HashiCorp Configuration Language) for product engineers who prefer familiar programming languages.

Slide 2

Pulumi and the Open Source IaC Landscape

Pulumi is highlighted as a strong alternative that supports a wide array of languages, including TypeScript, Python, Go, and even YAML. Unlike HashiCorp’s recent licensing changes, Pulumi’s source code remains Apache 2 licensed, allowing it to position itself as the “real” open-source option for infrastructure. A key advantage of Pulumi is its ability to interact directly with Terraform backends, allowing organizations to run both tools side-by-side during a migration rather than requiring a total rewrite. The speakers also discuss SST (Serverless Stack), which originally built abstractions on top of AWS CDK but has recently pivoted to use Pulumi as its engine. This shift is significant because it moves away from the “all or nothing” database-transaction style of CloudFormation, which can often get stuck during rollbacks. Pulumi and Terraform offer more granular control over state refactoring, which is essential for large-scale enterprise environments. While Pulumi offers a free open-source tier, its commercial model involves a managed cloud UI for state and orchestration, similar to Terraform Cloud.

Slide 3

Defining Developer Experience in Platform Engineering

The speakers attempt to map various tools on a scale of Developer Experience (DevX) versus operational features. They define the role of a platform engineer as providing tools that allow developers to take full ownership of their services in production. High-DevX tools like Vercel, Netlify, and Fly.io are praised for their simplicity, often requiring only a CLI and a basic configuration file. However, these tools often lack the “operational depth” required for complex infrastructure, such as fine-grained control over database bootstrapping or networking. AWS CDK is placed high on the DevX scale but lower on operational flexibility because it is backed by CloudFormation, which can lose track of resources if logical IDs change. The speakers argue that a good developer experience is not just about ease of use, but about the “agility” it provides to a team. They note that many organizations struggle with “click-ops,” where developers manually configure resources in the AWS console because the IaC tools are too convoluted to use effectively.

Slide 4

The Complexity of Low-Level Resource Management

A major criticism of Terraform is that it forces developers to manage every single low-level API resource, such as IAM roles, trust policies, and security group rules, just to connect a simple Lambda function to an API Gateway. This “low-level” perspective is a barrier for product engineers who want to focus on application logic rather than infrastructure plumbing. The speakers discuss the varying quality of Terraform providers, citing the Snowflake provider as an example of a tool that can be “experimental” and prone to recreating resources unexpectedly. They describe the “nightmare” of trying to manage everything through Terraform, such as running SQL queries to configure database extensions, which requires complex networking tunnels and security compliance measures. Some argue that IaC should be reserved for stable, long-lived resources like databases, while more dynamic application components should be handled by higher-level abstractions. The lack of automated testing in many Terraform setups further complicates long-term maintenance, leading to “complex interfaces” that are difficult to refactor after a year or two of development.

Slide 5

Strategic Infrastructure Mapping for the Enterprise

When considering how a CTO should manage hundreds of AWS accounts, the speakers weigh the benefits of Pulumi, SST, and AWS CDK. Pulumi is noted for its “on-event” hooks, which allow for dynamic logic during deployment—such as automatically adjusting configurations based on the number of availability zones in a specific region. This is contrasted with Terraform’s deterministic, static nature. AWS CDK uses “context providers” to achieve a similar effect, querying the environment during the synthesis phase and storing the results in a cdk.context.json file to ensure builds remain deterministic when checked into version control. The speakers discuss the “Two-Pizza Team” model used at AWS, where the team responsible for the product also handles observability, paging alerts, and reliability. In this model, the separation between “infrastructure” and “code” disappears. For organizations with strict silos—where security teams own IAM and networking teams own VPCs—adopting these integrated programmatic tools can be challenging, as they require a platform team that understands object-oriented programming and software testing rather than just system administration.

Slide 6

Integrated Deployments and the Construct Hub

The final segment focuses on the “Construct Hub,” a registry for AWS CDK, CDKTF, and Projen constructs that allows teams to share high-level integration patterns. Unlike the Terraform Module Registry, which is often limited to HCL, the Construct Hub supports multiple programming languages and leverages native package managers like NPM and PyPI. The speakers highlight the “Construct Hub” itself as a prime example of a mature serverless application built by a two-pizza team, featuring automated failovers and detailed runbooks. They argue that the traditional separation of infrastructure and application code is fundamentally “wrong” for modern DevOps. The whole deployment process belongs to the product team not to the infrastructure team. This integrated approach is facilitated by the AWS CDK asset pipeline, which bundles application code (like Docker images or Lambda zip files) directly with the infrastructure definition. While some criticize this for making deployments dependent on local build environments or rate limits, the speakers view it as a vital feature for developer autonomy. The discussion concludes with a look toward the future, where AI might assist in governing these complex environments by guiding LLMs with organizational rules and “sandboxes” to prevent rampant, unmanaged resource creation.

Model: google/gemini-3-flash-preview

Transcript (auto-generated from YouTube captions)
You see the little voodoo mask over
there where I pray. I do my silent
prayers and curse the forces of the day
at Hashi Corp.
>> Yeah. So that CDKF thing uh got you
activated. So did you what did you do
after hearing that news? Cuz I thought
that project I I was I I think we
discussed this project. No one was using
it. I mean, or what was my impression?
>> Triggered. Triggered.
>> Triggered.
>> He's pushing buttons, right? This guy
woke up fresh. I don't know what I don't
know what you want to, you know, get off
before we start.
>> Okay. So, anyone who's not aware, um,
and this is my version of the story,
right? My my my side of the story. Um
when I woke up on Thursday last week um
IBM
has decided to sunset CDKTF
even though that the week before that
they were all there with and um with all
the people from AWS and if you don't if
you're not aware CDKTF kind of
collaboration between AWS and Hashi Corp
because CDK is is um is an AWS uh
toolkit cloud development toolkit and
only really successful for AWS cloud
itself with AWS CDK there is some CDK TF
for Azure but you know there's bicep and
and Google I think they they try to use
config um what's it config manager or
config connect it's like crossplane or
um based kubernetes based
um so yeah it was sunset to be honest I
have been trying to fork the repository
and nobody did anything the repository
had not received any love or any
updates. It was still pinned to version
1.6 of Terraform and I think they
released 1.13 lately.
>> Uh most of the features that came to
Terraform since 1.7 and I think 1.7 is
when the whole BSL fork happened uh I
think with 1.8.
>> So ever since then
>> you might as well go open tofu right at
this point.
>> Absolutely. So, so the the m so after
the sunset event um which was posted on
Reddit and hacker news and on LinkedIn
uh most of the comments on on Reddit
terraform obviously was nobody's using
it right uh no let it die right hate
those people why would people say that
right and and then
>> several of course Puli jumped on the
opportunity it's like yeah CDKF is like
two years younger than Pulumi so Pulumi
came out first and it was kind of like a
halfbaked effort from Hashi Corp to try
and emulate what Palumi provides. I
don't think that's really the case. I
mean maybe it was
>> actually I've not used Palumi in anger
so I don't know what to say about it.
>> Yeah. So I did a very fun talk at DevOps
Day Singapore about how Terraform
Hashikorp language is a horrible way for
developers to manage their
infrastructure and goodness that there's
only few other options such as Pulumi
but nobody used it and somebody in the
audience obviously took offense to that
and um told me to do a a co-presentation
for the AWS uh community day in
Singapore in June and um and I got
schooled
cuz um I was like um this is how I have
to do it with CDKTF and he was like oh
in Pulumi it's literally like one line.
Oh okay. So he kind of showed me the way
and I have to say Pulumi is impressive.
Um the only problem is and kind of how I
changed my presentation because my
presentation was all about how so much
easier it is to use CDKTF than Terraform
modules. And the fact is that he was
showing all of my examples with Pulumi
and they looked even easier with Pulumi.
No, they look the same. Let's be honest,
they look the same. Um so then um I
changed my pitch mid presentation to
basically say so many organizations have
like two to three years Terraform
footprint with like you know known
automation solutions such as Atlantis or
GitHub workflows that are all built
around Terraform you know security
scanners all built around Terraform IC
so it's very hard sell as a product
engineer who wants to build a product
and leverage
you know, a queue and a lambda and the
tool has to be connected and you don't
care how, right? And you do do
serverless. You're building this
beautiful API gateway with all of its
endpoints going through ECS Fargate
containers for long running jobs or
directly to lambdas for a quick response
and you don't care to learn about five
different Terraform modules with 40
different variable inputs and how do you
configure an API gateway, right? So for
serverless, you know, AWS CDK is
amazing, but you know, try to come to
your platform team and say, "Yes, I know
you guys have this amazing Terraform uh
pull request previews and and and
scanning code and and and all this
stuff, but I want to use AWS CDK. I want
and then they have to start supporting
cloud for uh or even you know more go
towards them and say I want to adopt
pulley and now they have to think about
pulley um into this pipeline. Although
that pulley's strong point is that they
make um trans migration from Terraformed
to their cloud very easy. Obviously they
are backed by the original Terraform
providers. So they have a lot of
migration paths.
>> Yeah. I'm just looking at Palumi now.
They seem to support every language
under the sun
>> even YAML. Yeah, you can even put YAML
as an input and you get uh you get
infrastructure as code.
>> So do they do they have tools to to
convert the Terraform into into
>> language? They have a very powerful I
think they can even interact with the
terraform back end directly right so you
can have them side by side you don't
need to migrate everything immediately
the only problem is you have to now sign
a contract with Palumi and then you have
to you know
>> so you're so the big problem with Palumi
is that it's a commercial non-free thing
right
>> well when when the BSL announcement came
basically when Hashi Corp announced that
the source code was uh available but not
allowed to be used in competing compar
commercial platforms,
>> the business license that they put on
Terraform. Pulumi made a big
announcement how they are the real free
version, the real open-source
infrastructure as code. So, I can't
claim um
>> Oh, so so they're open. Okay, hold on. I
got to check out the GitHub now.
They're open source.
>> Yeah. And they um they also another
famous pro for Palumi is that SST which
is a I think originally SST they are the
people that build serverless.tf TF uh
serverless not serless.com.
>> Yeah. SD, right?
>> Yeah. Okay. So, so the source code is
Apache 2 licensed. Okay. Okay.
>> Yeah. So,
>> but I'm guessing they have have a model
because I see they see looks like they
have like a a cloud UI, right?
>> Yeah. So, they're they're like Terraform
Cloud, right? They they give you the
ability to very quickly get started.
Just sign up to their cloud and get your
Pulumi code ready. And the terraform
cloud is is essentially non-free, right?
>> Yeah. They both under management pricing
models, right? I think we talked about
that
>> very first time back in September when
there was this uh announcement of open.
>> Okay. So, Palumi seems to be in a good
position to deal with the CDKTF fallout
then, right?
>> Yeah. And they even have made their AWS
CDK adapter generally available. So
CDKTF had this in in um technical
preview since its inception and for five
years it was still in technical preview
until it got uh you know shut down
together with CDKTF. So the the adapter
basically your team can write AWS CDK
code and the adapter converts the the
generating cloud formation into pulley
equivalents allows your teams to quickly
convert your AWS CDK to pulley as well.
still that doesn't sound quite right to
me because even if you convert your
cloud information to Palumi, how the
hell are you going to, you know?
>> Yeah, it's I think this is just a um
>> marketing
>> just marketing and just to allow people
to quickly do a PC on Palumi and then
see the benefits of the cloud. I guess
there is a benefit compared to cloud
formation, right? It's very frustrating
cloud formation sometimes when you kick
off a roll out and then it gets stuck
and it does a roll back and you have to
wait an hour and and it's it's this
cloud for all or nothing behavior that
is sometimes very frustrating the
ability for cloud form to you know lose
track of resources if the logical ID
changes. So that's where like terraform
and puli are like advantage have
advantages because of the the way they
track state. They allow you to more
carefully refactor your state, but they
don't have this all or nothing guarantee
like cloud form, right? Cloud formation
is really like a database transaction.
You kick off a roll out, it's going to
go through. If it doesn't, it's going to
try and roll back, which honestly also
doesn't always work, right? Sometimes
there will be something blocking it.
Yeah. And then the roll back fails. So
that's where people are like, oh, the
AWS CDK is awesome. Cloud formation is
horrible. um and then they maybe have a
lot of issues with like managing the
overall teams
>> um interaction with cloud form stack. So
pulley is in a really great position.
They also have SSD.
>> So SSD originally serless were built on
cloud form and SAML um SAM sorry not
SAML uh SAM the
>> yeah I'm I'm an AWS SAM guy kind of guy
to be honest.
>> Yeah and SST was kind of like
replicating SAM on top of AWS CDK. So
you don't have to work with the AWS CDK
abstractions but for example you can say
I want open next deployed as serverless
on top of lambdas. So SST gave you that
um it take care of everything like I
want an application right I don't care
about lambdas
>> I'm just clicking around Palumi I guess
looks like it's done a quite a good job
I'd say on the face of it
>> it's just it's just the ball breaker is
the fact that they will
catch you in their in their web of the
the
>> cloud costs
>> the cloud costs
>> so there's there's no there's no open
source
>> there is cloud so
There was one of the uh misconceptions I
had as well about Pulumi was that I
heard that it was expensive and you
can't self-host but you can you can move
your cloud hosted back end to an S3
bucket but the the the counter to that
is then but now you have to manage all
of this cross team uh rolebased access
control you know all the enterprise
features that come around
>> oh yeah software
>> orchestration and all that sort of
stuff.
>> So so then you need to take that on
yourself. Yeah. And and in that aspect
in in the Terraform ecosystem, you have
a lot of open source projects, right?
And you can choose between um Spacelift
um you can choose between Terra Team or
um you you can choose Terra Mate or
Terra Grand or Terra Grand Scale. So
there's so many options around Terraform
and for Purimi we didn't have that many.
However, Spacelift and others say yes,
you can also manage pulley with us.
We're also hosting an S3 bucket and
we're coupling it together with your
terraform. So, so yeah, that's that's
why most of the reactions Yeah.
>> So, the
let me I'm I'm just
let me just share my screen. I was I
just I just want to map out where
infrastructure is at then.
Sorry.
And then we haven't even talked about um
system initiative and uh and
>> I hope I hope to catch up with um with
Adam at the config management camp in
Gent.
>> Yeah, you give you a beautiful demo.
>> Let me just trying to think.
I don't know how to do the scale here,
but I was I was going to put like maybe
this terraform here
and then this Palumi here
and Palumi has seems to be the last.
>> I would put AWS CDK all the way on the
right. That is like the benchmark for me
>> because it came first.
M no I don't think I think Palumi came
be around the same time or at the same
time or little bit earlier to AWS CDK
maybe
>> okay that okay so we have to pre prefix
this with AWS infrastructure
>> and then I mean I was going to put it
here but like anyway
so most
>> yeah for me it goes more to the right to
puli because because it it has this
little additional library like next to
AWS CDK Here you can put SST because
that is on top of poly
>> SST.
>> Yeah.
>> Okay. So I was going to maybe put use a
scale of like I don't know features
because you I mean let's be we've talked
about this before but you can't do
uh well lambda and serless very easily
on the terraform level.
So you need something like
>> it depends what features you're talking
about because features are related to
developer experience or operational
experience um and and how you like do
>> um previews plan previews and things
like that.
>> Well
and rolebased access control.
>> Um I'm thinking developer experience. I
mean what do you mean operational
experience like how easy it is to to
manage or
>> to refactor? uh for example let's say as
a company we start with a single
offering and we build a VPC with like
some lambdas and so on and then later on
we spin off
>> I would always feature agility
operational then
>> yeah agility
>> yeah so so
>> so you're you're only looking at one
dimension operational features
>> yeah well I I sent you the link but I
mean be good to explore
the dimensions.
>> I uh yeah, let me try and add the
developer experience dimension.
>> So, um
>> just bossing you around.
>> I mean, cloud form is probably at the
bloody bottom, isn't it? I mean, it's a
nightmare to work with.
>> No,
>> cloudformation is at the same level as
Terraform. Come on, be honest.
>> Going to give you that.
I've refacted Terraform plenty of time.
>> Okay.
>> The tooling is good. cloudformation like
you it's you.
>> So we I'm going to create a separate
scale for developer experience.
>> Yeah.
>> Oh wow. Hyperland does not
>> I'm going to I'm going to put AWS SAM in
the middle just because
>> I'm on Arch by the way. I'm going to say
like six times during this call.
Do you know I started I started my
channel by making Archix installed
videos for noobs like you.
>> No, I didn't have to install it.
>> Oh, yeah. You're using Omar. You're
using uh what's it called?
>> Omari.
>> Yeah, that's that's how way he pronounce
it, right?
>> Yeah. But you were sending me
screenshots of Hyperland crashing or
something, right?
>> Yeah.
>> That's why I'm on Arch.
for the uh crash experiences. I think
Arch cannot run this website. Uh cannot
run um Xcoly draw.
>> What?
>> Maybe developer experience goes the
other way or I think the same direction.
>> What's okay define developer experience.
>> Yeah, as a DevOps engineer you should
know this.
>> Well,
>> okay.
Basically we are not devops engineer we
are platform engineers and one of the
things that we should focus on is to
provide our developers the tools so that
they can take ownership on the services
that they built and run in production.
>> Okay. Okay.
>> And the developer experience comes with
um you know the the easiness at which
they can define their production
workloads.
>> Yeah. So my my points of what my point
of mental reference is like you know net
lefi and u up cell and things like that.
>> So essentially what what they need to
twiddle with is is a config yaml and uh
a CLI tool or something like that and
that that's it right that that's that's
my point of reference. Of course, so
many companies just do it so much more
convolutely convolut in a awkward way.
Fly.io.
>> What did you say you you you called
>> Netlfi? Netlfi.
>> Yeah. So, they all work in a similar
way. There's some CLI and there's some
config YAML
>> or toml.
Maybe I should do a scale for cost
like or enterprise adoption or something
like that
because some of these things like Palumi
is going to get expensive.
Enterprise
I don't know. So, anything I select
doesn't show up on my on my browser. I
think there's a problem with Chromium to
be honest. Um, I'm on a Chromium browser
>> on a fork
>> and uh and doesn't render properly
sometimes.
>> So, Palumi is going to be expensive. I
think cloudformation terraform is a bit
tricky cuz
No, I mean Terraform is good because you
don't need to pay for rum.
No rum.
I think you cannot put operational
features AWS
above terraform
or maybe
>> I I mean I love it. I love it
>> because it's backed by CFN. So you must
have the same problems like losing
logical um logical ID for resources
loses the actual resource ownership.
Although they have added a lot of new
features to cloud form to help you
refactor your code. But yeah, the main
reason there is that organizations
constantly change the names. Oh, we did
a we we had um an offsite of the with
the sea level team and we decided to
merge our AI team with our data team and
then all of these resources that were AI
team.
>> I love what you I love what you said uh
a few chats ago with changing of IDs.
You were saying that like uh you should
just use labels, right, to address
resources
>> and not and use opaque IDs. I mean I
really that stuck with me. I need to do
that more.
>> Yeah, I think so.
>> Oh, and convince people you don't have
to name a bloody bucket this certain
way.
>> And that's something that cloud form
kind of forces upon you or AWS CDK,
right? By default, it doesn't even allow
you to define the physical ID of
resources. And it and then I had some
some um colleagues and they were like,
"No, no, this load balancer has to be
named exactly like this because I need
to be able to find it in the console."
And I'm like, "No,
>> no,
>> no.
then you have to deploy the same stack
twice and you you get an error because
the load balancer identity like physical
ID does already exist like
>> you know and then I got this whole
discussion with the team manager after
the guy that tried to do what I I
wouldn't allow him to do raised it up to
our our manager and then said yeah come
on Vincent we we're not deploying the
same application twice in the same AWS
account and it's like Well, yes, we are.
And we are consolidating more of our
infrastructure. So,
>> okay. I mean, I think you're being a
little bit danty. I mean, to be honest,
I make assumptions right now. The thing
I'm working with and I need to make it
uh talk to each other at some point
soon. Okay. So,
um yeah. Uh well, I thought I mean I
like to fill this void. I do think AWS
Okay. AWS is so specific to serless,
it's probably not worth beating around
about.
Uh
I'm probably going to copy.
This is so difficult because the
functionality is not comparable, is it?
>> Copy it or just drag it.
>> Oh, sorry. I meant to copy it. Hold on.
Let me copy my
Okay. I don't know. We've just been
dragging things around. Maybe we should
we got to start somewhere. Let's
>> say what we what we mean by this.
>> Okay. Your developer experience.
Um I'm I'm really surprised you put
Terraform right rock bottom. I mean
Terraform has an incredible developer
experience.
>> No,
>> it does.
>> It's a horrible developer experience.
>> It's the worst.
>> Okay. So, okay. I I think Okay, you're
coming from a developer point of view.
Okay. You're like the guy says like I
don't understand this. What is this TF
file?
>> Why do you s make a whiny voice when
you're the emulator developer a product
engineer?
>> What I'm saying is Terraform um is
exposing every single API resource of
the cloud of the SAS that you're
interacting with, right? Either the
cloud provider or um you know whatever
um is it or whatever you're you're
you're talking to. Every single API
endpoint must be configured and then
must be linked together. So if you're
setting up an API gateway and a lambda,
you must set up the IM role and the IM
policy to you know provide lambda
permissions. Then you have to do you
know the lambda trust policy. Then you
have to set up lambda permissions to
allow the gate API gateway service to
invoke the lambda that you have to do
with terapform.
>> Yeah. And then you have to do it for
every possible scenario that those
things can be combined together, right?
>> Yep. Yep. Yep. Yep. I I'm just trying
I'm just trying to come up with the
right word. You have to basically
>> manage everything and it's
>> Yeah. As a developer and many people
always came to me when I was purely
Terraform only guy um and said like look
I'm not like you. I cannot read the API
docs or the provider docs and figure out
how I need to comm connect connect all
of these resources. Let me click ops.
Let me go into the AWS console, click on
this, then click on that and then after
that I will try to capture everything.
>> On the subject of click ops, is there
good support by any of these tools to
basically capture the state from from a
from AWS? I think I think you should ask
uh system initiative to give you that de
demo because that's one of the things
that he's advertising right like look
people have clicked and now you have to
you know control it so here you go
system initiative doing that for you is
there anything that does that really
nicely
>> I don't think so I don't think any of
these tools help you fix whatever
somebody clicked in clicks up still in
but
>> some of these tools allow you to avoid
clickups to basically start the correct
way um by defining it with SSD because
they give you that ability to say like I
had a gateway.
>> I mean I I got a soft spot for click ops
in a way just because I was on a
>> I was on a job and it took it took me
literally like a week just just to
toggle something. Wow. I'm I'm
exaggerating, but it took a while.
>> And I thought to myself,
>> yeah, absolutely. So that's the problem
with a lot of these infrastructure as
code libraries is that they're built
from um a very low-level perspective and
you can either and a lot of the tools
that are being built right now is to you
know reflect the reality of this
nature of the cloud changing things
under the hood right if you create an
RDS instance it's going to auto upgrade
to the latest Postgress version and then
your Terraform's going to go like nope
this is supposed to be Postgress 15.
What are you doing running Postgress 18
over there? You know, let's delete this
database and recreate it.
>> Yeah, actually
>> dealing with dealing with data and any
of these tools makes me a bit sweaty
>> like uh
what happened.
>> That's interesting because that's
exactly the argument that somebody made
just now on a thread on Reddit because
I'm I'm 24 hours on Reddit obviously. um
that
he just made the argument that the only
place you would use something like
Terraform is to manage databases.
>> What?
>> Yeah. Because he says like everything
else is so dynamic and most of the stuff
you shouldn't be doing with IC. IC
should be done for these like um
resources that take need additional like
operational
>> Okay, maybe he's got a point because
it's got it's got more
>> control
>> stability aspects to it. Yeah. Yeah,
because you're right. You do a because
with IC it's often very close to
GitHubs, right? You need to make a
source code change,
>> bring it to production.
>> We're using Terraform to manage some
data right now and and uh our basically
one of our main guard rails is the plan,
but no one reads the plan. No one reads
the plan. Like we like we got like a
nice GitHub summary to say like, oh, do
you know you're recreating resources
here?
and they just go, "Yeah, whatever.
Apply."
>> That's weird because like first off, why
is it recreating resources? That means
that and that's the hard thing about
Terraform.
>> Well, I I didn't want to mention the I
didn't want to mention the provider, but
I'm I'm going to mention it. It's not
going to incriminate anyone, but this
the we've been working with the snow
snowflake provider and it just wants to
recreate things very easily, but it it's
it's it's a complicated environment to
be honest.
>> Yeah. Some providers have really low
quality.
>> Yeah. And the snowflake one is in
maybe someone has made a video about it,
but it's it's it's came out of like I it
came out of like the uh the Chan
Zuckerberg Foundation or something like
this. It's hasn't been maintained very
well. Then Snowflake itself eventually
adopted it.
>> LOL. Oh, that's so funny. I I I used and
there's so many experimental features in
it, it makes you very nervous. I mean,
and then Snowflake is only used by the
like the biggest enterprises ever.
>> Wow.
>> We It's a very It's a very weird setup,
but I guess it is it is better than
managing it by by hand, I like to think.
But still at the end of the day the the
provider just seems to do SQL calls or
or like it it it lacks so much
functionality you're ending up having to
write these like what do you call like
SQL execute blocks here and there and
everywhere which
>> yeah so so this is kind of where I feel
when I started on my Terraform journey I
was like terraform everything right you
create an RDS instance you need a
database in it well we're going to
define the terraform provider for
Postgress and we're going to connect it
to your RDS instance and we're going to
create a database and we're going to
create the plug the extensions that need
to be active on that database and it's a
nightmare because now when you ever you
run Terraform you have to have a tunnel
to connect to the Postgress instance and
you know once you start doing compliance
you need you need all types of security
around that and and this is the type of
stuff that it shouldn't be part of
Terraform right like running SQL queries
through a provider just to me already
after using it for 10 years seems
something like done that been there
never again you know
>> yeah okay I think we all agree I agreed
I'm agreed with this whole developer
experience at the bottom here um
>> convinced you
>> but but at the same time the things that
we put at the very top don't really I
mean that's for very narrow use cases I
feel like we need to have maybe two axis
at this point because we we need
we We need like oh god
one access to sort of
we need we need the vertical access to
talk about um what you can do like you
know AWS
feature
>> but that's what the defex or what
>> scope or something like well like the
trouble is is that versal is good at
setting up a website but you can't like
run a database So I mean probably I mean
maybe it does support database
>> because is this as a higher level
abstraction right?
>> Yeah. So I understood. So so basically
it needs to go down
you know it needs to sink down here.
Well well with with
>> you just moved you just moved my devx uh
scale to the right saying feature scope
and and you just
>> and then here I would say de dev
experience because we need to basic okay
we can discuss this later. I think your
feature scope is the devx and your your
x-axis should be the operational
features that we we were just talking
about
>> because because the feature scope here
like Versel has um great Devx so it
needs to go up there but horrible
operational experience such as like I
need fine grain control to bootstrap a
database I can't do that because first
is very high level and under the hood
it's going to create some type of data
store and they take care of it which is
like a trade-off right
>> yeah they're going to you like three
different types of data store and you
don't care how they're
>> Yeah, you're right. You're right. The
operational stuff comes. Yeah. Yeah.
You're right. You're right. You're
right. I didn't know what SST v2 is.
What the hell is that? That's just
serverless, isn't it?
>> So, basically the the way I understand
it cuz I only came became familiar with
SSD when my my friend introduced it to
me. Um originally I think the server the
people that built serverless.com
they created um SSD on top of AWS CDK. I
think serverless was using SAM and maybe
cloud form directly and then they with
some scripting around it and then they
created um SST which is just instead of
directly writing cloud form they would
just leverage all of AWS CDK because AWS
CDK is this amazing library that gives
you these beautiful integration
patterns. If you need to create a lambda
and a gateway and you just connect it to
it's going to take care of everything,
right? So you don't have to generate
every single cloud for resource, you
just say here.
>> So it's like a it's another sort of
CDK/palumi
type type offering, right?
>> No, it's it's on top of so originally it
was on top of cloud for then they
rewrote it on top of um on on on AWS CDK
and then they rewrote it on top of FUMI.
So SSD is like the AWS CDKL2s. Um but
they're trying to go like like Versel
kind of in the middle.
>> They are.
>> Oh, we don't have Palumi on this top
thing. I mean Palumi needs to be up here
or something. I don't know.
>> You're you're like yeah I was trying to
duplicate it but it didn't manage to
duplicate it. So yeah, Palumi and SST on
operational I think there would be the
same.
Okay.
>> Yeah, SSTV1 was on AWS CDK and SSTV2 is
on top of Pulumi. Um, so
>> how do you get exposure to all this
stuff, man? I feel like I'm doing a lot
and I don't get to touch some things.
Okay. I guess you attend a lot of talks,
don't you?
It was my colleague uh sorry my ex-
flatmate who um who who pivoted you know
originally started with Amplify then
with AWS CDK and then he says you know
SSD is this amazing thing.
>> Oh my god. Amplify. Oh my god. Sweet
Jesus.
>> Yeah. But Amplify also completely wrote
itself on top of AWS CDK. Yeah. And then
they just became like uh this portal
that you it's kind of like I think AWS
answer to Versel. This basically like
allows you to create your front end to
deploy it.
>> Yeah. That's true. That's true. But I I
never appreciated the stack.
>> Okay.
>> Yeah, they completely changed the stack
because originally amplify was doing
cloud formation and now it's just doing
like CDK stacks and then it's just
allowing you to manage your front-end
deployments, you know, your S3 contents
and your CDN configuration from an
abstract level. A bit like Versel really
like I think amplify is really like
Versell.
>> No, I think I think Vel is much better
than amplify.
>> When was the last time you looked at
amplify? uh years ago and I I had I
think I think I have a GitHub project
about it and then it was impossible to
like just maintain it. So basically,
>> yes, I know that's what amplify used to
be. But what I there was this uh lady
who posted on LinkedIn access to a Udemi
workshop that she had just published
which was AWS AWS CDK and Amplify. And I
and for free you got access for like two
days or something like that. And so I I
did a speedrun through it like literally
in a day just crushed it. And um I went
through the whole AWS CDK thing and the
Amplify side of things. And this
literally just like a month ago, not two
months ago.
>> Yeah. And and it's really like amplify
when I looked at it and I haven't used
forcell but um it really is like oh I
want to do blue green experiment. Oh I
want to do this. It just takes care of
everything under the hood for you and
you you just go here's my website source
code and it just take care of the whole
>> anyway. So we can put bloody amplify
here. Gez.
>> Yeah. Amplify V2 or whatever. Amplify
current
whatever
new one. Okay.
So,
okay. So, now now if we
and how do we account for the the cost
of things? I guess let's let's just
focus on operational features and and
DevX. Can are you able to copy and paste
into this one so that we have a a better
graph here? or shall I just do it?
>> Uh, yeah. No, my my my Chromium is un
unresponsive.
>> Okay, so if I maybe I put Terraform on
the bottom here.
Cloudformation too. God, it's got a
terrible experience.
Palumi
looks like it can do a lot.
Wait, it's going to look the same, isn't
it?
It's going to look the same. There's no
there's no DevX and operational features
seems to be the same thing, right?
>> I mean, Palumi and Palumi cloud I guess
and Terraform and Terraform cloud maybe.
Uh
so Palumi I would I would pose in terms
of operational features a bit higher
than Terraform and in terms of DevOps
kind of in the middle. Um but but
ultimately I can't help but think
there's no the major differentiator
short is going to be is just going to be
it's just going to be price isn't it? We
you you like if you were like a an enter
like a Fortune 500 company,
you're not going to use um
well, you can't you can't use VEL and
and things cuz that's not going to be
enough
and
you're not going to use AW CDK and
Terraform is as we know limited.
But then you're gonna you're gonna
basically pay for Palumi. Okay, this I'm
not too sure where I'm going with this.
>> Okay, I
>> I also wanted to tie this into AI
somehow, but it just it look it looks
like Palumi is in a very good spot. And
we haven't even talk about we haven't
even talked about Kubernetes, but I
don't want to talk about Kubernetes.
Looks like Palumi is is on a I don't
know if can can we invest in Palumi?
Looks like it's in a really good spot.
>> Are you building a tech radar? Maybe I
should pull up the some famous tech
radar.
Um, hold on. Uh, what was I? Ah, AWS
CDK.
>> Not on the current edition.
>> I would give AWS CDK highdevx but very
low operational experience. And then SST
given it's on on Palumi would be a
little bit less on the DevX side because
they don't they didn't build all the
same like service levels but on the same
level as Palumi in terms of operation
because it lose uses Palumi under the
hood. Yeah.
What else is there?
Does it make sense?
Where are you? I don't see you anymore.
>> I'm here. I'm here. I was just looking
at um Oh.
What the Why does it say data dog?
>> What the I
>> I was just I was just looking at the uh
>> I think you're on this
>> the tech radar.
The thing the only thing it says on
platform to adopt is uh ARM in the
cloud. which sounds a bit weird
sometimes. I wonder if these people that
make those T radars really know what
they're talking about.
I don't know where which one you're
looking at, but like I'm just guessing
now.
Uh,
okay. Let's tie this back to AI. So we
we just riffed about how
Palumi ST is is in a good spot. We we
Oh, we should we should put system
initiative somewhere here, right?
>> Maybe you can take this this slide back
when you talk to Adam from system
initiative where you put it.
>> I'm not that I'm not that happy here,
but like okay, what okay say you're the
what do you call it? the chief
technology officer of a of a big company
that that had a whole bunch of AWS
accounts
>> only AWS.
>> Let's say it's only AWS. Just just to
keep the conversation sane.
>> Yeah.
>> How would you begin to manage it? Like
let's even go even more bizarre. Let's
say like, oh Vincent, we need to build
up to 100 accounts and we need to do
this in the space of six months.
and or three months and you choose the
technology to do it with can I assume
that Vincent would choose Palumi
and there's no budget I mean
>> it would be between Palumi and or
between SST and AWS CDK yes if there's
no budget limitation
maybe more towards SST then
>> but SST doesn't have a a cloud and man
and governance and or
>> I think they may have runners but They
they basically
originally SSD they had their own like
deployment pipelines but since they
completely pinned themselves on pulley I
would imagine that they are completely
powered by Palumi deployments.
>> Okay it sounds like Palumi. So okay so
you would explain once once more why SST
and and and Palumi and AWS CDK and cloud
for what the relationship is right you
understand AWS CDK. So AWS CDK is to
cloud formation what SST is to pull. In
other words, Pulumi gives you the
low-level concept of an IM role, an IM
policy and a bucket and an API gateway
and a lambda. And then SST gives you the
concept of I have an um an API gateway
that's backed by a lambda and write
>> higher level patterns, right?
>> Yeah. SSD level two level threes and
>> yeah and then and then Puni they have
two different providers they have the
pure terraform provider converted on top
of their own engine so they they run the
engine the configuration that you
provide is in programming language or
YAML or whatever they they run that
inside a runtime they convert your
program into configuration that then
gets um executed right so if if you look
at it like cdktf I to me pum and CDKTF
is very similar um is that you write
TypeScript code or Golang code or Python
code and it generates configuration for
the Terraform provider and PUMI their
internal representation of whatever that
cloud plug-in is right if they targeting
AWS it's a plug-in for AWS this they
originally just ported the provider AW
for Terraform for AWS right PMI was just
porting the Terraform provider and then
building a programmatic interface on top
of it I think they may like refactored
the way that that works because now they
have all kinds of hooks system. So while
you are your program is executing some
of your program execution is happening
while it's deploying things inside the
cloud. So if you look at Terraform, you
you have a configuration and then the
provider is executing the configuration
and then the provider is you know config
like sending the request to the API do
this then send the request to the API do
this right and Terraform
does not really have a lot of features
that allows you to mit deployment
execute this function and then based on
the output do something else right by
design because originally Terraform was
meant to be very deterministic very
predict predictable so that you are able
to to know this is the exact
configuration what I want all of these
resources to look right right but with
pulley you have like this on on event
type of things um you can you can hook
into the process and if you're deploying
to a region that only has two
availability zones you automatically
like um adjust the configuration towards
it right so yeah so pulley has these
like events um and I think AWS CDK has
similar things because while you are you
know as as a as a product engineer
defining this is what I need to deploy.
It will also hook into the target
environment depending on how you are um
calling the the constructs. They can
basically decide that okay I I just I
just downloaded the whole VPC setup. I
know there's two subnetss and they are
into the these these availability zones.
I know all of this information which is
called the context of the environment
that you're deploying into and they can
reconfigure or generate cloud form
stacks accordingly.
>> I didn't even I've never written a CDK
like that. Um
>> yeah that's that's what context
providers do and and then to make sure
that still deterministic that context
that was used to basically determine how
the uh cloudformation stack is generated
is also stored on disk. So you can then
put that into your GitHub um into your
version control sorry git and then you
can um you know rerun the context lookup
to update your context. So then if you
want to change things for example maybe
maybe one day you are targeting
Singapore region and it only has two
availability zones uh but the next time
Singapore introduced the third
availability zone and you don't want all
of your cloudformation
>> you're blowing my mind here CDK you
would check in something into your in
>> the context yes so so
>> I've never seen that done I mean the CDK
is all managed in cloudformation
is how I understood it
>> CD no CDK generates cloudformation but
in the process of generating cloud form.
It can do some callouts to your
environment to determine how to best
generate the cloudformation.
>> Do you have an example of a context
checked into Git? I guess it's all going
to be
>> Yeah, the one that I I was just talking
about and the example that they give why
you should checking your context is
exactly what I just said like let's say
that the new availability zone is
introduced and that kind of like deter
subnetting logic that you have a whole
like subnet for this particular tier of
of of your
>> blowing my mind. I didn't really know
about this context. I have I have to
look it up. And then and then and then
when you do CDK bootstrap it it creates
like three different bloody places for
things or something if I remember
correctly.
>> Yes. because CDK is very enterprise
focused allowing you to exactly control
how to um you know how the the the
bootstrap happens right like what are
the basically CDK has this asset
bundling pipeline and that's why it
bootstraps so many things because if you
do terraform you just need to find a way
for example to put an object into a S3
bucket so that your lambda can point to
it and then deploy the source code from
the S3 object or maybe your lambda wants
to be deployed from a docker image so
you need to use ECR So these asset
repositories uh the ECR and the S3
bucket are very important in the way
that you deploy your code and this is
more important if you do serverless
because you know you have all of these
snippets of of of code that that need to
be coordinated together with your Lambda
um configuration and the environment
variables and everything right so AWS
CDK has a built-in asset pipeline and
and and part of the things that it
bootstrap is all of the necessary
supporting um architecture for that
asset pipeline it will create an ECR
repository so that it you know, so that
they can build a Docker image part of
the, you know, bundling aspect of your
of your application and then deploy that
that Docker image in or push that Docker
image into the um into ECR the asset
registry for Docker images or you know
push the bucket maybe which is an ES ES
build bundled NodeJS with all of its
dependencies and whatever AWS SDK is
external needs to be external because
that's provided within the runtime. So
all of that is taken care of by AWS CDK
because it has this beautiful asset
pipeline, right?
>> Well, I noticed it in one in my
workplace that when AWCDK deploys this
Fargate pattern or whatever, it's
building the Docker image in the same
pipeline. And I thought to myself,
>> yeah,
>> that's not cool.
>> It depends. So as soon as the Docker
file build fails with some rate limit,
then then the whole deployment fails.
That's a joke in my opinion.
>> Uh to be honest,
if you are coming from a developer
experience perspective, not being
bothered by how exactly your code gets
bundled up and and made available to be
deployed is kind of a feature that you
want and that's why they have it, right?
This asset pipeline thing. From looking
back when I started with AWS and
Terraform, I very strictly said, okay,
your code, for example, your website and
your bundle, the way that like assets
are getting deployed is very
disconnected from your infrastructure,
right? Classically,
>> I'm not so sure I'm a big believer that
because because these things,
>> it's wrong. What I just said is wrong.
When you start out, you think like I
have a very very strict separation
between infrastructure and the code
because my infrastructure is, for
example, my Kubernetes cluster. It's my
S3 bucket and my cloud cloudfront uh CDN
setup, but the actual website that's
managed by the product team that need to
be deployed and rebuilt is decoupled
from it. Right.
>> Exactly. Exactly.
>> Exactly. And that's wrong.
>> What? absolutely wrong because if you're
doing um actual DevOps culture two pizza
team where you have site reliability
engineer as part of the product team the
whole deployment process belongs to the
product team not to the infrastructure
team.
>> Yeah. Okay. Okay. But there's more to it
because you don't want a product team to
manage Kubernetes. But okay.
>> Why? I mean like sure you don't want
them to damage to manage Kubernetes.
That's where you as a platform team are
provisioning the the the Kubernetes and
the integration points like the
Kubernetes endpoint where they need to
target their deployments towards, right?
>> But we're not talking about Kubernetes
here, right? We were talking about an S3
bucket and the contents of that S3
bucket or a lambda and the contents of
that lambda together with like let's
imagine that you're you're deploying
this API gateway like this magic. I feel
like we need another scale about how the
how the organ how the organization is
done like if it's if it's like team team
topology or whatever.
>> Yes. Because that's what a lot Ben
Israeli figured out after he left AWS
and why AWS CDK works so well in in AWS
but doesn't work in other organizations
>> because
>> because in AWS they have a two pizza
team they have an S sur uh as part of
the team. The team is responsible for
all of the observability for every
paging alert that happens. It goes to
the product team. They are deploying 100
times a days. They get the alerts. They
have their their product uh you know
reliability and their runbooks.
Everything is managed by the team. But
in a lot of organizations there's still
a very strict separation where you have
a security team responsible for the IM
roles and other team responsible for
other things and that's where team
topologies are are are then making it
obvious.
>> Yeah. I mean, to be honest, I'm I'm been
working with strict separation, you
know, separation of duty type outfits
for like a decade now. So, I'm pretty
I'm pretty like
I don't know how to describe I I I don't
even know what it's like to be in an
autonomous team anymore.
>> Yeah. So, so
>> it's it's crazy that AWS can do that in
a way considering you know
>> you know where I like
>> very nicely and a public artifact of
this as an example as part of AWS CDK
and the the whole CDK ecosystem they
built this thing called the construct
hub. So the construct helper if you go
to constructs.dev
I think it is is a place that you can
find every single construct that was
built and remember constructs are
usually you know L2s or L3s built by the
community. Yeah. Constructs.dev. So
these are amazing. Um
they are they're like the terapform
module registry but instead they it
doesn't cover a niche technology by one
company IBM. um and then pedled by other
companies like Spacelift. Instead, this
is using registry of .NET, Golang, Java,
Python, TypeScript and its best-in-class
um you know artifacts or yeah artifactor
um artifact registries. So across all of
these so so this construct hub is a
complete public GitHub repository and if
you go to that public repository of the
source code of the construct hub you see
that it's a massive serverless
application um basically there's um
there's
what is it it's it's a kinesis stream
subscription or it's a stream
subscription
>> to npmgs
uh publish published packages right so
so if you go to the source
um you can find and the reason this is
public is because you can deploy this
within your organization. So it tells
you exactly how you can operate this
within your organization. For example,
you have your own private registry of
npm your own net registry that you don't
want to be public and you want to make
it this construct hub available within
your enterprise you can do that and and
it has documentation with guide books
exactly what is the alert that's set up
like there's a backup bucket uh in in a
separate region. So if a region is down,
all of your registry downloads are still
available in a separate region and this
is how you do a failover and this is how
you do that. These docs are amazing. So
when I saw this, I was like now I
understand how a product team can build
something and has like very detailed
runtime guidelines on on how to observe
and react to alerts and why that alert
exists because it creates all of the
Cloudatch alerts. It tells you exactly
why the alert is triggering and how to
handle that that instance. So that's on
one side like a two pizza team. You want
to see a beautiful implementation or a
product delivered by a two pizza team,
you look at the construct hub. It's I
looked at it, it was amazing.
>> So I mean these the these people the two
pizza team has to be like super mature
to take take on all these
this uh this responsibility I suppose.
But mean but meanwhile most most
companies are designed to to silo
responsibility for for lots of good
reason
>> because once you start talking about
compliance and and those initiatives
then now you need to align and you need
to like do across all of your your teams
you need to make sure that the the
technology they are using are are are
similar so that you can push through
huge initiatives. you know, you have
have one team doing it like this and
another team doing it all on on Google
Cloud, you know, it's it's extremely
difficult difficult to get like um
compliant and I guess like AWS is really
good at that as well. Um but most
enterprise main main you know business
is not about doing all of that, right? I
mean AWS is a company providing cloud
services and they they are building
cloud services and they have a great
team to build cloud services. So that
makes sense.
Most companies the DevOps um you know
type of of of initiatives are
part of an operational team that is
short staffed and that needs uh
alignment across the teams and centrally
controlled and um and that's where team
topologies come in right. So, so which
so which tooling by that explanation
would they gravitate to in your opinion?
I believe with with things like AWS CDK
and Construct Hub, you can have a
platform team that builds really
powerful constructs for the rest of the
organization. constructs that make sure
that the the patterns used by the
product teams are supported and can be
easily integrated within compliance
initiatives and and zero trust and all
those you know crossorganizational
um effort that you don't want to go
through every team and try to fix them
up. You want to give them an approved
and and rubber stamped.
>> Yeah, that's exactly what happens in my
current gig right now. We create
constructs for for other teams to use.
>> Yes. And and that requires your platform
team not to come from pure operational
background, right? requires your con
your platform team to understand how to
do object-oriented programming, how to
define an interface, how to integrate
that like iterate on that interface, how
to do you know contracts across teams,
how to test against those contract
contracts and then you come to an
organization that's using Terraform
because the old system administrators
that like config files never wrote uh
actual object oriented interface or
whatever and then they cannot deal with
CDK. they cannot deal with like all of
these like program.
>> Yeah. Well, we we tr we uh
>> I I sound because I'm I'm a bit
frustrated because I was in a lot of
those things where I try to to introduce
this and and I always get like the
feedback like you know Terraform is
simple why do you make it so complicated
but in reality Terraform is not simple
and one year down the line two years
down the line you have Terraform modules
that have such a complex interface
there's no testing because you have
never thought about like actual software
testing on your infrastructure as code
Okay, cool. But you're actually doing
infrastructure as
>> comp. We need and we need to wrap up in
five minutes. I need to run out and drop
my kids off to school. But like
>> but just on this point
uh you you develop constructs for for
for um for other people in your
organization to use, right?
But but the trouble is the trouble is is
that
um
let me just get this clear. Do you
expect people to use your constructs via
a config.yaml or do you expect them to
use like a a like a Python uh library or
something?
>> Yeah. So I think there's very different
personas. Um, and I think as a platform
team, what you should be building
maybe exposes a flat interface like a
YAML, but I don't like YAML. At least it
should be JSON schema type YL so that
they get an error if they use a field
that is not there, right? You can do
YAML uh
>> with JSON schema or use most companies
use pedantic. Pedantic
>> pedantic on YAML. I never tried that.
>> Yeah. Yeah.
>> But how does pedantic work? It must must
have some type of schema for the data
structure behind it.
>> Yeah. So so basically pedantic if I
understand correctly
it uh it has its own model. So so the
the you the way they use pedantic is
that you you read in that YAML and then
you compare it against the model and the
model is very powerful. You know you can
you can express anything in that model.
>> Okay. And then the model basically tells
you if if it's um yeah how what what all
the configs going to be and and if the
config yl is valid and
>> s so forth and it's used a lot.
>> Yeah. So what the way I handled like the
problem with YAML with it being so
unstructured is that we use YAML often
as an input for generating
um well if you put it on top of
Terraform you can do the Terraform plan
preview to see how how messed up you did
when you agreed to it.
>> But it it sounds like such a this whole
this whole area with the governor. Okay,
I do want to bring this back to we I
guess we can continue but like what what
what of all these technologies that we
sort of try to map out here badly what
do you think AI is going to help any of
these problems that we have at the
moment like the teams
the devx
did
>> so I did a podcast about a year ago
about the AI and the infrastructure and
They compared it as a new way of doing
click ops. Basically, you just have
these rampant LLMs just going around
creating things across different areas
where you have no idea. So the main
point of bringing AI to an organization,
I think we might have talked about this
already was that we need to guide the AI
with rules and sandboxes and there's
several organization like several um
tool tooling suppliers like stackpack
that are focused on.
>> So basically basically we're going to be
in this area in AI
We're we're we're headed to the
governance
side of things.
>> Uh yeah, I mean in a way it's like you
see what Cloud Skills is doing and and
now Kira superpowers. It's all about
giving the LLM directions, right? And
and and right now they're generic, but
I'm sure a lot of organizations adopting
AI are are creating internal rules,
right? They're saying okay uh if you're
using cloud use our rules use our skills
directory internally within our
organization. What kind of rules would
there be? Like use
>> if you want to deploy the integration
points for a VPC are in this repository.
Don't create a VPC for scratch. There's
an existing one and this is how you find
the information about it. Right? Our
ingress is handled through our CDN layer
and uh we must follow these rules so on
right like the platform team uh are
here. This is the registry where you can
find information about the different
integration points. as a product team,
you're going to have to integrate into
the platform team or the cloud.
>> Yeah. Yeah. I mean, that that makes
sense, but I'm just thinking aloud that
um
how is this actually governed? So,
so you have the rules and and you and
like say say u a product team. Oh
I need to go. But okay, we need to pick
up here. We need to pick up here about
how AI is going to work in a typical
organization. Why did we end up talking
about this? Because you asked me about
CDKTF and I just went on my classic
rant.
>> Yeah, we can we can reflect. Okay, I
I'll catch up with you in a bit. Uh
probably tomorrow, right?
>> Yeah, tomorrow because I in a bit I'll
also be on the road.
>> Okay. So,
>> okay. Good one. Thanks, Vincent.