►
From YouTube: Admiral Bash's Island Adventure with Phi... John Forman, Simon Forster, Danielle Cook & Robert Glenn
Description
Don’t miss out! Join us at our next event: KubeCon + CloudNativeCon Europe 2022 in Valencia, Spain from May 17-20. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Admiral Bash's Island Adventure with Phippy + Friends | A Book Reading
Admiral Bash's ship has been sunk by pirates and his mainframe is at the bottom of the sea! Washed up on a deserted island, join Admiral Bash as he navigates his cloud native transformation, helped by Phippy, Zee, Captain Kube, Goldie and some very special new friends. Will the team ever get to enjoy cocktails on the beach, or will this cloud native transformation prove too much? Authors Simon Forster, Danielle Cook, John Forman, and Robert Glenn, from the Cartografos working group, present a first-look at this brand new book!
A
B
B
So
today
we
wanted
to
introduce
our
new
book.
I
admiral
bash's
island
adventure
with
fippy
and
friends.
So
why
did
we
create
another
book
right?
We
wanted
to
just
like
the
other
books
in
the
series.
We
really
wanted
to
convey
a
complex
topic
as
simply
as
possible
to
really
be
able
to
be
accessible
by
children.
If,
if
it
can
be
read
by
a
child,
then
it
can
be
read
by
a
c-suite
right.
B
That's
the
goal,
so
so
we
we
actually
developed
a
framework
for
understanding
the
maturity
model
or
understanding
the
the
the
landscape.
The
cncf
landscape
has
exploded
over
the
past
couple
of
years.
How
do
we
navigate
it
right?
How
do
we,
how
do
we
bring
our
organizations
larger,
multinational
organizations
to
really
achieve
you
know
the
these?
The
the
landscape
right?
So
we
wanted
to
divide
up
actually
the
tools
and
technologies
and
experience
the
journey
into
five
phases
which
we
are
calling
our
maturity
model.
B
And
if
you
want
to
get
involved,
we
have
some
some
slides
later
about
how
to
how
to
do
that.
But
you
can
check
out
our
maturity
model
on
github.
We
have
released
it
and
we
are.
We
are
looking
for
some
help
to
to
improve
it,
and
we
are
looking
for
feedback
on
on
how
we
can
how
we
can
grow
it
and
maybe
how
we
can
make
it
more,
even
more
accessible
to
to
you
and
to
to
your
teams.
C
All
right,
so
how
did
we
get
here?
Good
question
glad
you
asked
that
question
so
over
the
last
five
years
or
so
there's
been
a
journey
to
many
different
things.
First,
if
you
guys
remember,
there
was
a
big
journey
in
the
cloud.
Every
was
flocking
to
the
cloud,
but
then
when
they
got
to
the
cloud
they
realized,
we
need
to
develop
stuff
as
well.
So
then
the
whole
tech
ops
journey
began.
C
How
do
does
take
up
the
best
way
in
a
kind
environment
and
by
the
way,
that's
what
complex,
because
now
it's
multi-cloud,
how
do
I
build
a
devsecops
pipeline
in
a
multi-cloud
world?
It's
challenging
it's
difficult,
so
it
ended
everything.
Then
there's
kubernetes,
big
bang
kubernetes
became
the
operating
system
of
the
cloud.
C
So
now
you
have
three
journeys
going
on
in
different
three
different
work:
streams
where
people
weren't
going
to
the
cloud
they're
trying
to
figure
out
devsecops
in
the
cloud
and
then
there's
a
new
thing
called
kubernetes.
How
do
we
do
all
this?
How
do
we
make
a
true
multi-cloud
world
with
these
different
tools?
Well,
that's
where
the
world
changed
and
shifted
to
cloud
native.
C
C
All
right,
so
the
aim
of
the
cardiographic
working
group-
I
said
it
correctly.
This
time
is
that
you
know
we
want
to
be
able
to
build
a
framework
for
the
world.
Were
you
looking
at
difficult
going
to
cloud
and
kubernetes?
How
do
we
take
this
trail
map
and
the
eyesore
of
cncfcio,
where
you
see
a
thousand
icons
of
all
these
amazing
little
icons,
prometheus
and
others
right?
But
how
do
you
map
that
to
something
real?
C
That's
what
the
framework
was
created
this
way
the
average
user
and
developer
on
the
street
can
take
all
this
information
and
do
something
with
it.
So
I
speak
with
many
clients
on
a
daily
basis
and
I'm
constantly
re-effecting
the
wheel
for
every
migration
that
we
do
in
every
journey
that
we
do
I'm
like.
Why
are
we
doing
this?
C
The
aim
that
we
want
to
achieve
is
we
want
to
work
not
only
with
the
cncf
but
view
also,
so
it's
working
with
inside
the
cncf
and
the
ecosystem,
with
cyra
and
other
friends
out
there,
along
with
clients
and
customers,
to
help
us
achieve
this
goal.
This
is
something
that's
it's
early
stages
over
the
last
10
months,
we've
built
what
you
see
today
and
it's
a
lot
of
blood,
sweat
and
tears,
but
still
with
love.
C
But
the
main
point
is
that
you
know
we're
on
a
journey
here
and
we're
not
going
anywhere
we're
in
this.
You
know
for
the
long
haul
and
we
want
to
work
with
you
to
make
this
real.
I
think
everybody
in
this
room
and
across
the
world
the
internet
sees
the
value
here.
Listen.
I
hope
you
do
because
we
definitely
see
a
strong
value
to
do
this.
B
Yeah
so,
as
john
mentioned,
we
had
three
work
streams,
kind
of
simultaneously
working
on
these
maturity
models
and
this
this
framework
in
which
to
break
up
this
journey
right.
So
what
we
did
over
the
past
eight
months,
or
so
we
have
combined
the
the
models
into
a
single
framework
and
one
of
the
really
the
the
really
great
things
that
came
out
of
this
was
we
actually
focused,
instead
of
just
focusing
on
tools
on
tooling
tool
sets
and
and
just
the
the
landscape.
B
We
wanted
to
focus
on
things
like
the
people,
who's
who's
actually
going
to
be
developing
this
stuff
who's
actually
going
to
be
planning
this
stuff
right,
you're
again,
the
c-suite,
the
vps,
the
sales
people.
How
did
how
do
the
sales
people
talk?
Kubernetes
right?
We
need
them
to
so.
The
goal
here
is
to
is
to
be
accessible
from
a
lot
of
different
audiences
in
within
the
organization
to
really
convey
this
complex
topic
and
break
it
up
again
into
multiple
years,
so
that
it
can
be
achievable.
It's
not.
You
know
how
do
you?
A
So
what
we
did
to
actually
come
up
with
this
each
one
of
us
had
worked
on
a
maturity
model.
So,
as
I
said
before,
we
had
the
fairwinds
kubernetes
maturity
model
which
looked
at
everything
from
starting
with
kubernetes
all
the
way
through
to
what
you
know.
The
ultimate
goal
was,
and
then
simon
who
is
presenting
there.
He
had
worked
on
one
that
looked
at
what's
the
journey
from
your
legacy
systems,
all
the
way
to
cloud
native
and
then
robbie
and
john
had
put
together
a
maturity
model
as
well.
A
So
we
took
all
of
these
maturity.
Models
worked
on
them,
went
line
by
line
through
them
and
came
up
with
kind
of
the
five
stages
that
we
saw
of
your
cloud
native
maturity.
So
the
first
is
hey
you're,
building
something
you're,
not
in
production
but
you're
playing
around.
Then
you
move
to
when
you're
actually
going
to
operationalize
your
cloud
native
infrastructure
and
your
applications.
A
You
move
on
to
scaling,
which
is
level
three,
which
is
when
hey
it's
time.
We
need
to
do
more
with
this.
We
need
to
make
sure
that
the
organization
across
can
use
all
the
cloud
native
tools
and
process
we
put
in
place.
Then
you
move
to
improving
it
and
optimizing
it.
So
there's
five
levels
of
the
cloud
native
maturity
model
and
then,
as
as
robbie
mentioned,
we
divided
it
when
we
were
going
through
it.
A
A
We
looked
at
the
process
that
you
have
to
put
in
place
policies
you
have
to
put
in
place
like
how
does
that
look
from
level,
one
all
the
way
to
maturity
and
then
finally,
we
did
look
at
the
technology,
so
we
have
that
throughout
the
maturity
model
and
then
we
have,
but
we
do
have
a
number
of
resources.
So,
as
I
said
on
github
or
as
one
of
us
said
on
github,
you
can
look
and
you
can
see
exactly
how
we
did
it.
What
we
did.
We
have
a
prologue.
A
We
have
each
definition
of
each
stage
and
we
also
have
a
master
spreadsheet,
so
you
can
look
through
all
of
our
workings
and
see
how
it
came
to
be
now.
We
have
the
bit
that
we
really
wanted
everybody
to
be
here
for
which
is
the
book
and
so
we're
gonna
simon's
gonna
read
the
book
to
you
and
then
we're
going
to
go
through
what
it
actually
means.
So
we've
talked
about
the
cloud
native
maturity
model
right
now.
The
book
represents
the
model.
So
we're
going
to
do
some
interpretation
of
the
book
for
you
afterwards
and.
C
D
D
Suddenly,
admiral
bash
came
under
attack
by
pirates
weighed
down
by
a
heavy
mainframe
admiral
bash
could
not
maneuver
away
from
danger,
so
the
lifeboats
shouted
admiral
bash.
As
the
ss
legacy
started
to
take
on
water
captain
q,
a
fellow
explorer
was
able
to
evade
the
pirates
and
watch
them
safety
from
a
submarine.
D
After
the
ss
legacy
sunk,
admiral
bash
and
his
crew
were
washed
up
on
shore
with
where
they
were
met
by
captain
q
and
his
friends,
we'd
better
start
settling
the
island.
We
need
shelter
and
water
and
we
need
to
replace
our
mainframe
to
run
the
island.
Let's
draw
up
full
plans
and
then
we'll
start
building.
D
If
we
wait
to
drop
the
plans
before
building
we'll
waste
time,
we
must
get
shelter
and
water
quickly,
let's
start
inspect
and
adapt
as
we
go,
we'll
cover
the
basics
and
change
direction
quickly
and
when
needed.
Let's
use
our
experts
across
teams,
admiral
bash
agreed
with
captain
cube
and
the
team
went
to
work.
D
Goldie
and
captain
cube
were
there
to
help
goldie
knew
that
the
regulator
ravens
used
their
eagle
eyes
to
keep
order
and
would
wave
their
police
badges
if
they
spotted
little
gaps
in
security,
assemble
the
basics,
shelter
and
water
supplies
and
get
the
computer
available
and
admiral.
We
need
to
think
about
security.
D
D
Goldie
helped
some
of
admiral
bash's
penguin
crew
set
up
a
basic
installation
of
kubernetes,
with
cube
adm
to
get
familiar
with
kubernetes.
The
crew
deployed
a
mapping
application
by
hand
with
help
from
a
friendly,
cube,
cuttlefish.
The
mapping
app
was
small
and
scaled
well
and
showed
how
kubernetes
could
help
the
penguins
build.
The
settlement,
admiral
bash's,
busy
crew
got
into
the
swing
of
things
quickly.
D
D
D
D
D
D
D
Fifi
was
very
invested
in
this
phibi's
long
neck
made
them
the
only
animal
able
to
hang
the
phone
lines
but
unbeknown
to
admiral
bash.
The
pirates
who
attacked
the
ss
legacy
had
discovered
the
island,
never
missing
an
opportunity.
The
pirates
started
phone
freaking
using
high-pitched
whistles.
They
were
an
ever-present
threat
that
no
one
was
paying
attention
to.
D
Now
the
penguins
were
confident
with
the
new
technology
they
built
more
and
more
applications,
but
admiral
bash
and
his
crew
started
struggling
with
repetition.
The
penguins
had
even
reinvented
the
wheel,
hazel
the
helm
hedgehog
noticed
they
keep
repeating
steps
which
was
very
time
consuming
so
hazel
helped
them
to
simplify
everything.
She
created
charts
listing
each
component
for
the
penguins.
These
templates
mapped
out
exactly
what
was
required
for
an
application
deployment.
D
D
Community
focused
cows,
esmeralda
and
margarita
saw
an
opportunity
to
sell
the
different
components
that
penguins
needed.
They
opened
a
store
that
sold
wrenches
pliers
saws,
get
and
even
some
standard
applications
and
policies
to
make
life
even
easier.
Hazel's
charts
were
available
at
no
more
wheels.
D
D
Luckily,
linky
the
lobster
had
a
plan
linky
had
their
team
of
lobsters,
write,
messages
on
shells
and
encrypted
code.
Then
a
saharan
silver
ant
collected
the
messages
and
transported
them
to
another
lobster
who
decoded
them
that
stopped
the
regulator
ravens
from
complaining
and
stopped
the
pirates
from
eavesdropping.
D
As
the
settlement
grew,
goldie
created
a
machine
to
help
the
penguins
build
well-crafted
applications.
The
penguins
could
put
their
code
and
dependencies
in
one
side
to
be
built,
tested
and
scanned.
Now
the
other
side
came
little
containers
that
were
delivered
to
separate
kubernetes
clusters
by
conveyor
belt,
with
each
cluster
having
a
different
role
for
development
and
testing.
D
D
D
The
curious
thing
started
to
happen
with
admiral
bash's
penguins,
rather
than
lining
up
in
ranks
and
moving
together,
sometimes
after
delay.
There
was
always
one
laggard.
The
penguins
now
worked
in
little
groups,
they'd
stand
together
in
front
of
white
boards
for
15
minutes
a
day
and
then
work
in
their
own
little
groups,
the
penguins
loved
it.
They
worked
on
one
thing
yet
as
a
whole,
they
completed
big
projects.
D
D
Z
clocked
the
time
it
took
for
the
penguins
to
release
software
counting
the
number
of
successful
releases,
the
faster
the
better,
the
beavers
were
very
close
to
continuously
building
houses
saved
for
the
foreman
sign-off
and
on
the
code
side.
Now
that
all
the
application
tests
were
automated,
all
fibby
had
to
do
was
approve
each
code
release.
Everything
was
continuously
continuously
delivered
up
to
that
point,
the
black
spots
were
very
popular.
D
The
penguins
used
them
to
speed
development
by
quickly
testing
their
applications,
including
their
deployments,
simply
by
checking
and
manifesting
to
get
the
penguins
watched
as
the
fluxwats
deployed
them
and
looked
to
use
them
for
production.
The
regulator
ravens
were
happy
as
it
meant
the
cube
cuttlefish
couldn't
make
ad
hoc
changes.
Whenever
asked
by
a
penguin,
the
ravens
were
always
taking
a
hard
line.
D
The
feedback
loop
got
stronger,
the
penguins
got
feedback
out
of
their
deployment
pipelines
and
put
it
straight
back
into
their
code.
The
beavers
and
molds
found
small
building
defects
and
logged
the
issues
as
they
repaired
them.
Learning
on
the
job,
the
regulator,
ravens
refined,
the
policies
based
on
what
the
penguins,
beavers
and
moles
found
the
ravens
made
sure
the
policies
were
available
at
no
more
wheels.
D
Admiral
bash
noticed
the
crew
was
experimenting,
a
lot
more
and
had
some
new
ideas
for
the
beavers.
Everyone
has
become
much
more
comfortable
experimenting.
The
community
is
actively
contributing
said,
captain
cube,
esmeralda
and
margarita
started
an
online
marketplace
for
no
more
wheels
to
make
its
stock
even
more
accessible.
D
D
The
penguins
used
goldie's
machine
learning,
algorithms
to
predict
when
load
would
increase
or
decrease
admiral
bash's
existing
clusters
scaled
easily.
Excitingly
new
clusters
were
created
automatically
when
needed.
Admiral
bash
was
in
awe
the
machine
handled
the
deployment
of
packages
with
lots
of
measurement.
D
D
Goldie
was
pleased.
Our
applications
match
our
platforms,
the
old
mainframe
monoliths
have
been
broken
up
and
the
applications
were
now
loosely
coupled
the
crew
was
out
able
to
update
parts
of
the
applications
much
more
easily
admiral
bash
exclaimed.
This
is
what
we
wanted.
We've
come
so
far
since
the
pirates
sunk,
our
mainframe,
and
we
settled
this
uninhabited
island
with
that.
The
cheer
went
up,
hooray.
D
A
A
So,
first
up
we
when
we
we
talked
earlier
about
how
people
were
a
big
part
of
the
theme
throughout
the
maturity
model
and
really
it's
about
the
organizational
change.
So
when
you
adopt
cloud
native,
it's
not
just
hey
here's
some
technology,
it's!
How
are
we
going
to
work?
How
are
the
people
going
to
do
it?
What
skills
do
we
need
in-house?
So
we
represented
this
in
the
book
with
admiral
bash.
Talking
to
captain
cube,
I
mean.
A
D
D
They
are
our
most
obvious
symbol
of
community
and
open
source
in
the
book,
with
fair,
shot,
no
more
wheels,
but
look
a
little
deeper
and
we
can
pick
out
other
things
that
map
to
people,
process
policy
and
technology
first
off
with
people.
You'll
have
noticed
earlier
in
the
book
that
there's
a
focus
on
working
together
with
our
friends.
Captain
cube
for
easy
and
goldie
all
lending
a
hand
to
admiral
bashing's
penguin
development
team.
D
We
see
that
everyone
can
contribute,
no
matter
their
skill,
location
or
situation,
whether
you're
a
penguin
just
starting
out
and
getting
lessons
from
phippy
or
a
rock
star
like
goldie.
You
can
contribute
and
policy
at
a
high
level.
Is
the
company
decision
whether
to
go
with
open
source
either
adopting
projects
or
allowing
your
community
con
contributions
into
your
own
products?
D
Then
there
are
the
technical
policies
you
can
implement
with
oprah
and
caverno
and
publish
those
policies
on
github
artifact
hub
or
send
them
to
no
more
wheels,
and
then
we
have
process
and
think
carefully
about
how
you
can
avoid
reinventing
the
wheel
and
what
practices
you
can
learn
from
or
contribute
to.
The
community
get
ops
is
a
great
example
of
a
delivery
process.
That's
grown
within
the
cloud
native
community
and
it's
and
it
has
the
technical
tooling
to
match,
and
we
saw
admiral
bash
and
goldie
adopt
flux.
D
C
Okay,
security
security
was
weaving
through
the
entire
book,
as
well
as
the
maturity
path
model,
and
if
you
notice
from
the
book
securities
mentioned
in
the
early
part
of
the
book,
just
like
in
real
life,
security
is
always
a
first
thought
right.
Well,
maybe
not,
but
it
should
be,
and
so
we
want
to
show
that
within
our
within
the
maturity
path
model,
as
well
as
the
book,
how
critical
that
is
so
last
year
I
worked
in
the
linux
foundation
when
I
created
the
kubernetes
certification
program
for
security.
C
So
all
the
lessons
learned
that
we
learned
from
that
is
we've
the
framework
as
well.
So
security
is
throughout
the
entire
lifecycle
of
a
mature
model,
as
well
as
the
book
you
just
read.
Let
me
just
write
for
you
so
within
kubernetes
making
you
know
security
first
citizen
is
critical
when
you
think
about
attack
vectors
and
kubernetes.
There
are
10
attack
vectors
in
any
cluster
right
from
the
container
down
to
the
network.
You
got
to
make
sure
each
one
of
those
10
layers
is
fully
secured.
C
Otherwise,
guess
what
this
gap
is
security
and
somebody
will
get
into
xcd
and
if
they
are
game's
over
for
the
cluster,
they
could
blow
it
up.
So
we
want
to
protect
that
entire
vector
as
much
as
possible.
We
do
that
by
using
hygiene
right
security
hygiene.
What
is
that?
Well,
it's
a
good
question
is
how
do
I
properly
hygiene,
my
security
model
within
my
containers,
to
properly
secure
them
by
shifting
left
as
much
as
possible
right
through
that
entire
life
cycle?
C
Also
images
images
can
be
very
bloated
and
very
fat
and
very
large,
an
image
only
a
couple
of
kilobytes,
but
I
see
them
in
megabytes.
I've
even
seen
in
gigabytes,
believe
it
or
not,
they're
so
bloated
with
drives
and
libraries.
You
don't
need
if
I'm
creating
an
application,
the
applications
containers
you
only
have
within
it
the
libraries,
the
jobs
that
I
need
to
run
the
specific
task
and
nothing
else.
C
I've
seen
containers
with
hp3
drivers
in
them
an
hp,
3
printer
driver
in
the
container.
Why
that's
a
tech
vector
for
hacker
to
get
into
and
expose?
So
when
you
develop
a
container,
you
want
to
have
minimum
images.
Anything
you
don't
need
take
it
out,
do
not
use
it.
Have
it
shrunk
as
much
as
possible?
If
you
do
that,
your
attack
vector
is
reduced,
and
that
brings
you
proper
computer
hygiene.
Also,
for
god's
sake,
please
do
not
your
developers
ever
download
anything
from
docker
hub.
That's
a
big
no-no
right!
C
You
want
to
have
your
own
repository,
that's
fully
secured
with
that
you
control
and
only
developers
can
go
to
that
repository
to
build
on,
because
you
know
they're
hardened
right.
They
they're
unbloated,
because
you
took
out
all
the
drivers
and
necessary
things
out
of
them.
So
you
use
your
foundation.
Anything
you
develop
is
gonna,
be
a
pure
container,
that's
fully
secured
and
all
the
hygiene
and
all
the
goodness
and
all
the
garbage
you
have
is
in
that-
and
I
I've
seen
this
too
many
times
where
people
get
attacked.
Why?
C
Because
they
let
the
developers
just
go
wild
wild
west
right,
develop
whatever
you
want,
go
crazy.
We
have
to
stop
doing
that.
We
have
to
really
be
smart.
Now.
Ransomware
is
on
the
rise.
Why?
This
is
why
now
we
can
build
an
anti-pattern
of
ransomware
very
easily
with
cncf
open
source,
it's
very
easy
to
build
an
anti-pattern
against
these
things.
But
to
do
you
got
to
be
smart,
every
guy
stops
doing
the
old
way
of
doing
things,
and
we
gotta
do
the
new
way
of
doing
things.
B
So
so
we
talk
about
service
mesh.
One
thing,
you'll
notice
in
the
book
is
that
we
wanted
to
really
focus
on
on
the
again
the
journey
like
you're
not
going
to
be
throwing
away
old
infrastructure
right.
So
we
we
built
our
lines.
We
built
our
network
right.
50
hung
the
lines
they
have
cans
on
each
end
of
them.
They
can
talk
to
each
other,
that's
great!
Well,
how
do
we
repurpose
that
make
it
more
secure?
B
We
have
little
saharan
silver
saharan
ants
carrying
these
shells
that
have
encrypted
encrypted
packages
that
they
can
run
along
really
fast,
using
their
little
sneaker
net
technology
to
get
it
to
the
to
where
they
wanted
to
go.
Then
we
introduced
things
like
blue-green
deployments,
using
the
very
same
infrastructure
that
we
set
up
earlier
in
the
book.
That's
that's
exactly
how
these
kind
of
journeys
work
right,
you're,
not
throwing
things
away.
You
always
want
to
be
adding
to
it
building
on
to
it,
so
you
have
to
start
with
that
secure
foundation.
B
Oh,
it's
me
again,
so
another
thing
we
we
see,
actually
we
call
it
out
very
specifically,
is
helm.
We
want
reusability
right.
We
want
the
ability
to
not
just
build
something
once
maybe
have
all
these
one-off
things
right,
we're
maybe
creating
you
know,
networks
all
over
the
place.
Why
don't
we
just
create
a
single
resource,
crd
or
something
that
we
can
apply
in
all
of
our
environments
right,
so
we
created
our
shop
no
more
wheels
so
that
we
wouldn't
reinvent
the
wheel.
A
So
in
terms
of
policy
management,
so
when
you
start
off
using
on
this
cloud
native
journey,
you're
not
going
to
have
a
lot
of
policies
in
place
for
specifically
for
cloud
native
now,
you'll
have
a
ton
of
policies
for
other.
You
know
legacy
systems
and
whatnot.
So
it's
like
how
do
you
get
policy
throughout
your
journey
to
maturity?
So
in
the
book
we
represented
this
with
by
showing
the
beavers
and
the
raven
trying
to
you
know,
this
is
what
we
want.
This
is
what
we
don't
want.
A
You
are
enforcing
it
automatically.
Your
developers
know
what
they
need
to
be
doing,
and
you
know
if
something
doesn't
comply.
It's
not
going
to
get
into
production
and
you're
going
to
be
able
to
tell
your
developer
hey
like
here's,
your
remediation.
This
is
what
you
need
to
do,
and
the
little
beavers
on
this
have
hats,
because
my
daughter
wanted
hats
on
the
beaver.
So
that's
a
little
fun
nugget
for
all
of
you.
B
So
another
thing
along
the
line
of
building
on
top
of
infrastructure
that
we
have
right.
We
we
have
these
admission
controllers,
which
can
which
allow
us
to
apply
these
policies
or
rules
or
whatever
we
want
at
the
at
run
time
and
throughout
the
process.
So
it's
actually
the
end
of
our
deployment
right.
It's
admitting
it
to
the
cluster,
but
it
also
is
continuously
checking
against
these
things.
So
the
in
this
case,
our
emission
controllers,
are
these.
C
Supply
chain
cd
diff
set
gobs,
my
favorite
topic
right.
So
if
you
read
the
book
and
if
you
read-
which
I'm
sure
you
already
read
it
by
now
five
times
right,
awesome
and
if
you
go
through
the
maturity
model
that
we
built
right
secured
again,
shifting
left
first
thought
the
process
here
that
we
built
a
consistent
workload.
This
is
a
container
that's
consistent
and
again
I
talked
before
about
how
the
consistent
you
know
repository
right
to
be
able
to
do
that.
C
C
Your
own
adventure,
which
is
kind
of
the
theme
underlying
thing
in
this
book,
is
choosing
your
own
adventure.
So
what
tool
do
I
use
to
build
this
adventure?
That's
up
to
you
guys
so,
once
you
do
it
the
right
way,
the
smart
way
you
think
about
it
quite
a
bit.
You
know
whether
you
want
to
be
pure,
open
source
or
mix
of
enterprise
open
source.
It's
your
journey
to
do
that,
but
you
must,
but
I
recommend
the
pattern
we
have
here
is
the
glue.
That's
the
magic
sauce.
C
The
secret
sauce,
if
you
will
of
the
trade
model,
is
how
we
do
the
pattern
right.
There's
many
tools
in
the
market
that
do
similar
things
similar
to
the
pattern.
So
it's
just
picking
and
choosing
the
best
ones.
You
have
to
pull
it
out.
At
the
same
time,
there
are
gaps.
There
are
many
security
gaps
in
every
tool
you
use.
So
when
you
do
these
things,
you
want
your
assessment
of
your
tooling
for
this.
C
When
you
assess
the
you
know,
the
framework,
as
well
as
the
the
patterns,
work,
my
gaps,
so
one
tool,
for
example,
may
do
everything,
but
one
time
security.
Well,
if
I
don't
have
time
security,
that's
very
bad,
so
maybe
now
I
need
to
run
time
security.
If
I
do
that
now,
all
my
apps
are
filled
in
like
I
talk
to
clients
again
very
often,
and
we
do
assessments,
we
see
gaps
everywhere,
because
nobody
does
this.
It's
just
don't
think
about
doing
this.
C
Just
because
you
buy
a
tool
and
they
tell
you
it
does
everything
you
need,
don't
believe
them
check
for
yourself
and
go
through
it.
You'll
find
out,
you
have
gaps
and
those
are
the
gaps.
Hackers
will
find.
I
promise
they
do
it
every
day.
So
it's
your
job,
you
know
to
find
those
gaps
and
fill
them
in
at
every
single
segment
of
the
pipeline.
Also,
when
you
build
the
pipeline,
I
recommend
six
quality
gates
through
the
entire
process
as
you're
building
it
out
each
quality
gate.
C
C
C
D
C
D
So
what
we're
working
on
when
now
we're
socializing
the
maturity
model
amongst
the
tags,
projects
and
end
user
groups
of
the
cncf,
but
the
charter
of
the
group
means
that
we
can
work
on
more
than
just
the
cloud
native
maturity
model.
It
allows
us
to
put
together
tools
to
help
the
community
navigate
the
ever-changing
cloud-native
landscape.