►
Description
In this Kongcast episode, Matt Stratton, a Staff Developer Advocate at Pulumi, explains the history of configuration automation, the world of cloud engineering and how it compares to DevOps.
▬ Want to see more Kong + Pulumi? Watch the 'DevMyOps - Deploy Kong with Pulumi' Tech Talk premiering live on 3/17/22: https://bit.ly/3oYNUd0 ▬
Subscribe to get email alerts for the latest new episodes and see which guests are coming on the show next: https://bit.ly/3zQV71e
Get started with Pulumi: https://www.pulumi.com/docs/get-started/
Join the Pulumi community: https://www.pulumi.com/community/
How Pulumi and Kong work together: https://konghq.com/blog/kubernetes-ingress-pulumi/
Deploying a Kong Gateway Data Plane With Pulumi: https://konghq.com/blog/kong-gateway-pulumi/
▬▬▬▬▬▬ TIMECODES ▬▬▬▬▬▬
0:00 Kongcast Show Intro
0:29 Welcome, Matt!
2:58 DevOps Tool Challenges
6:20 Sysadmins Are Coders Now Too?
9:20 Managing Technology Changes
14:36 What’s Cloud Engineering?
15:51 Cloud Engineering vs. DevOps
18:15 DevOps Evolution/Revolution
23:20 Demo: Configuring Infrastructure With Pulumi
30:59 Where to Go for More Complex Pulumi Examples
32:45 TV Show Recommendations from Matt
35:10 Kongcast Show Outro
▬▬▬▬▬▬ ABOUT KONGCAST ▬▬▬▬▬▬
Hosted by @ViktorGamov and Kaitlyn Barnard, we interview software developers and technology leaders at the top of their game every other week. We’ll also give you the tools, tactics and strategies you need to take your distributed architectures to the next level. Kongcast goes beyond the buzzwords and dissects real-life applications and success stories so that you can tackle your biggest connectivity challenges.
▬▬▬▬▬▬ KONG COMMUNITY ▬▬▬▬▬▬
⭐ https://github.com/Kong/kong
🐦 https://twitter.com/thekonginc
🌎 https://konghq.com/community/
🍻 https://www.meetup.com/pro/kong
❓ ️https://discuss.konghq.com/
💯 https://konghq.com/kong-champions/
#CloudEngineering #CloudEngineer #DevOps #Pulumi #Kongcast
B
B
B
Yes,
it's
been
a
while,
since
we
wanted
to
bring
you
in,
and
it's
finally
happened-
and
I
am
extremely
excited
to
talk
to
you
today
about
this
stuff.
I
am
a
huge
fan
of
the
stuff
that
you
guys
do
in
the
palomi
and
how
you
can
use
like
a
normal,
normal
programming
languages
to
do
infrastructure
as
a
code,
where
is
code,
is
actual
code,
not
some
bunch
of
yaml
and
stuff.
So
before
we
jump
to
this,
one
tell
us
a
little
bit
about
yourself.
C
Absolutely
so,
without
going
through
like
a
whole
bio
but
just
sort
of
the
interesting
parts.
So
I
spent
about
two
decades
working
in
traditional
technology
operations.
I
was
assist
admin
and
I
I
live
here
in
chicago.
So
I
worked
for
a
lot
of
financial
institutions
and
insurance
companies
because
that's
usually
where
you
work
in
chicago.
If
you
work
in
tech
and
kind
of
along
the
way
I
got
gotten
interested
in
this
devops
stuff
about.
C
C
Where
you
write
your
code,
your
info
code
in
ruby
kind
of
stepped
away
from
that
for
a
little
bit
and
then
I
came
back
to
join
palumi
and
so
infrastructure's
code
is,
is
really
interesting
to
me
and
I
think,
there's
a
lot
of
power
to
it
and
I
like
to
see
how
things
have
continued
to
evolve.
But
at
the
end
of
the
day
like
to
me,
it's
like
I've
been
the
person
that
this
was
crappy
right
like
doing
this
work
was
not
great,
and
so
I'm
excited
that
this.
C
B
You
said
like
you're
working
with
chef
and
ruby
like,
but
you
start
this
the
journey
as
to
solve
your
problems.
You
know
your
own
problems
as
a
as
many
assistive
administrators
they
trying
to
make
their
life
easier,
and
after
that,
you
realize
that
you
can
actually
make
life
other
people
easier
to
do
the
things.
What
are
the
challenges
you
saw
with
tools
like
puppet
and
with
tools
like
palumi
and
the
you
said,
like
you
believe,
in
in
tools?
B
First
and
after
not
the
kind
of
like
a
you
believed
in
the
tools
before
you
joined
the
company
right
yeah
how?
What?
How
would
help
you,
like?
You
probably
went
through
this
kind
of
like
a
curve
of
learning
the
multiple
different
tools
and
how
you
end
up
in
in
in
this
in
this
particular
case
like
why?
C
I
mean
well
I'll
put
it
to
you
this
way
right
and
yeah,
I'm
wearing
my
palomi
shirt
right
now,
but
still
I
used
to
say
when
I
was
a
chef
and
people
would
say:
should
I
use
chef
or
puppet?
I
would
say
yes
right,
like
others,
so
do
something,
and
I'm
a
big
believer
in
that
our
the
biggest
competitor
that
we
might
have
in
this
space
is
not
another
vendor.
It's
do
nothing
incorporated
right.
C
C
We
keep
talking
about
infrastructure
as
code,
but
really
what
we've
been
doing
is
maybe
building
our
infrastructure
using
some
code,
but
we
don't
think
about
our
infrastructure
as
reusable
components
that
are
abstractions,
that
we
can
treat
them,
treat
the
infrastructure
like
software,
which
is
what
I
think
is
the
exciting
thing
that
we're
moving
towards.
Today
I
mean
the
thing
that
gets
you.
Your
job
done
is
the
right
thing
for
you,
and
the
decision
you
made
was
the
right
decision
to
make
at
the
time
so,
but
things
are
continually
evolving.
B
I
would
like
you
to
a
little
bit
elaborate
on
one
point.
So
since
you
mentioned,
you
started
your
life
as
a
like:
a
system
administrator
and
historically
culturally
system,
administrators
and
developers,
they
are
different
breeds.
Like
you
know,
you
write
software,
not
because
you
like
write
software
as
a
developer,
but
because
you
have
to
automate
your
tasks
because
you're
lazy,
and
now
we
came
into
the
world
where
you
kind
of
as
a
system
administrator,
you
have
to
program
stuff
and
we
have
to
we.
B
You
know
a
lot
of
tools
are
pushing
all
these
cycle.
Reliability,
engineers,
I
don't
want
to
say
the
devops
engineer,
because
it's
going
to
be
fun.
Everybody
understands
that
and
like
how
we
end
up
here
right
so
like
why
to
make
people
who
genuinely
don't
like
code.
You
know
they
like
the
console
they'll,
do
like
to
do
infrastructure
and
and
stuff
like.
Why
force
them
to
to
do
this
programming.
C
You
you
couldn't
have
teed
me
up
better
right
like
this
is
the
point.
So
I've
been
saying
this
for
a
long
time
and
to
to
my
to
my
friends
in
this
admin
world
and
everything,
and
I
especially
would
start
to
bring
in
chef
and
bring
in
these
tools
and
like
and
again
that's
the
concern
they're
like
I'm,
not
a
I'm,
not
a
coder,
I'm
not
a
software
engineer.
Why
are
you
gonna
make
me
code?
I'm
like
I
got
great
news
for
you,
sis
admin
pals.
You
already
do
this.
We
just
use
different
words
for
it.
C
It's
super
true,
like
we
don't
talk
about
programming,
but
we
talk
about
scripting
and
as
much
as
you
might
like
being
in
the
console
and
stuff.
We
all
write
scripts
all
the
time
and
we
do
it
for
lots
of
ways.
That's
coding.
I
got
news
for
you
bash
that's
code,
man
and
you're,
doing
it
so
cool
and
we
don't
call
them
code
reviews.
We
call
them,
but
you
do
that.
Maybe
through
change
control
like
we
do
these
processes,
we
don't
call
it
debugging,
we
call
it
troubleshooting.
C
B
You
know
in
particular
you
know
day
or
hour,
and
it's
actually,
you
know
I
use
my
like
a
programmer
skills
so
there,
because
I'm
I
want
to
use
the
program
launch.
I
want
to
use
like
module
structure.
I
want
to
apply
some
of
the
concept
that
I
learned
from
the
object-oriented
programming
language
at
that
time,
so
which
brings
us
to
the
to
the
point
or
that
I
want
to
discuss
about
like
how
the
things
are
changed
from
the
time
when
we
just
started.
B
You
mentioned
like
people,
starting
with
bash
scripts
and
make
files,
and
now
we
are
introducing
or
some
of
the
concepts
that
were
introduced
in
the
programming
language,
like
modules,
the
code
reviews,
union
tests
are
actually
like
the
puny
trades
into
a
world
of
like
infrastructure
management,
so
you
you've
been
in
this
in
this
world
for
a
while.
So
how
you
see
this
transition
and
how
the
people
you
know
accepting
this.
C
I
will
tell
you
that
I
think
the
biggest
pushback
for
any
change
is
rarely
having
to
do
with
it
even
being
a
new
skill,
because
people
do
like
to
learn
new
skills.
I'm
not
saying
everybody
wants
to
learn
something
new
and
have
to
learn
something
new
every
week
when
your
job
is
continually
changing,
but
it
is
so
much
of
change
comes
back
to
a
sunk
cost
fallacy
right,
which
is
the
and-
and
it's
interesting,
because
I
see
this
a
lot
with
terraform
and
terraform
is
great.
Terraform
does
wonderful
things.
B
C
Might
be
all
excited
about
a
new
thing,
but
you're
like
oh,
my
god,
do
you
know
how
much
work
to
get
to
that
and
it's
it's
funny,
because
whatever
was
the
the
thing
that
is
oh,
it's
too
much
work
to
move
off
of
today
was
the
thing
that
people
didn't
want
to
move
to
six
years
ago,
because
it
was
too
much
work
to
move
off.
The
other
thing
right.
A
B
C
Throw
things
away,
but
there's
there's
it's
a
real
thing,
and
especially
the
larger
the
organization-
and
this
goes
back
to
like
don't
change,
never
change
for
the
sake
of
changing
right
like
we.
We
want
to
do
that
and
as
engineers,
we
like
new
things
that
are
fun
and
it's
always
fun
to
learn
new
things
and
continually
like
refactor
and
polish.
The
thing,
because
your
your
legacy
code
was
the
new
hotness
five
years
ago.
Right.
C
So
keep
that
in
mind
it's
hard
to
remember,
but
always
what
does
a
new
thing
do
that
you
can't
do
now
so
back
again
to
put
in
the
concept
of
like
with
chef,
I
would
go
work
with
organizations
a
lot
of
times.
Maybe
they
were
using
system
center,
like
in
a
microsoft
shop,
they're
trying
to
make
sccm,
which
was
fundamentally
a
thing
for
configuring
desktops
to
configure
their
data
center,
and
maybe
they
already
had
an
investment
in
it,
and
then
they
wanted
to
move
to
chef.
C
But
what
what's
common
to
do
is
take
all
the
things
your
old
tool
did
and
re-express
that
with
a
new
tool,
so
you're
gonna
spend
a
whole
lot
of
time.
Doing
that
and
at
the
end
of
the
day,
nothing
actually
changed.
So
I
always
sat
there
and
said:
what's
the
gap
right?
What's
the
thing
you
can't
do
with
config
man
right
now
that
you
can
do
with
chef?
Do
that
part
first,
so
at
least
while
you're
doing
the
work
you're
getting
some
new
value.
So
this
is
tech
is
easy.
People
are
hard.
C
The
hard
stuff
of
all
of
this
is
around.
How
do
we
change
organizationally?
How
does
my
day-to-day
change?
How
does
my
communication
change
with
this?
So,
if
you're
going
to
do
all
that
work,
you
should
be
getting
something
out
of
it
other
than
you're
paying
somebody
different
now
than
you
were
yesterday
right.
You
know
if,
at
the
end
of
the
day,
you
move
to
this
new
platform
and
you're
doing
all
the
exact
same
things
you
used
to
do,
but
now.
B
It's
someone
else's
exactly
what
I
get
out
of
it.
That's
that's
what
I
saw
like
multiple
times,
people
just
like
using
like
a
new
tool,
because
somehow
it's
a
new
shiny
things,
but
they
keep
repeating
the
same
pattern
and
in
this
new
tool
it
might
be
not
so
idiomatic
or
using
this
type
of
like
approach
that
you
did
like
five
years
ago,
whether
this
tool
might
not
be,
you
know,
feasible
or
not
possible.
C
Understand
yes,
this
is
also
a
fun
thing
that
this
reminded
me
of
a
little
bit
that
I
used
to
see.
I
feel
a
little
more
comfortable
telling
the
story
with
like
chef
and
puppet
and
stuff
where
it
was
because
I'm
not
there
anymore
and
and
where
those
come
in,
but
I
still
think
it's
true
across
the
board.
But
I
I
can't
tell
you
like
how
many
I
would
go
to
a
meet
up
or
something
someone
would
be
giving
a
talk
about
like
we.
C
We
took,
we
threw
out
all
of
our
chef
code
and
replaced
it
with
ansible,
and
it
was
so
much
better
or
they
would
do
the
same
thing.
We
threw
out
all
of
our
puppet
code
replacing
with
chef
and
was
so
much
better
and
it
was
always
about
well,
because,
obviously,
the
tool
is
so
much
better
and
it's
like
no
you're
smarter,
because
when
you
took
your
existing
implementation
and
you
redid
it,
you
did
it
with
more
wisdom
that
you
didn't
have
the
first
like
the
first
time
like
so.
C
C
B
You
keep
mentioning
some
of
the
like
the
the
words
or
vocabulary
that
very
familiar.
The
many
developers
very
familiar
and
developers
also
like
to
call
themselves
like
software
engineers
now
and
I'm
trying
to
brings
us
to
the
topic
of
the
cloud
engineering
and
what
does
it
mean
in
general?
Like
is
it?
Is
it
something
that,
when
you
writing
your
yaml
files
and
send
them
to
your
kubernetes
cluster,
it
doesn't
make
you
a
cloud
engineer.
C
I
so
what
I
think
about
cloud
engineering
is
it's:
it's
really
a
discipline
that
is
encompassing
what
we,
what
we,
how
we
build,
how
we
deploy
and
how
we
manage
these
platforms
and
applications
and
services.
So
it
encompasses
people
who
are
writing
the
application
code.
It
encompasses
your
operational
folks,
your
sres,
it
encompasses
your
infosec
and
your
compliance
and
your
security
folks,
and
the
idea
is
that
we
have
one
way
to
do
it
and
it's
not
one
way
for
the
entire
industry.
C
That's
what
breeds
empathy
and
empathy
is
the
core
of
this,
and
if
a
lot
of
this
sounds
like
devops,
it's
because
I
think
it
is
at
least
what
devops
was
supposed
to
be
somewhere
along
the
way.
Devops
became
automation,
tools,
right
and
writing
automation
and
that's
just
part
of
it,
but
really
it's
about
taking
these
principles
like
what
can
all
these
different
groups
learn
from
each
other
and
then
come
together
in
a
cross-functional
way?
B
We
start
talking
devops
as
a
tooling,
and
I
think
the
the
point
you've
made
a
little
bit
early
in
terms
of
tech
is
easy.
People
are
hard
and
allows
us
to
steer
from
the
actual
problems
that
devops
trying
to
solve.
As
a
you
know,
cultural
aspect
to
how
to
communicate
between
teams
how
to
establish
this
communication,
how
to
properly
plan
and
share
the
work
and
plan
work.
A
C
Tools,
influence
culture,
culture
influences
tools
right.
So
that's
the
thing
I
want
to
make.
I
think
sometimes
people
feel
like
when,
when
you
know
rant
about
things
like
this,
I'm
like
anti-tool
or
anti-automation,
I'm
like
no.
It
feels
like
we
over
correct
on
culture
and
communication
and
human
factors,
because
those
are
the
things
that
we
have
to
tell
you
to
do
because
playing
with
tools
we'll
do
that
automatically
like
we'd
like
to
do
that
right,
you
don't
have
to
tell
a
bunch
of
engineers
to
like
want
to
automate.
C
We
all
want
to
do
that
and
it
reinforces
that,
but
it's
really
easy
for
the
gravity
of
that
to
sort
of
become
the
default
like
we
gravitate
to
that.
So
we
have
to
push
harder
against
to
get
sort
of
escape
velocity
from
tool
tool
pull
to
culture
pull,
which
is
why
we
talk
about
it
a
lot,
but
it
kind
of
happened.
I
like
to
say
you
can't
buy
devops,
but
I
can
sell
it
to
you
right
and
devops
is
being
sold
to
you
folks.
So
so.
B
I
like
rap,
I,
like
I
like
it,
how
it
sounds.
So,
let's
talk
a
little
bit
about
the
the
value
prop
of
the
tools
and
how
how
it
changes
and
why
we
still
even
like
five
six
years
into
this
devops
evolution
revolution.
I
would
say
revolution
because
it
changes
the
minds
of
people
significantly
and
how
this
value
prop
changed
over
the
time
like
starting
from
the
simple
automation
things
into
the
point
where
we
can
have
like
real
programming
languages,
a
real
sdks
that
will,
you
know,
do
whatever.
C
C
I
found
this
really
interesting
about
why
a
lot
of
early
automation
tools
were
a
lot
better
on,
say
linux
than
on
windows
and
jeffrey
stover,
who's
distinguished
engineer
at
microsoft,
he's
doing
a
bunch
of
great
invented
powershell
all
this
on
stuff.
He
said
something
many
many
years
ago
where
he
said
part
of
the
reason
is
that
linux
thinks
about
the
operating.
Everything
is
a
document
right,
whereas
in
windows
and
again
I
understand
I'm
putting
myself
back.
Everything's
changed
a
lot,
but
at
the
time
everything
was
an
api.
C
So
if
you
had
tools
like
shaffer
puppet
that
wanted
to
reason
about
files,
they
were
really
hard
to,
because
that's
not
how
the
operating
system
worked.
So
that
thing
being
said,
if
we
think
about
the
cloud
and
and
kubernete
you
know
whatever
the
modern
cloud
is
kubernetes,
you
know
containers
all
the
things
cloud
resources
they're
all
apis,
which
means
we
reason
about
this
infrastructure
in
a
lot
of
ways,
that's
very
similar
to
how
we
build
services
that
our
applications
run
on.
C
So
it's
a
lot
easier
I'll
give
a
really
interesting
example
is
back
in
the
chef
days.
My
customers
would
always
ask
me
they
say
how
come.
I
can't
just
point
chef
at
my
apache
server
and
have
it
spit
out
a
cookbook
to
build
that,
and
I
was
like
because
on
that
linux
operating
system
and
apache
there
are
hundreds
of
thousands
of
possible
things
and
chef
has
no
idea
which
of
those
you
care
about,
what's
relevant.
What's
just
sort
of
there
blah
blah
blah,
you
know
what
you
can
do
with
like
palumi,
for
example.
C
You
can
absolutely
point
it
at
your
aws
infrastructure
and
have
it
spit
out
pollumi
code
to
make
that,
because
it's
a
defined
api,
that
the
settings
are
understood,
what
they
are.
That's
just
the
world
of
cloud.
That's
api
first
versus
document.
First,
it
lets
us
reason
about
things
that
way.
So
I
think
that's
where
that
interesting
evolution
has
come
and
we
need
to
embrace
that
a
little
bit
more
rather
than
again
a
lot
of
our
stuff.
We
think
about
yaml
files.
B
That's
very
interesting
point
because
I,
when
I
explain
this,
I
like
to
approach
this
from
perspective
of
api
and
saying
this
document
essentially
would
be
translated
to
api
call.
We
take
this
like
yaml
file.
It
will
be
translated
to
json
and
after
that
it
will
be
submitted
to
kubernetes
api.
I
absolutely
agree
with
you
in
terms
of
it's
just
like
the
way
how
you're
thinking
about
the
the
what's?
B
What's
your
mindset
like
when,
what's
your
mental
model
that
you
used
to,
when
you
you
know,
do
certain
things
like
if
we
describe
infrastructure
and
how
you
would
describe
infrastructure
from
perspective
of
state?
That's
how
the
kubernetes
teaches
to
do
things
right,
so
we're
describing
desired
state
and
after
that,
kubernetes
will
make
things
happen
versus
two
things:
how
we
have
with
the
playbooks,
where
we
actually
describing
a
steps
that
the
tool
needs
to
take
to
take
us
somewhere
and
in
one
case
it's
a
it's
all
about
journey,
another
one.
B
C
What
I
have
here
is
I
have
a
pretty
straightforward,
paloomy
program
that
I've
written
to
configure
a
little
bit
of
infrastructure
for
us
now.
My
use
case
here
is
not
one
that
I
imagine
any
of
us
are
doing,
because
I
don't
know
how
many
of
you
are
serving
your
websites
as
simply
a
bunch
of
static,
html
and
an
s3
bucket.
I
mean
you
might
be
you're,
maybe
using
a
static
site
generator
or
something,
but
not
just
a
bunch
of
files
sitting
there.
C
But
this
is
kind
of
illustrating
a
couple
of
the
interesting
things
we
can
do
with
pollumi.
So
the
first
thing
I
want
to
talk
about
here
is
you'll
you'll
see
my
pollumi
program
is
written
here
in
typescript
it's
written.
This
is
I'm
using
javascript
and
typescript.
Now
I
could
also
have
written
my
plumi
program
in
python
or
in
go
or
in
net
c-sharp
f-sharp,
et
cetera
in
this
particular
case,
I'm
using
typescript
as
it
happens,
I
like
go,
but
it's
a
little
easier
to
illustrate
in
typescript,
so
that's
the
one
that
I'm
using
here
now.
C
What
what
happens
here
is
you
can
see.
One
of
the
things
I
think
is
really
cool
is
anytime.
I
start
using
a
new
tool
that
involves
me
using
anything
in
visual
studio
code.
Of
course,
what's
the
first
thing
that
we
do,
is
we
go
and
we're
like
where's
the
plugin
right,
let
me
put
in
the
plugin
that'll,
give
me
snippets
and
type
ahead
and
all
that
stuff.
C
Now
what
we're
doing
I'm
going
to
walk
you
through
real,
quick
and
show
you
what
it
does
and
then
we'll
make
a
change.
So
my
use
case
here
is:
I
want
to
throw
a
bunch
of
html
files
in
an
s3
bucket
and
then
I
want
to
serve
them
so
that
it's
understandable.
So
the
first
thing
is
we're
going
to
create
a
bucket
and
we're
going
to
call
it
mybucket,
because
I
am
very
protective
of
my
own
stuff.
C
Now
one
of
the
things
that
palumi
does
do
just
because
if
you'll
see
this
later,
we
do
an
auto
naming
so
that
you
don't
get
name
collisions
because
you
might
be
like
well.
How
do
you
know
there's
not
already
a
bucket
called
my
bucket,
the
name
that
gets
created
for
this
is
going
to
be
my
bucket
dash
and
then
an
identifier.
C
C
So
the
first
thing
is
that
I'm
able
to
do
is
I
am
saying,
instead
of
identifying
all
the
files
I've
created
a
directory
that
we're
going
to
refer
to
as
a
value
of
citeder,
which
you'll
see
in
a
second
and
I'm
just
basically
saying
loop
through
that
whole
directory
and
for
each
of
them
create
a
new
object
and
but
look
the
bucket
is
my
bucket
right.
So
I
don't
need
to
know
the
id
of
the
bucket
I'm
able
to
pull
it
because
I
created
this
object
now.
C
What
I've
done
in
pollumi,
so
you'll
see
that
I
say
this
citer
but
you're
like
what
site
duramaddy
well.
This
is
when,
because
it's
a
programming
language
I
can
bring
in
a
component,
so
I
created
a
component
called
config,
which
is
basically
saying
what
configuration
is
necessary
for
me
to
do
this,
and
one
of
those
configurations
is
there
needs
to
be
a
value
for
citer.
The
reason
this
matters
is:
maybe
I
have
a
different
now.
I
don't
know
why.
C
I
would
do
this
why
I
would
have
a
different
directory
in
my
program
that
I'm
going
to
use
for
production
versus
pre-broad,
but
we're
going
to
pretend.
So
if
we
look
at
my
configuration,
I
have
one
called
dev
and
in
dev
the
value
of
citer
is
dub
dub
dub
right.
So
what
we
can
do
here
with
this
pollumi
program
right
now,
if
I
type
in
pollumi
up
now,
I
will
tell
you
one
of
the
things
I've
already
done.
My
computer
is
configured
to
know
how
to
talk
to
aws.
C
C
If
you
run
this,
this
is
what's
going
to
happen
now,
in
this
case,
one
of
the
things
I
have
to
do
in
order
for
this
to
happen,
palumi
has
to
understand
my
state
and
you
can
store
your
state
in
all
sorts
of
different
ways.
One
of
the
places
is
with
the
palumi
service,
which
is
what
you
see
here.
So
if
I
were
able
to
click
here,
I
could
see
in
the
browser
all
the
things
that
I'm
doing,
but
fundamentally
here's
what
it's
saying
it's
saying
if
you
were
to
run
this
right
now,
here's
what's
up.
C
I
need
to
create
an
s3
bucket
and
I
need
to
create
these
two
bucket
objects,
and
even
if
I
were
to
go
in
and
say
details,
we
can
see
the
really
specific
details
of
what's
going
to
happen
and
remember.
You're,
like
hey,
I
created
a
bucket
and
it's
called
my
bucket
d2eb155
like
I
don't
have
to
remember
that.
So
if
I
were
to
go
ahead
and
say
yes,
let's
go
ahead
and
run
this
this
one's
pretty
fast,
because
it's
just
s3.
C
C
Let
me
do
that
and
the
one
thing
just
to
sort
of
show
the
difference
of
what,
when
the
configuration
really
quick
is
maybe
okay.
So
I
have
my
stack
so
if
I
say
polumi
stack
ls,
we
can
see
it'll
tell
you,
okay,
you
have
one
stack
right
now,
maddie,
it's
called
dev,
here's
what's
up
with
it,
but
I
want
to
have
one
for
prod.
So
in
prod
we
might
have
some
different
configuration.
Maybe
it's
a
different,
a
different,
a
z,
a
different
region,
so
I'm
gonna
create
a
new
one
called
prod.
C
So
now,
if
I
were
to
go
in
and
say,
pull
me
up
what
it's
going
to
do.
Is
it's
actually
not
going
to
like
this
because
it
said
that
it
needed
to
find
I
I
set
the
value
to
something
that
wasn't
there,
so
I
think
that
gives
us
kind
of
the
idea
of
where
that
would
would
go
where
these
changes
go.
There's
a
lot
more
to
this
one
of
the
things
that's
really
powerful
about
this
as
well,
because
it's
a
programming
language
I
can
use
all
of
the
things
I
would
normally
do
to
test.
C
B
B
Where
you
would
recommend
people
to
look
if
they
want
to
see
some
more
complex
examples,
like
you
mentioned
the
provisioning
kubernetes
cluster,
which
sparks
interest
in
me.
You
had
my
attention
now.
You
have
my
curiosity.
So
no,
like
you
have
my
you
have
my
curiosity
and
now
you
have
my
attention.
Yeah.
C
One
of
those
things
you
got
it
somehow
chocolate,
peanut
butter,
whatever
one
of
the
places
for
that
is,
if
you
go
to
plumi.com
registry,
that's
our
registry
of
all
of
the
different
providers
and
then
and
all
of
the
packages.
So
if
you
went
to
the
kubernetes
one,
you
would
see
there's
a
set
of
how-to
guides,
various
things
about
hey.
How
do
you
get
either
as
just
as
simple
as
a
hello
world
on
maybe
aks
on
azure
kubernetes
service?
Or
how
do
I
do
a
stateless,
app
deployment?
How
do
I
deploy
with
helm?
C
There's
a
lot
of
examples
for
that.
So
really,
plummy.com
registry
is
probably
a
great
place
to
look
at
that
stuff.
Also,
if
you
just
go
to
the
it's
like
palumi.com,
get
started,
that'll
walk
you
through
a
lot
of
those
things.
I
also.
If
you
are,
you
know
we
have
some
weekly
live
streams.
We've
started
to
do.
In
fact,
I'm
about
to
go,
do
one
right
after
you
and
I
are
done
so.
C
B
That's
awesome,
matt
and
definitely
check
out
the
show
notes
in
the
description
below
you'll
find
all
these
links.
You
can
find
all
the
contacts
from
matt
and
follow
me,
and
I
would
like
to
say
huge
thanks,
matt,
to
find
the
time
to
talking
to
us
and
being
a
part
of
comcast
usual
question
that
I
have
last
question
that
I
have
on
my
guests.
B
Is
that
is
there
any
something
like,
for
example,
is
there
any
book,
or
maybe
podcast
or
maybe
movie,
or
something
that
you
saw
that
maybe
not
necessarily
related
to
the
topic
that
we
talked
about
like
excited
you
and
you
want
to
share
or
like
you
cannot
shut
up
about
this
and
you're
telling
everyone
like,
for
example,
I
last
basically
two
months.
I
was
like
deep
into
watching
all
james
movies
to
prepare
myself
to
no
time
to
die
and
I
couldn't
shut
up
about
this
with
the
you
know.
B
C
C
Studio-
and
it
is
not
only-
is
it
very
very
funny,
but
I
will
tell
you
they're,
both
seasons
that
have
been
out
so
far.
They
have
an
episode
that
just
sort
of
catches
you
and
you're
like
wait.
What
that
you
know
just
like
catches,
you
in
the
feels
I
mean
it's
very
funny-
very
dark
in
a
lot
of
ways,
but
I
I
think
it's
getting.
I
think
it's
underrated
and
again
when
I
started
watching
it.