►
From YouTube: Cloud Native Live: Humanizing your cloud native platform
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
A
I've
been
following
them
since
day,
one
they've
kind
of
become
this
alternative
to
what
it
looks
like
of
creating
or
to
create
infrastructure
from
scratch
and
giving
you
more
options
in
terms
of
building
that
infrastructure,
of
course,
and
managing
it
right
very
similar
to
terraform
in
some
ways,
but
very
different
in
some
really
really
nice
ways
as
well
check
them
out
apology.com,
and
I
think
one
of
the
goals.
For
me
this
session
is
to
help
you
understand
the
concepts
and
the
methodologies
that
lee
is
talking
about.
A
So
please
ask
as
many
questions
as
you
can
in
whichever
platform
you're
currently
using
right
now,
and
I
will
help
to
facilitate
make
sure
that
myself
and
lee
get
to
those
questions
to
make
sure
you're
getting
the
best
information
and
getting
the
the
correct
answers
to
understand
and
one-up
your
skills.
So
I'm
really
excited
lee.
Has
experience
at
aptio
and
yelp
he's
a
dub
advocate
at
the
blooming
corporation
right
now
and
I'm
pretty
sure
I've
heard
of
him
in
a
few
other
circles
as
well.
A
I
think
he's
he's
a
bigger
deal
than
he's
going
to
let
on
for
sure,
but
so
we'll
see
we'll
see,
I'm
talking
him
up
a
little
bit
but
I'll.
Let
him
prove
it
to
you
so
lee
take
it
away.
Thank
you!
So
much
and
everybody
please
ask
many
questions.
Go
ahead.
Thank
you.
B
Very
much
mario.
I
really
appreciate
the
kind
words
I
would
not
necessarily
describe
myself
as
a
as
a
big
deal,
but
you
know
I
I
have
been
active
in
the
cloud
native
community
for
for
a
long
time
now,
and
I
think
a
lot
of
people
know
me
for
a
expletive
written
blog
post
a
little
while
ago
about
templating
yaml,
which
you
can
see
on
my
blog
leighbriggs.com
uk.
So
I'm
actually
here
to
talk
about
something
similar
to
that.
B
One
of
the
things
that
I
have
really
kind
of
leaned
into
in
the
last
few
years,
especially
as
cloud
native
technologies
have
taken
off,
is
the
idea
that
user
interfaces
are
super
important
and
while
a
lot
of
these
cloud
native
technologies
are
extremely
empowering,
they
are
often
in
my
experience
not
always
the
most
user-friendly
because
they
are
building
blocks
because
you
are
supposed
to
layer
your
you
know
your
beautiful
experience
on
top
of
them.
B
So
the
title
of
what
I'm
going
to
talk
about
today
is
humanizing
your
cloud-native
platform,
I'm
going
to
whiz
through
some
slides
and
then
I'm
going
to
do
a
demonstration
and
then
we
should
hopefully
have
some
time
for
some
questions
at
the
end,
depending
on
how
much
I
ramble
away.
But
before
I
do
that,
let
me
first
just
introduce
myself.
I
work
at
palumi.
I've
had
several
roles
at
palumi
I
like
to
change
jobs
every
six
months
and
I
like
working
at
palumi.
B
So
I
just
change
my
title
now
and
I
occasionally
blog
about
random
things.
I
post
on
twitter
and
it's
usually
related
to
technology,
and
I
have
a
github
which
is
full
of
terrible
code,
I'm
originally
from
the
uk,
as
you
can
probably
tell
by
the
accent-
and
so
it's
really
pained
me-
to
have
americanized
spelling
in
a
lot
of
these
slides.
B
So,
for
example,
humanizing
with
the
z
is
not
my
my
preferred
way
of
spelling
it,
but
just
because
I
live
in
the
united
states
now
I
have
kind
of
lean
into
it.
So
what
I'm
gonna
be
doing
is
talking
a
little
bit
about
platforms
platform.
Is
such
an
overloaded
term,
especially
in
the
cloud-native
community,
it's
thrown
around
all
over
the
place.
So
before
I
actually
talk
about
platforms,
I'm
gonna
give
my
definition
of
a
platform
in
this
particular
context.
B
So
what
I'm
talking
about
here
is
the
automated
opinionated
batteries
included
mechanism
that
allows
you
to
deliver
infrastructure
and
applications.
So
if
you
think
about
cloud
native
technologies,
you
think
about
things
like
prometheus,
you
think
about
open
tracing,
you
think
about
kubernetes
and
all
of
the
things
that
kind
of
wrap
up
in
that
cloud
native
software.
B
To
me,
all
of
those
things
are,
you
know,
building
blocks
to
build
a
platform,
and
certainly
I,
before
I
worked
at
palumi,
built
an
actual
platform
where
there's
some
wonderful
colleagues
for
my
old
employer
that
incorporated
all
of
these
different
things
into
a
mechanism
for
our
software
engineers
to
deliver
applications
really
stretched
like
really
seamlessly,
and
I
learned
a
lot
during
the
experience
of
building
a
platform
and
a
lot
of
the
things
that
I
learned
actually
looked
like.
B
You
know
a
lot
of
those
things
that
I
learned
actually
started
to
to
become
apparent
as
I
joined
palumi
before
I
actually
talk
a
little
bit
about
the
humanizing
part
of
this.
I
want
to
talk
a
little
bit
about
like
the
platform
adoption.
This
is
from
the
2020
state
of
devops
report
and
I
saw
this
last
year
and
thought
okay,
I
thought
we
were
all
crazy
for
building
these
complex
platforms,
but
it
looks
like
a
lot
of
people.
B
Certainly
in
the
cloud
native
community
are
having
similar
ideas,
which
is
we're
going
to
build
this
mechanism
to
deliver
software
and
infrastructure
in
a
way
that
allows
our
users
to
not
really
have
to
think
about
it,
and
I
think
this
is
really
kind
of
like
the
uptake
in
these
different
platform.
Building
mechanisms
are
really
really
starting
to
to
show
through,
especially
when
you
start
to
think
about
how
kubernetes
and
and
other
related
software
really
makes
this
easier
for
you
within
your
organization.
B
Why
might
you
do
this
again?
We
talked
about
streamlining
application
and
infrastructure
delivery,
but
for
me
it's
about
empowering
developers,
you're
software
developers,
if
you're
on
the
cloud
native
side
of
things
and
you're
more
of
an
infrastructure
person
like
myself.
Your
job
is
to
help
your
developers
deliver
software
and
deliver
features
to
your
users
as
fast
as
possible,
so
that
you
can
increase
the
business
value
that
they
experience
by
using
your
application,
and
we
like
to
at
paloomi
talk
about
this
being
a
competitive
advantage
right
like
you.
B
If
you
can
get
your
features
in
the
hand
of
your
users
as
fast
as
possible,
your
users
will
love
your
application
because,
let's
face
it,
we
all
love
shiny
new
things
and
we
all
love
to
kind
of
experience,
new
features
and
being
able
to
abstract
a
lot
of
that
complexity.
Away
is
really
the
bread
and
butter
of
what
a
platform
can
do
for
you,
and
is
why
you
might
experience,
might
think
about
building
one.
B
So
let's
talk
a
little
bit
about
what
automation
means
in
the
context
of
a
platform,
so
I'm
going
to
have
multiple
xkcd
comics
in
here,
because
I
really
think
that
they
capture
what
it
really
means
to
actually
work
in
technology,
but
ultimately
like
really
the
the
point
of
automation
is
to
make
sure
that
you
get
more
free
time
back
often
in
in
certainly
in
the
cloud
native
experience.
B
I
have
found
that
this
it
looks
a
little
bit
like
the
second
of
these
boxes,
in
which
you
start
to
build
a
cloud
native
platform.
You
input,
incorporate,
kubernetes
and
prometheus,
and
all
these
different
things
into
your
environment
and
then
what
actually
ends
up
happening.
Is
you
spend
most
of
your
time
managing
that
platform
and
managing
that
automation
to
make
sure
it
works
correctly?
B
And
what
I
personally
experienced-
and
this
may
not
be
the
experience
of
everybody
watching
today,
but
I
personally
experienced-
was
that
that
ongoing
development
meant
that
I
really
didn't
think
about
what
the
experience
of
people
consuming
that
platform
had.
I
didn't
think
about
how
they
enjoyed
using
that
platform.
Sure
it
was
easier
than
it
was
before
when
they
had
to
do
a
bunch
of
manual
deployment
processes
or
a
manual
bunch
of
manual
release
processes.
B
So
here
are
some.
I
I
one
of
my
colleagues
paul
asked
me:
is
this
a
quote
or
a
statement?
I'm
like
it's
a
statement,
we're
going
to
try
and
make
it
a
quote.
A
good
infrastructure
platform
should
allow
you
to
continuously
deliver
your
applications
and
continuous
delivery
and
platforms
are
inextricably
linked.
B
If
you
think
about
continuous
delivery,
if
you've
heard
that
phrase,
a
platform
is
really
helping
you
to
like
build
a
pipeline
for
to
continuously
deliver
your
applications
and,
as
I
already
mentioned,
being
able
to
continuously
deliver
your
applications
means
that
your
users
get
features
and
your
the
people
that
you
actually
are
trying
to
sell
your
business
to
will
be
ultimately
be
happier,
and
this
is
just
a
slide
from
a
talk
that
I
watched
by
charity.
Majors.
B
I'm
sure
everybody
watching
today
has
at
least
heard
of
charity
majors,
which
I
think
is,
is
really
really
important.
To
kind
of
consider
that
shipping
is
the
heartbeat
of
your
company
and
actually
delivering
application
features
to
your
users
really
should
be
the
thing
that
happens
most
often
and
a
platform
will
help
you
do
that
via
automation.
If
you
think
about
what
a
really
good
platform
would
look
like,
you
start
the
process
and
at
the
end
of
the
process,
your
users
have
something
in
their
hands
that
they
can
use.
B
B
Continuous
delivery,
as
we
also
mentioned,
is
not
only
inextricably
linked
to
a
platform,
but
continuous
delivery
is
often
paired
with
continuous
integration,
and
you
often
see
those
two
acronyms
used
together,
ci
and
cd,
and
if
you
think
about
how
a
lot
of
automation,
platforms
or
delivery
platforms
look,
they
often
start
with
a
git
push,
and
you
know,
certainly
in
the
cloud
native
in
the
cloud
native
community,
git
ops
is
becoming
a
really
kind
of
big
deal.
B
This
idea
that
your
git
repositories
and
your
source
code
repositories
are
the
source
of
truth
for
your
deployments
in
your
pipeline,
and
my
personal
perspective
on
this
is
that,
because
git
is
not
always
the
most
user-friendly
tool
to
actually
use
and
again
this,
this
xkcd
comic
really
kind
of
makes
me.
You
know
look
at
this
and
think
git
is
not
always
the
most
user-friendly
of
these
tools,
but
if
git
and
your
ci
pipeline,
the
question
that
I
ask
myself
is:
is
git
and
your
ci
pipeline
the
most
user-friendly
interface
into
infrastructure.
B
Like
is
this
the
way
that
you
could
make
your
deployment
and
delivery
processes
user-friendly?
Is
this
a
human
way
of
actually
getting
applications
into
your
you
know
into
your
users
hands
and
it
is
a
user-friendly
way
for
people
consuming
any
platform
that
you
build
and
actually
using
it
and
delivering
that
delivering
value?
Well,
here's
a
couple
of
pros
and
cons.
B
I
know
I
could
probably
talk
at
great
length
about
this
and
I
do
have
a
blog
post,
which
is
very
click-baity
titled
that
I
hope
to
publish
by
the
end
of
this
week,
but
some
considerations
that
you
might
think
about
in
terms
of
using
git
or
using
your
version
control
as
the
interface
into
your
actual
delivery
pipeline.
B
It
allows
you
to
see
every
atomic
commit
and
the
history
of
your
actual
changes.
If
you
do
it,
if
you
do
it
correctly,
you
can
make
these
things
reproducible
and
we
see
things
in
the
cloud
native
community
around
building
images
and
building
containers
which
will
really
help
you
you
know,
would
really
help
you
make
those
deployments
reproducible.
B
My
personal
perspective
is
that
the
feedback
loop
for
git
ops
and
get
delivery
pipelines
is
really
not
an
optimal
way
to
actually
deliver
software
like
you,
don't
always
get
the
opportunity
to
push
something,
and
then
it
just
shows
up
into
your
actual
into
your
actual
infrastructure.
You're,
often
looking
at
your
ci
cd
pipeline
you're,
often
looking
at
you
know
refreshing
a
page
looking
at
you
know:
git
lab
pipelines
and
and
github
actions,
pipelines-
and
I
personally
have
experienced
this
and
found
it
to
just
really
not
be
an
excellent
feedback
loop.
B
So
now
we'll
get
to
the
actual
point
of
what
I'm
trying
to
say.
Maybe
there's
a
different
approach
to
all
these
things
and,
of
course,
I'm
a
palumi
employee.
So
I
am
going
to
talk
a
little
bit
about
how
polumi
can
help
here
with
a
demo
and
an
example
towards
the
end,
but
I'm
trying
to
think
what
I'm
really
trying
to
do
is
start
to
make
you
think
about
in
when
you're
building
delivery
pipelines,
especially
for
myself
as
an
infrastructure
engineer
the
most
important
part
about
humanizing.
B
These
things
is
to
think
about
what
your
users
want
to
do
and
every
single
organization
is
different.
Like
I,
we
all
love
these
opinionated
platforms,
but
you
have
to
actually
fit
them
within
the
context
of
your
your
company's
compliance
needs
with
the
context
of
your
company's
application
and
how
it's
been
built
and
humanizing.
These
things
the
most
important
thing
and
it's
a
term
that
we
throw
around
all
the
time
when
we
talk
about
devops.
The
most
important
thing
to
think
about
is
empathy.
B
B
So
I
like
to
think
about
building
delivery
mechanisms
using
apis,
because
aprs
are
interfaces
that
most
software
developers,
which
is
what
we
are
at
heart,
can
actually
understand
and
use.
They
allow
you
to
create
flexible
mechanisms
to
actually
consume
your
platform.
They
create
a
communication
format
that
is
essentially
universal.
It
goes
across
languages,
it
goes
across
a
programming
languages
and
the
final
thing
is:
it
creates
a
documentation
mechanism
that
you
know
can
really
help
people
who
come
along
after
you
to
understand
why
you
did
something
so
everything
you
know.
B
One
of
the
reasons
that
I
think
that
kubernetes
has
really
exploded
in
popularity
is
not
only
because
it's
a
container
orchestration
mechanism,
but
because
it
has
a
an
api.
That's
well
documented
that's
easy
to
consume
and
is
published.
You
know,
basically
everywhere
you
might
want
to
use
kubernetes.
So
you
know
you
can
go
and
read
the
api
documentation.
You
can
go
and
actually
have
a
look
at
what
the
api
is
doing
and
get
an
idea
of
what's
actually
happening
inside
a
kubernetes
cluster.
B
So
the
final
part
of
this
that
I
want
to
talk
about
before
I
stop
boring
everybody
with
slides
is
I
want
to
talk
about
how
you
might
build
on
those
apis
to
make
the
apis
consumable
for
your
users,
and
I'm
also
going
to
you
know,
shamelessly
talk
about
how
polumi
can
help
you
with
these
things.
Building
on
apis
is
is
really
helpful
in
the
sense
that
it
actually
makes
you
start
to
think
about
what
mechanism
the
users
of
your
platform
will
want
to
consume
those
apis.
So,
of
course
they
can
use
the
raw
api.
B
You
know
the
kubernetes
api
and
they
can,
even
if
they
really
want
they
can
define
the
yaml
infrastructure
or
the
yaml
definition
of
that
api,
which
is
what
a
lot
of
users
seem
to
do,
but
is
that
the
end
be
all
and
end
all
in
terms
of
humanizing
your
api,
because
a
lot
of
times,
especially
when
you're
using
configuration
file
formats
like
yaml,
you
end
up
with
a
lot
of
repetition,
and
you
end
up
with
you
know
hundreds
of
lines
of
code
when
often
that
repetition
is
not
needed.
B
So
what
I
believe
is
that
the
right
way
to
build
on
those
apis
and
the
right
way
to
humanize
your
platform
is
to
think
about
what
your
users
want
and
then
abstract
that
api
away
into
an
easy-to-use
mechanism
and
there's
a
few
ways
that
you
can
do
that
and
I'm
going
to
show
you
examples
of
how
you
might
do
that
within
within
the
context
of
pollumi.
So
the
first
way
that
I
think
is
really
undervalued
and
really
not
looked
at
as
much
as
it
should
be
in
the
cloud
native
community.
B
Is
that
sdks
are
your
software
engineers,
bread
and
butter?
They
use
them
in
their
application
pipelines,
they
use
them
when
they're
building
their
application.
Libraries,
npm
modules,
nuget
packages,
go
modules,
python,
pip
repositories.
These
are
the
things
that
your
users
of
your
platform,
the
I.e
the
software
developers
delivering
value.
B
These
are
the
things
that
your
users
are
using
every
single
day
and
if
you
can
define
software
fdk
sdks
for
your
platform
and
your
infrastructure
delivery,
we
have
seen
at
palumi
that
the
amount
of
the
amount
of
velocity
your
users
get
when
they
are
able
to
consume.
Those
sdks
can
often
far
outweigh
the
idea
that
you
would
say:
hey.
We
have
this
kubernetes
platform,
go
and
learn
this
yaml
format
and
start
to
understand
how
it
works
and
then
you'll
be
able
to
have
a
really
great
experience,
building
software,
sdks
and
building
things
in
languages.
B
The
second
thing
to
think
about
is
that
the
people
who
might
want
to
consume
your
platform,
the
people
who
might
want
to
deliver
software,
and
not
always
software
engineers
or
technical
users.
I've
certainly
worked
in
environments
where
less
technical
users
do
need
to
be
able
to
actually
deliver
features,
and
software
and
web
portals.
If
you
think
about
some
of
the
major
cloud
providers,
they
all
provide
web
portals.
B
Web
portals
can
be
a
super
super
valuable
part
of
deploying
software
and
infrastructure
and
delivering
value,
and,
if
you
think
about
some
other
cloud
native
technologies,
like
argo,
argo
and
argo
workflows,
they
provide
these
web
interfaces
that
allow
you
to
actually
operate
on
your
on
your
kubernetes
infrastructure.
B
To
really
help
users
actually
deliver
value,
and
then
the
final
thing
is
is
that
you
know
I'm
personally.
A
command
line.
User
command
line
interfaces
can
really
help
power.
Users
feel
effective
and
command
line
interfaces,
don't
always
need
to
be
the
be
all
and
end
all,
but
a
command
line
interface
can
help
those
users
that
are
consuming
your
platform,
especially
in
an
automation
context.
B
B
Palooni
palumi,
I'm
going
to
show
you
a
little
bit
more
about
pulling
me
in
a
second,
but
palumi
is
an
infrastructure
code
platform
that
allows
you
to
choose
one
of
our
supported
languages
to
actually
define
infrastructure
and
application
delivery
pipelines.
We
support
the
node.js
ecosystem.
We
support
python.
We
support,
go
wespot.net.
My
favorite
language,
to
use
of
these.net
language
is
a
visual
basic
because,
let's
be
honest,
it's
been
around.
B
For
you
know
nearly
20
years
at
this
point,
and
anything
that's
been
around
20
years-
must
be
a
good
thing,
but
you
can
actually
choose
the
languages
that
you
consume
your
infrastructure
in
with
polumi
and
deliver
value
to
your
users
using
that
language,
and
it
also
allows
you
to
choose
your
workflow.
We
already
talked
about
web
services
and
command
line
interfaces
with
the
prelumi
automation
api,
which
we're
going
to
see
a
little
example
of
in
a
few
seconds
with
the
pollumio
automation
api.
B
You
can
actually
start
to
fit
your
platform
and
all
of
the
parts
of
the
platform
that
you've
built.
You
can
actually
start
to
fit
it
into
the
context
of
your
organization
and
build
your
workflow.
That
makes
sense
for
your
users,
so
I've
talked
a
lot.
I've
talked
for
20
minutes
now
and
I
don't
want
to
keep
talking
about
these
slides.
What
I
actually
want
to
do
is
put
my
money
where
my
mouth
is
and
show
you
an
example
of
what
this
might
look
like.
This
is
going
to
be
a
live
demo.
B
If
I
make
mistakes,
I'm
just
going
to
just
figure
it
out
as
we
go
along.
So
let's,
let's
take
a
look
at
what
this
might
look
like.
Mario
I've
just
been
talking
for
20
minutes
now
I
don't
know
if
you
want
to
jump
in
with
any
questions
before
we
start
looking
at
how
this
might
look
in
practice.
A
No
yeah,
this
is
fantastic,
and
lee
talked
about
a
lot
of
things
there.
I
wanted
to
highlight
a
couple.
The
state
of
devops
report
put
out
by
puppet
is
a
really
important
thing
to
keep
your
eye
on.
I
think
that
there's
a
lot
of
good
information
there
in
terms
of
trends
and
what's
going
on
in
terms
of
these
adoption
rates
and
how
many
teams
are
realizing
value
out
of
the
the
kind
of
landscape
out
there
right
and
then
the
other.
A
You
know
ux
and
focusing
on
you
know
my
developers
and
you
know
running
the
platform
like
what
what
does
that
have
to
do
like
I'm
an
sre
like
I
just
want
to
make
my
cloud
infrastructure
better,
but
I
actually
what
ends
up
happening
and
I've
been
in
sra
for
a
while,
and
I
know
lee
obviously
has
worked
in
sra
as
well
like
you
actually
become
a
support
person
more
so,
and
I'm
not
saying
this
in
a
bad
way.
I'm
saying
that
you
end
up
finding.
A
A
But
what
what
lee's
actually
saying
here
is
why
don't
we
solve
the
underlying
problem
that
the
platform
and
the
semantics
for
how
we
ship
applications,
how
we
manage
applications
and
the
flexibility
and
the
shift
left
of
focusing
on
the
developer
and
what
their
workflow
is.
We
can
actually
solve
a
lot
of
those
problems
and
we
can
make
it
really
self-service,
which
is
what
we're
looking
for
and
we
can
make
it.
A
You
know
make
sense
and
fit
into
our
policies
and
fit
into
our
security
and
fit
into
what
our
goals
are
for
our
platform
right
and
so
that
ends
up
turning
around
and
changing
the
paradigm
where
sre
actually
becomes
what
sra
is
meant
to
be
as
people
that
are
automating
the
toil
away,
maintaining
an
amazing
platform
and
maybe
helping
even
distract
other
elements
of
the
platform
in
terms
of
other
realms.
You
know
security
or
latency
or
whatever
it
might
be
right.
So
I
love
everything
you
mentioned
lee
everything
there
is
really
strong.
A
We
had
a
question
on
what
are
the
prerequisites?
I
think
you
can
get
into
that
in
the
demo
a
little
bit
as
well.
A
You
know
one
of
the
prerequisites
to
leveraging
palomi
and
I
think
what
we're
really
starting
to
see
is
is
the
enablement
and,
like
you
said,
empowerment
of
developers
to
do
more
of
this
on
their
own,
with
sdks,
with
apis
and
with
tools
like
pollumi,
I
love
crossplane
and
backstage
from
spotify
ambassador
dcp,
like
these
kind
of
control,
plane,
centric
elements
where
developers
don't
actually
really
need
to
know
kubernetes
and
it's
all
about
getting
them
to
know
less,
so
they
can
do
their
jobs
faster
and
actually
produce
more.
A
So
I'll
stop
talking
now
lee
I'm
really
excited
for
this.
Hopefully
the
demo
works.
B
B
I've
had
these
moments
in
my
career,
these
kind
of
epiphany
moments
where
you
start
to
realize
that
everything
you've
been
doing
the
last
few
years
is
really
not
the
right
way,
and
I
had
a
conversation
with
with
a
developer
in
my
old,
the
old
company
that
I
worked
at,
and
I
was
trying
to
get
them
to
adopt
this
infrastructure
tool
that
had
a
learning
curve
and
I'd
spent
like
six
months,
like
learning
how
to
use
this
infrastructure
tool-
and
I
was
talking
to
this
software
developer
and
I
went
to
them
specifically
because
I
knew
that
the
software
developer
was
super
smart
super
capable
like
they
were
the
person
who
I
would
go
to
get
a
get
a
bunch
of
answers,
and
I
was
like
look
we're
going
to
build
this
platform
and
we're
going
to
make
it
we're
going
to
build
it
around
this
infrastructure
tool.
B
And
you
know
I'd
really
like
you
to
be
an
ambassador
for
the
platform
and
all
that
kind
of
stuff
and
their
response.
The
software
developers
response
was
like
it's
really
great,
that
you've
had
six
months
to
learn
this
tool,
but
I've
also
got
other
things
to
do
right,
like
I've
got
to
deliver
features
to
my
users.
I've
got
to
actually
get
things
in
the
hand
of
people,
and
I
don't
really
have
six
months
to
learn
this
tool.
You
know
what
I
mean
and
I
had
realized.
B
I
had
spent
six
months
building
something
and
learning
something,
and
that
was
my
full-time
job,
but
the
software
developers
who
actually
wanted
to
use
the
platform
they
were
like.
I
I
don't
have
time
to
do
any
of
this.
It's
really
cool
and
it's
really
exciting.
But
when
I'm
like,
I,
I
don't
get
to
put
six
months
of
sprint
work
to
learn
this
new
tool
so
that
I
can
help
people
be
an
ambassador
and
it
really
changed
my
perspective
and
it
really
changed
the
way.
B
I
think
about
things,
and
I've
been
thinking
about
that
for
two
years,
and
it's
really
culminated
in
this
particular
talk,
because
when
we
talk
about
humanizing
things,
you
really
have
to
think
about
what
your
end
users
have
to
do
in
order
to
actually
consume
the
platforms.
You're
building
with
cloud
native
technology-
and
I
really
love
like
backstage-
is
a
great
example.
B
What
you
brought
up
there,
mario
of
a
thing
that
has
come
up
around
these
different
needs
right,
like
the
consumers
of
the
people
who
own
and
manage
backstage,
they
get
to
actually
build
something,
and
then
the
consumers
just
get
a
really
nice
experience
and
if
you
think
about
where
all
the
really
great
cloud
native
technologies
are
the
ones
that
give
those
interfaces
that
are
kind
of
flexible
and
buildable
are
really
really
really
taking
off
and
really
starting
to
see
their
usage
explode
and
again.
B
I
think
this
is
one
of
the
reasons
why
kubernetes
is
so
popular.
I
know
it's
a
polarizing
piece
of
infrastructure.
Like
you,
you
know
every
week,
there's
a
new
hacker
news,
article
that
says
we
don't
use
kubernetes
and
we
love
it
and
I'm
like
great.
But
what
about
all
those
people?
You
know
you
know
what
are
they?
What
are
those
people
that
aren't
using
kubernetes
gonna
do
after
this
so
yeah?
I
I
think
you
know,
I
think,
hopefully,
the
ideas
that
I'm
talking
about
are
getting
along,
but
let's
see
it
in
practice
right.
A
B
A
user
interface
perspective,
so
you
probably
saw
a
link
on
the
screen
earlier.
There's
a
github
repo
with
some
pollumi
code
in
it
that
I
kind
of
threw
together
yesterday
evening
that
uses
three
features
of
palumi.
That
will
allow
you
to
really,
I
think,
let
your
users
consume
things
in
a
you
know
in
a
really
nice
way,
and
we
can
either
show
it
now
I'll
show
it
at
the
end.
But
what
I'm
gonna
do
is
quickly
like
go
through
what
I've
actually
built.
B
So,
let's
just
switch
to
screens
here.
This
is
my
vs
code
window,
and
what
I've
done
here
is
build
a
very,
very
lightweight
example
of
building
a
software
sdk
for
delivering
infrastructure
to
a
platform
built
on
kubernetes
right.
So
what
I'm
going
to
do
is
just
quickly
show
you
through
what
this
might
look
like.
I've
written
this
in
our
go
sdk
and
it
you
can
probably
if
you're,
a
kubernetes
user
or
some
of
this
will
look
very
similar.
B
So
you
have
a
namespace,
you
have
a
kubernetes
deployment
and
then
you
also
have
a
kubernetes
service
and
of
course
you
know.
The
idea
here
is
to
you
know.
Just
suspend
your
belief
for
a
second
about
what
a
production
ready
application
might
look
like,
but
what
we're
doing
here
is
is
using
our
the
paloomi
go
sdk
to
actually
like
create
consumable
sdks
in
all
of
palumi's
other
supported
languages,
and
this
like
this,
really
this
this
ability
to
do.
B
This
is
one
of
the
most
strong
things
in
terms
of
humanizing
platform:
accessibility,
because
if
you're
working
in
a
software
engineering
environment,
you
probably
have
a
back-end
language
and
a
front-end
language,
it
might
be
the
same.
You
might
be
using
node
for
both,
but
I've
certainly
worked
in
environments.
Where
you
know
users
will
use,
go
on
the
back
end
and
they'll
use
typescript
on
the
front
end
or
they
might
use.
B
You
know
you
might
be
a
windows
shop
and
be
using
c
sharp
and
f
sharp,
but
being
able
to
actually
allow
your
users
to
consume
your
infrastructure
in
software
languages
that
they
feel
familiar
with
and
comfortable
with,
but
not
having
to
make
them
choose,
I
think,
is
a
really
really
strong
part
of
you
know
creating
a
humanized
platform.
So,
as
I
said,
I've
created
a
an
example:
production-ready
application
that
will
that
is
written
in
go,
but
it
compiles
into
all
of
paloomi
supported
languages.
So
you
we
have
net,
we
have
go.
B
We
have
node.js
and
python
libraries
that
can
be
used
from
this
production
ready
application,
and,
if
you
think
about
what
this
might
look
like
in
practice,
when
you
as
an
infrastructure
platform
owner,
want
to
update
what
a
what
a
production
ready
application
looks
like,
perhaps
you
have
decided
the
the
three
replicas
in
a
you
know
in
a
paloomy
sorry,
in
a
kubernetes
deployment,
three
replicas
is
no
longer
acceptable
for
production
ready
and
you
want
it
to
be
five.
Instead,
you
know
you
can
update
this.
B
You
can
version
it
like
software
and
you
can
ship
it
to
your
users
and
they
just
consume
it
like
a
normal
software
library
that
they're
already
doing
in
their
software
development
lifecycle
and
again.
This
is
actually
creating
software
development
libraries
in
through
in
four
different
ecosystems,
so
your
users
no
longer
have
to
choose
to
learn
a
new
language
or
a
new
configuration
file,
format
or
a
complex
dsl
that
they're
only
going
to
use
for
the
deployment
mechanism
and
they
can
actually
consume
it
in
their
languages
that
they're
already
using
in
their
application
lifecycle.
A
So
leigh,
I
have
a
question
really
quick.
I
I
wanna
I
wanna
unpack
this
a
little
bit.
So
what
you're
saying
is
that
we
can
issue
a
library
being
the
sre
team
being
the
platform
team.
We
can
issue
a
library
that
has
some
of
these
kind
of
expected
defaults
or
best
practices
that
we
want
for
applications
being
deployed
on
our
platform,
and
we
can
write
this
out.
A
We
can
obviously
have
it
reviewed
by
our
co-members
and
and
other
developers
as
well,
and
we
can
issue
it
as
a
library
and
then
kind
of
what
you're
saying
is
you
know
that
library
is
a
go
library,
so
anyone
writing
their
their
microservice
in
golang
can
actually
pull
in
that
library
and
now
get
the
best
of
all
worlds
right.
They
get
everything
that
we
intended
in
terms
of
you
know
what
the
platform
should
look
like.
What
applications
should
look
like
running
on
the
platform
right
and
they
also
get
a
little
bit
of
basically
automation.
A
A
Maybe,
and
maybe
we
get
the
secrets
later-
that's
a
tricky
one,
but
it
seems
like
you
know
I
guess
you're
taking
some
of
that
extra
configuration
that
we
actually
end
up
replicating
in
so
many
repos,
with
values,
files
and
home
charts
and
when
you
have
microservices
and
there's
40
of
them,
you're
really
just
copying
the
same
same
things
over
and
over.
It
sounds
like
this
being
issue.
Is
a
library
that
maybe
you
tag
is
this:
how
most
teams
that
you've
worked
with
are
are
doing
this?
A
B
Yeah,
absolutely
that's
you.
You
basically
hit
the
nail
on
the
head
and
what
I'm
gonna
show.
You
is
three
different
ways
of
consuming
this
library
right.
So
the
like,
we
talked
about,
you
know
different
mechanisms
of
humanizing
these
libraries,
the
building
block
of
those
and
humanize
of
that
humanization,
is
building
these
reusable
libraries
right,
like
you
start
here,
you
start
here
with
like
an
sdk
that
all
the
other
users
can
consume
and
then
they
get
to
choose,
and
I
think
we
all
love
choice
like
choice
is
one.
B
I
think
choice
is
one
of
the
foundations
of
the
cloud
native
foundation,
but
allowing
users
to
be
able
to
choose
how
they
consume.
These
things
is
really
powerful
and
I've
actually
got
examples
that
I'm
going
to
show
you
of
consuming
this
particular
library
that
I've
created
in
three
of
our
different
supported
languages.
So,
let's
look
at:
let's
look,
let's
look
at
the
first
one
right
and
I'm
going
to
start
with
a
traditional
infrastructure
code,
workflow
right.
So
this
is
our.
This
is
the
typescript
library
and
you
can
see
here.
B
It
builds
an
npm
package,
called
palumi
production
app,
and
you
can
see
that
the
actual,
like
the
actual
implementation
of
all
of
this
go
code,
is
four
lines
of
typescript
right.
I'm
gonna
specify
an
image,
I'm
gonna
say
what
image
that,
what
port
that
image
runs
on
and
then
it's
going
to
basically
return
me
a
url
from
my
mini
cube
cluster,
which
you
know
if
you
think
about
the
user.
Experience
of
what
that
looks
like
you
know,
for
for
a
typescript
developer,
a
front-end
engineer.
B
This
is
just
a
very
standard
workflow
for
them
like
import,
a
package,
write
a
couple
lines
of
code
and
I'm
going
to
get
an
expected
end,
end
point,
and
so
I'm
going
to
deploy
the
kuad
example
app
to
a
mini,
cube
cluster
and
let's
take
a
look.
What
that
looks
like
and
again,
I
think
this
is
for
most
people
doing
infrastructure
as
code
or
most
people
in
the
cloud
native
community.
This
is
a
workflow
that
they'll
feel
familiar
with.
B
Like
you
define
something,
and
then
you
run
an
external
command
line
tool
to
actually
deploy
it
might
be
kubectl,
it
might
be.
You
know
any
of
the
other
infrastructures
code.
You
know
things
that
you
might
be
familiar
with,
but
this
is
one
example
of
a
workflow.
B
So,
let's
look
in
my
example,
repo
so
in
samples
node.js
and
just
make
sure
that
I
have
an
index
file
here,
oh
and
type
of
course-
and
you
can
see,
I
have
a
a
little
tiny
kubernetes
cluster
locally,
just
a
micro,
kubernetes
cluster,
and
so
I
want
to
get
my
production
ready
application
onto
this
cluster.
So
what
I
would
do,
let
me
just
bump
this
up
a
little
bit
there
we
go.
B
What
I
would
do
is
run
pull
me
up
so
think
about
this
in
terms
of
coo,
cuddle,
apply
or
something
along
those
lines,
and
you
can
see
it's
going
to
deploy
my
name
space.
It's
going
to
deploy
my
service
and
it's
going
to
create
my
deployment
so
hit
yes,
again,
very,
very
familiar,
familiar
kind
of
workflow.
We
talked
earlier
about
feedback
loops.
B
I
think
this
feedback
loop
is
really
really
good,
because
if
you
think
about
how
cucu
works,
like
you
just
send
off
a
api
request
and
then
you
have
to
do
a
bunch
of
debugging
commands
to
actually
let
you
know
if
any
of
that
actually
worked
or
not,
but
you
can
see
it's
created,
my
namespace,
my
service
and
my
deployment,
and
it's
just
returned
me
the
url
of
what
my
service
is
running
on
and
I
can
actually
verify
that
is
created
you
can
see.
I
have
an
example
namespace
and
in
that
example
namespace
you
can
see.
B
I
have
my
three
replicas
right.
So
this
my
production,
ready
application
has
been
defined
and
is
running
and
it
allows
me
to
as
an
upstream
platform
owner.
It
allows
me
to
define
those
different.
You
know
those
different
things
and
again
like
if
we
imagine
what
this
might
look
like
from
a
downstream
consumer
perspective.
B
B
So
we'll
just
wait
for
a
second,
and
you
know,
let
me
imagine
some
elevated
music
right
now,
while
we,
you
know,
while
we
wait
for
our
library
to
build,
I
could
talk
a
little
bit
about
what
this
is
doing,
but
it's
essentially
generating
the
sdks
for
go
for
net
for
python,
and
you
can
see
it's
actually
creating
a
bunch
of
python
packages.
A
Okay
lee
so
this
this
is
like
the
example
of
basically
us,
as
developers
of
this
library,
issuing
a
new
version
like
a
new
tag
that
other
developers
can
then
say.
Oh
there's
a
new
tag.
I
want
to
pull
that
in
to
my
service
yeah
and
adopt
that,
and
those
changes
inherently
just
are
automatic.
Basically
yeah.
B
Exactly
you
can
actually
see
the
version
here,
so
obviously,
if
you
like,
you
know,
use
proper
semantic
versioning
in
node
packages
or
python
or
all
that
kind
of
stuff,
you
might
update
the
version
to
you
know
1.0
or
0.0.2,
or
something
like
that.
You
know
we're
essentially
just
updating.
We
would
release
this
as
a
new
version.
Again,
your
downstream
users
would
decide
when
they
want
to
pull
this
in.
So
again,
it's
their
choice.
You
know,
there's
nothing
worse
than
somebody
breaking.
A
B
Again,
it's
just
going
to
generate
these
things.
I
think
I
ran
it
twice
because
you
know,
but
oh
well,
so
it's
generating
all
of
the
different
packages
that
we're
actually
going
to
consume
and
then
again,
your
downstream
users
are
going
to
be
able
to
re-run
their
application
and
because
I've
automatically
yarn
linked
into
into
here
the
actual
package.
What
would
actually
happen
is
your
users
would
take
the
dependency
and
do
an
npm
install
in
this
typescript
example.
B
But
if
I
re-run
my
pollu
me
up
now,
we
should
see
that
we're
getting
a
difference
in
our
actual
infrastructure
deployment.
So
if
I
look
at
the
details,
my
replicas
have
now
gone
from
three
to
five
and
you
again,
your
users
are
able
to
actually
experience
this
in
a
more
kind
of
relatable
workflow
to
them.
You
know,
and
even
though
we're
using
imperative
languages,
even
though
we're
actually
using
you,
know
node.js
you'll
notice
that
this
is
a
declarative
process.
B
So
if
I
rerun
my
pollumiop,
it
should
say
there
are
no
changes,
because
we've
already
actually
defined
our
infrastructure
so
again,
declarative,
like
kubernetes
already
is,
but
using
an
imperative,
typescript
language
that
allows
us
to.
Actually,
you
know
feel
like
we're
actually
using
things
that
we
already
feel
familiar
with.
So
I.
B
I
think
this
is
a
super
powerful
workflow,
but
we
didn't
just
talk
about
using
you
know,
typescript
and
all
those
kind
of
things
we
talked
about
going
an
extra
step.
We
talked
about
actually
making
you
know
making
this
relatable
not
just
for
our
software
engineers,
but
for
other
users
within
our
organization
as
well.
So
the
next
thing
that
I
want
to
show
you
is
again
another
example
of
consuming.
B
Excuse
me
another
example
of
consuming
this
particular
software
library
that
we've
created
and
what
I've
done
inside
this
repository
is.
I
have
created
a
power
user
command
line
interface
using
polumi's
automation,
api.
So
if
you
are
a
go
developer,
this
will
look
pretty
familiar
to
you,
I'm
using
the
kingpin,
cli
library
and
you
can
see
I'm
importing
our
go
sdk.
So
again.
This
is
the
same.
B
This
is
the
same
library
that
I'm
concerned
that
I
was
consuming
in
my
typescript
earlier,
but
now
it's
using
the
go
sdk,
but
I'm
I'm
creating
a
command
line
tool
that
I
could
distribute
to
my
users
within
my
audit
within
my
organization,
and
they
can
consume
my
platform
using
a
command
line
tool
that
has
again
abstracted
most
of
the
complexity
away,
but
still
allows
them
to
choose
the
image
they
want
to
deploy
and
the
part
that
they
want
to
choose.
B
So
a
lot
of
this
is
kind
of
and
you'll
see
when
I
run
the
tool.
A
lot
of
this
is
actually
just
a
mechanism
to
make
this
look
pretty
fancy,
but
most
of
the
actual
pro
stuff
is
actually
here.
You.
A
A
B
B
It
looks
it's
basically
the
same.
We're
specifying
an
image
or
specifying
a
port
like
the
actual
consumption
of
this
itself
is
very,
very
familiar
and
it
looks
very
familiar
over
different
languages.
When
I
started
at
palumi
I'd,
never
written
a
single
line
of
typescript.
I
am
now
you
know
not
a
good
typescript
developer,
but
I
certainly
am
way
better
than
I
was
a
year
ago,
but
the
the
the
this
is
kind
of
leveled
up.
B
A
B
So,
let's
so,
let's,
let's
have
a
look
at
this,
so
let's
look
at
the
cli
and
I'm
actually
going
to
rebuild
it.
So
I'm
going
to
do
go
build
my
so
production
app.
If
you
are
a
go
developer,
this
will
look
pretty
familiar,
and
I've
just
noticed
that
my
I
think
my
the
the
tag
is
actually
gonna
cover
up
what
I'm
gonna
run.
So
let
me
very
quickly
do
this
like
that
there
we
go
yes,
that
moving
it
to
the
right
side
would
be
super
helpful.
B
Thank
you
very
much,
mario.
So
I
I've
built
my
go
binary
like
so,
and
you
can
see
it's
called
prod
app
like
this,
and
I
can
actually
look
at
the
help
and
you'll
see
that
I
need
to
specify
a
name
and
I
have
a
deploy
command
and
a
destroy
command.
So
let's
have
a
look.
What
our
deploy
command
actually
does.
B
So
what
my
required
flags
are.
I
need
to
specify
a
name
for
the
deployment.
I
need
to
specify
an
image
and
I
need
to
specify
a
part
that
that
image
runs
on
and
you
can
also
see
because
I'm
using
a
command
line
interface
in
go.
I
can
actually
you
know,
set
defaults.
You
know
I
can
actually
specify
that
port
80
is
the
default
for
these
different
things.
B
So,
let's
run
my
prod
app
and
I'm
going
to
specify
a
name
of
example,
cli
and
then
my
image,
I'm
just
going
to
run
the
nginx
image
for
this
particular
example
like
so
and
again,
if
you
think
about,
if
you're
a
cli
power
user,
you
know
an
image
you
want
to
run.
You
know
what
you
know.
You
know
what
you
want
to
call
the
thing
that
you're
going
to
deploy.
So
let's
run
this
unknown
long
flag,
image.
B
Well,
you
know,
oh,
I
haven't
actually
specified
a
command
that
will
help
won't
it,
so
I
actually
need
to
run
the
deploy
command.
That
would
probably
help
so
I'm
gonna
run
deploy
and
the
name
and
the
image
like
so-
and
I've
built
this
list,
and
I'm
I'm
saying
I'm
but
my
actual
wonderfully
talented
colleague
kamal
ali
actually
built
this.
B
This
a
beautiful
ui
and
it's
going
to
deploy
my
kubernetes
deployment,
my
kubernetes
service
and
my
production,
my
actual
deployment
and
the
paloomi
stack,
and
it's
going
to
actually
do
all
of
the
preloomy
stuff
that
we
did
in
our
pull
me
up
and
I
haven't
invoked
palumi
at
all.
I
haven't
used
the
paloomi
cli
in
any
way
at
all,
and
I
can
verify
again
that
this
is
actually
deployed
by
getting
my
namespaces
and
you
can
see.
B
I
have
this
production
app
namespace
that
it's
actually
going
to
create
ctl,
get
po
minus
in
production
and
here's
my
five
replicas,
so
I
updated
my
library
earlier,
I
rebuilt
my
you
know.
I
rebuilt
my
command
line
tool
with
the
new
dependencies
that
I
have
and
I've
been
able
to
deploy
my
infrastructure
in
a
way
that
my
my
organization's
command
line,
users
feel
comfortable
with
and
feel
familiar
with,
and
if
you
wanted,
you
can
stick
this
directly
in
your
ci
pipeline.
B
Right,
like
you,
can
abstract
all
of
this
away
in
your
cei
pipeline
without
actually
having
to
worry
about
all
of
the
different
steps
and
all
that
kind
of
stuff.
Your
entire
infrastructure
portal
has
been
bundled
into
a
command
line
interface
that
you
can
just
throw
into
a
ci
pipeline.
A
This
is
literally
amazing,
so
I
actually
have
a
use
case
for
this
in
my
own
organization.
We're
building
a
singular
tool
that
tool
we're
building
to
solve
for
local
local
development
and
eventually
remote
development,
ephemeral,
environments,
right
and
plumi
here
can
provide
so
much
right
like
we
can
build
plumie
into
that
tool.
We
don't
have
to
have
people
learn
fluently
as
well
and
pulling
me
up
right.
It
just
everything's
kind
of
built
in
and
integrated
right,
so.
A
Is
one
of
those
things
where,
if
you're
getting
to
the
size
and
you're
saying
okay,
we
need
to
abstract
away
this
complexity,
provide
a
single
kind
of
streamlined
path
to
do
these
things
right
and
and
something
that
encapsulates
all
of
the
the
things
we
care
about,
whether
it's
like
security,
whether
it's
linting,
whether
it's
like
certain
configurations
for
our
monolith,
that
gets
deployed
right
and
that's
all
into
one
tool
that
you
you
maintain
and
manage,
and
then
you
just
slip
stream.
A
You
know
plummy
configuration
and
your
kind
of
de
facto
library
for
what
deployments
and
managing
those
apps
looks
like
like
this
is
incredibly
powerful.
I
think
you
know
if
you're
a
startup
you're,
probably
not
necessarily
using
this,
depending
on
on
what
you're
doing,
maybe.
B
Talking
about
hey,
you
know,
I'm
just
trying
to
get
off
the
ground.
You
know
I'm
just
trying.
A
B
Get
my
my
application
from
a
to
b.
This
is
a
lot
of
you
know,
there's
a
lot
of
work
in
those
situations,
but
in
those
larger
organizations
where
you
know,
you've
already
built
a
working
platform
and
what
you're
now
thinking
about
is
how
this
looks
for
your
users.
This
is
such
a
powerful
way
to
do
things.
You
know
and
then
there's
one
final
thing
that
I
want
to
show
you
and
I'm
just
conscious
of
the
time.
B
Well,
we
talked
about,
I
mean
command
line
interfaces
and
software
sdks
are
one
mechanism
for
actually
delivering
infrastructure,
but
we
also
talked
about
those
users
who
are
very
used
to
web
applications
and
consoles
so
again,
building
off
the
of
the
work
that
a
very,
very
talented
colleague
of
mine,
called
kamal
ali
did,
and
I'm
just
going
to
extend
this
so
I
can
switch
screens.
I've
also
embedded
this
into
a
python
flask
web
application.
B
So
if
we
take
a
look
in
our
in
our
source
code
here
again
we're
going
to
consume
our
production
application
inside
a
web
application
and
I'm
going
to
import
my
deployment
and
deployment
args
and
again
remember
I've
only
written
this
code
in
one
language
right,
like
I
haven't
written,
I
haven't
had
to
maintain
four
different
languages
here:
I've
written
it
in
one
languages
and
it's
generated
sdks
for
me
in
four
different
languages.
B
I
can
now
create
a
very
simple
flask
web
application
that
does
a
paloomy
deployment
within
the
web
application
itself
and
there's
considerations
here,
for
example
like
timeouts
like
web
timeouts,
and
all
that
kind
of
stuff
like
infrastructure
provisioning,
can
take
a
little
a
little
while
sometimes
so
like
building
this
into
web
applications
has
different
considerations
that
you
might
want
to
think
about
retries
and
all
that
kind
of
stuff,
but
and
actually
retries
is
not
a
great
example,
but
you
may
want
to
do
things
like
dispatch
to
a
worker,
for
example
like
a
kubernetes.
B
Pod
is
one
thing
that
I've
seen
a
pattern
of
where
a
web
application
will
dispatch
a
kubernetes
pod,
which
runs
pollumi
but
again,
like
the
paloomi,
like
the
actual
pollumi
is
three
lines
of
python
right.
It's
just
a
web
application
that
is
gonna
again
deploy
to
our
kubernetes
cluster.
So
I'm
gonna
start
this
little
python
web
server
and
you
can
see
you've
got
a
sneak
peek
there
that
I
already
started
earlier
to
make
sure
it
works.
B
So
we
have
no
active
deployments
right,
so
I
can
specify
a
name.
Let's
call
it
web
app
example
and
again
I'm
gonna
deploy
the
docker
docker
image
of
nginx
latest.
If
I
click
create
and
move
back
to
my
cli,
you
can
see
again
it's
it's
actually
running
pollumi.
In
the
background
like
this
python,
sdk
is
actually
provisioning.
Things
and
again,
we've
got
our
five
pods
available
here.
B
It's
actually
provisioning
things
into
our
kubernetes
cluster
via
the
web
application,
and
you
can
actually
see
that
and
if
you,
if
you're
a
way
more
talented
front-end
engineer
than
I
you
could
actually
you
know
perhaps
stream
this
in
your
web
application,
so
that
your
non-technical
users
can
get
an
example
of
what
this
looks
like.
And
if
I
go
back
to
my
web
platform
thing
I
now
have
my
web
example
has
been
deployed
and
you
know
I
can.
B
If
I
had
the
networking
setup
for
mini
cube
correctly,
I
could
actually
open
this
page
and
go
directly
to
my
nginx.
You
know
my
nginx
example,
so
these
these
are
different
ways
that
you
can
actually
build
these
reusable
libraries,
but
then
you
can
actually
due
to
the
flexibility
that
we
provide
in
the
paloomi
cloud
engineering
platform.
This
allows
you
to
choose
and
decide
what
ways
your
users
will
be
able
to.
You
know
what
way
your
users
be
able
to
consume
it,
and
I'll
also
just
have
to
caveat.
B
I
think
I
mentioned
this
before.
I
don't
particularly
consider
myself,
a
talented
software
engineer
I
from
an
infrastructure
background
right.
I
I
learned
htl,
I
wrote
bash
scripts.
I
wrote
you
know
I
wrote
you
know:
yaml
configuration
files
for
years
and
years
and
years,
and
I
threw
this
together
last
night
in
a
couple
of
hours.
So
if
you're,
an
actual
talented
software
engineer
and
you're,
actually
capable
of
doing
these
things,
imagine
the
kind
of
things
that
you
could
build,
that
your
users
will
be
able
to
actually
consume
and
use.
A
I'm
glad
you
said
that,
because
I
am
a
terrible
programmer.
I
am
acknowledging
that
here
in
public.
I
don't
even
know
what
I'm
doing
most
of
the
time,
and
this
looks
simple
enough
to
me
right.
You
know
I'm
good
at
reviewing
code
and
looking
for
things
that
don't
make
sense,
because
I
try
to
like
take
and
understand
the
logic
and
peace
it
out
right.
So
I
love
how
simple
this
has
gotten,
and
this
is
this
is
amazing.
A
This
is
again
is
the
we
want
to
provide
a
platform
to
our
users
and
we
we
can
do
it
either
via
you
know
the
web,
we
can
do
it,
be
a
cli
or
a
simple
library
right
and
everyone
works
on
a
different
kind
of
plane
and
wants
the
the
flexibility.
So
I
love
the
flexibility.
Are
these
new?
Is
this
new
to
pluma,
or
is
it
just
gotten
easier.
B
I
think
both
the
the
automation
api
has
been
around
now
for
a
year
and
honestly
like
if
I
could
tell
you
some
of
the
incredible
things
that
people
have
built
with
the
automation
api
it
just.
It
blows
me
away
all
the
time
like
what
people
like
you
know.
One
of
the
reasons
I
like
to
show
this
this
web
platform
type
example
is
because
we
have
users
that
are
actively
building,
not
just
internal
web
platforms
but
actual
provisioning
tools
for
external
users
that
heavily
leverage
polumi's
automation,
api
to
provision
infrastructure.
B
You
know
it's,
it's
such
a
powerful
mechanism.
It's
been
around
about
a
year
now,
you
know,
and
again
I've
got
to
give
shout
outs
to
my
colleague
kamal
who
has
really
put
in
lots
of
effort
and
another
colleague
of
mine
evan,
who
has
really
just
kind
of
completely
kind
of
seen
what
the
potential
and
possibility
of
the
automation
api
is
and
really
created
this
incredible
flexible
tool.
B
The
multi-language
part
that
I've
showed
you
where
you
can
write
a
component,
that
you
can
reuse
in
one
language
and
it
generates
sdks
in
all
four
available
languages.
That's
a
new
feature
that
we
announced
earlier
this
year
and
if
you
think
about
like
the
maintenance
burden,
that
people
had
that
were
creating
these
reusable
components
before
this.
If
they
wanted
to
support
all
pollutant
users,
they
had
to
maintain
languages-
and
you
know,
maintain
libraries
in
four
different
languages
and
the
maintenance
burden
was
just
crazy.
B
You
know
we
what
we
are
planning
on
doing
we're
working
on
right
now
is
we're
actually
working
on
creating-
and
I
don't
have
an
end
date
for
this,
but
it
is
on
the
it's
in
in
progress.
Right
now
is
we're
building
a
registry
which
will
allow
you
to
share
these
components
and
build
them
and
actually
distribute
them
to
other
users
as
well.
So
right
now
you
can
see.
B
This
is
all
in
a
git
repository
that
I
you
know
that
I
kind
of
maintained-
and
you
can
take
a
look
at
this
like.
I
would
encourage
you
to
go
and
have
a
look.
I'm
just
gonna
bring
up
the
page
if
you
I'm
just
gonna
bring
it
up
here.
My
fingers
have
just
completely
stopped
typing,
but
I'm
gonna
just
type
it
in
here.
B
So
this
is
the
the
repository
is
available.
If
you
wanna
take
a
look
at
it,
you
can
you
know-
and
you
can
see
I
was
working
on
this
an
hour
ago,
and
it
should
give
you
examples
of
how
to
build
and
look
at
this
thing.
B
But
if
you
want
to
see
what
this
looks
like
it's
all
in
here,
so
please
don't
hesitate
and
you
can
also
reach
out
to
me
on
twitter
at
brixell
and
I'm
quite
happy
to
kind
of
walk
you
through
some
of
these
examples
as
well,
but
we
are
going
to,
as
I
mentioned,
be
creating
a
registry
that
will
allow
you
to
build
these
components
which
we're
looking
at
in
here
inside
our
inside
out
this
provider
package.
B
So
this
production
app,
these
components
will
be
reusable
and
resharable,
and
so,
if
you
think,
if
you're
a
helm
chart
maintainer
if
you're
a
module
maintainer,
you
know
the
possibility
for
you
to
be
able
to
write
these
kind
of
things
and
reach.
You
know
think
about
how
large
the
javascript
community
is
you're,
basically
reaching
every
javascript
engineer.
There
is-
and
you
can
do
that
relatively
easily,
with
these
kind
of
multi-language
components.
A
This
is,
this
is
amazing.
This
is
the
next
iteration
of
palumi,
and
this
is
what
makes
it
easier,
which
makes
it
more
composable,
repeatable,
shareable
portable,
all
of
those
fundamentals,
all
of
those
principles
that
we
are
trying
to
build
modern
platforms
on.
I
think
right-
and
I
think
this
is
amazing-
focus
on
services
focus
on
developers.
It's
so
great
to
see
this.
I
really
wish
now
that
I
would
have
been
looking
at
plumi
at
least
some
point
in
the
past
few
months
and
and
playing
around
with
it.
A
I
definitely
will
be
maybe
even
this
weekend.
This
is
this
is
exciting,
stuff
lee
what
you
know
you
mentioned
the
road
map
a
little
bit.
What
is
some
of
the
the
key
things
that
you're
seeing
the
teams
that
are
using
polomi
right
now?
What
are
they
looking
at
and
asking
for
in
terms
of
like
more
maybe
more
power
in
control
over
what
is
possible,
more
flexibility
in
dealing
with
monoliths
or
enterprise
applications,
I'm
bringing
those
into
the
the
mold
of
kubernetes
land?
What
is
kind
of
the
the
hot
tub
take
there.
B
One
thing
that
I
think
you
know
we
see
quite
a
bit:
we
have
a.
We
have
a
kubernetes
operator
which
will
actually
kind
of
in
get
involved
in
the
reconcile
loop
that
comes
with
kubernetes
and
the
kubernetes
operator
actually
uses
the
automation
api
inside.
It
was
one
of
the
first
things
we
built
with
the
automation
api.
B
One
thing
that
we're
really
seeing
is
like
that
convergence
right,
like
the
idea
that
your
infrastructure
converges,
like
you
know,
if
you,
if
you
are
using
kubernetes,
you
are
used
to
this
idea
that
it
has
this
kind
of
self-healing
element
to
it,
and
so
we
use
our
kubernetes.
We
have
multiple
companies
using
our
kubernetes
operator
that
are
really
just
kind
of
looking
for
more
more
of
that
convergence.
B
Right
like
this,
if
you
imagine
running
palumi
in
a
four
while
loot
or
for
a
while
loop,
that's
one
really
kind
of
thing
that
we're
kind
of
working
on
and
looking
at,
and
I
think
that's
a
again
like
marrying
these
two
two
kind
of
technologies.
Together,
I
think
is,
is
really
you
know
such
a
really
strong
pattern
that
can
allow
you
to
not
only
feel
comfortable
in
the
way
you
deliver
infrastructure
and
applications.
B
It
also
makes
you
feel,
like
your
users,
just
understand
a
little
bit
more.
What
is
going
on
in
their
infrastructure
and.
A
B
You
know
I
the
this.
This
has
been
an
example
of
using
polumi
to
kind
of
solve
the
problems
that
I
talked
about
earlier,
but
if
you
don't
want
to
use
pollumi,
I
would
just
implore
you,
when
you
make
this
tooling
decisions
and
when
you
decide
how
to
do
things
within
your
organization,
think
about
what
the
end
users
want
like.
I
have
personally
been
one
of
those
people
who
has
just
tried
to
shove
this
technology
down
people's.
You
know
down
people's
throats
in
in
some
respect,
and
you
know
it
it's
it's.
B
It's
a
much
more
invigorating
and
empowering
way
of
working
with
your
colleagues
if
you
just
think
about
what
they
want
and
like
we
are
all
here
to
help
each
other,
and
that's
really
what
I
want
to
talk
like.
This
is
why
I
love
this
slide.
This
cloud
engineering
for
everyone,
like
all
of
the
big
cloud
providers
and
kubernetes
themselves,
have
such
a
huge
learning
curve.
There's
such
powerful
pieces
of
technology
and
all
the
other
cloud
native
software
there's
such
powerful
pieces
of
technology,
but
you
have
to
be
real.
B
You
have
to
remember
that
the
you
as
a
cloud
native
ambassador
or
you
as
a
cloud
native
user.
You
have
time
to
kind
of
take
these
things
in
the
people
who
are
using
them
and
consuming
them.
Don't
always,
and
if
you
think
about
how
people
want
to
consume
these
things,
I
think
it
gets
a
lot
more
human.
A
That's
absolutely
it.
I
remember
talking
to
developers
and
trying
to
explain
to
them
pod
anti-affinities
and
they
were
like.
I
don't.
I
don't
care
yeah.
B
A
Exactly
exactly
so
simplifying
getting
to
the
the
kind
of
brass
tacks,
if
you
will
of
what
are
we
trying
to
do?
I
just
need
to
ship
this
application.
It
needs
to
be
somewhat
redundant
and
reliable
and
providing
that
reliability
is.
You
know
your
job
in
a
lot
of
cases,
if
you're
an
sr
engineer
a
devops
engineer
platform,
whatever,
whatever
you
want
to
call
it,
we
have
plenty
of
overloaded
terms.
I
have
so
many
more
questions,
but
we
have
kind
of
come
to
an
end
here.
One
thing
I'll
highlight
really
quick.
A
That
happened
while
we
were
chatting
is
that
the
kubecon
and
cloud
native
con
north
america,
2021
schedule
has
just
released.
So
please
check
out
twitter,
the
cncf.io
website
for
more
information
on
that.
That
event
is
in
person
and
virtual.
I
will
be
there,
I'm
going
early
lee
any
final.
Any
final
thoughts.
B
No,
I
just,
I
really
appreciate
the
the
great
questions
that
you
asked.
It's
been
a
great
experience
if
you
are
watching
this
on
youtube
later
on
today,
and
you
have
any
other
questions
then
just
feel
free
to
dm
me
at
brexitel,
or
you
can
talk
directly
to
us
at
palumi
at
palumi
cop.
A
Absolutely
love
it!
Thank
you
so
much
everybody
for
tuning
in.
We
really
appreciate
you
coming
to
cloud
native
live,
and
I
think
next
week
is
going
to
be
probably
just
as
exciting
as
this
week
so
definitely
tune
in
subscribe,
and
thank
you
so
much
for
your
time
have
a
great
rest
of
your
day.
Bye.
Everybody
thanks.