►
From YouTube: Learn how to Leverage Kubernetes to Support 12 Factor for Enterprise Apps - Brad Topol
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Learn how to Leverage Kubernetes to Support 12 Factor for Enterprise Apps - Brad Topol & Michael Elder, IBM
“12 Factor” is a software methodology for building scalable microservice applications that provides best practices designed to enable applications to be built with portability, resilience, and scalability when deployed to the web. In this talk we provide an overview of the 12 Factor methodology and describe how the core constructs provided by Kubernetes can be leveraged to support the 12 factors for scalable web apps. In this talk we will provide live demonstrations of how Kubernetes can support 12 Factor for not only newer cloud native applications, but also for legacy enterprise middleware applications that include stateful and transactional workloads.
https://sched.co/MPXZ
A
B
A
And
today
we're
going
to
learn
how
to
leverage
kubernetes
to
support
12
factor
for
enterprise
apps.
So
what
are
we
gonna
be
really
focused
on?
This
is
the
excitement?
Let's
go
deploy
our
apps
on
the
cloud
and
why
would
we
want
to
do
this?
So
cloud
has
evolved
as
a
strategy
for
disruption
and
continuous
delivery.
So
if
we
look,
we
all
know
the
great
examples
that
we
see
small
little
businesses
like
uber
and
Airbnb
start
small
they're
able
to
scale
up
quickly
on
the
cloud
and
they're
able
to
disrupt
complete
industries.
A
So
a
lot
of
power
in
this
cloud
stuff
and
with
the
cloud
and
enabling
micro
services
and
the
architectures
to
scale
out
quickly,
we
can
roll
out
new
updates
at
immense
speeds.
Now
I
love
to
think
of
good
examples
of.
Why
would
a
company
need
to
roll
out
changes
very
quickly
and
at
rapid
speeds
and
there's
one
that
just
happened
the
other
day
so
at
people
familiar
with
uber
and
how
it
works
that,
if
there's
not
a
lot
of
cars
available,
they
do
a
surge
and
the
prices
go
up.
A
So
I
don't
know
if
any
of
you
all
saw
this
I
know.
Jeff
Bork
saw
it
because
it
was
on
his
Twitter
feed,
but
at
Reagan
National
Airport,
the
uber
drivers
have
figured
out
that
several
times
a
day
they
all
at
the
same
time
turn
off
their
app
and
what
happens
the
the
surge
kicks
in
the
rates
go
way
up,
and
then
they
start
picking
everybody
up
and
they're
making
a
lot
more
money.
So
probably
uber
wants
to
get
a
fix
out
there,
because
that's
just
going
to
get
old,
real.
A
Obviously,
in
the
cloud
data
becomes
the
fuel
for
business
innovation
and
when
you
have
lots
of
services
out
there,
and
we
have
lots
of
AI
based
services,
wonderful
ways
to
combine
the
different
services
to
do
a
lot
of
really
cool
stuff
in
the
enterprise
and
for
businesses
and
really
what
are
we
talking
about?
Ideally
profit
or
reduce
cost.
So
a
lot
of
good
reasons
to
move
to
that
cloud.
A
So
what
is
twelve
factor?
Twelve
factors
of
software
methodology
for
building
scalable
micro
service
applications?
It
was
originally
created
by
Heroku.
It's
best
practices
that
are
designed
to
enable
applications
to
be
built
with
portability,
resilience
scalability
when
deployed
to
the
cloud,
and
so
I'm
gonna
go
into
these
in
much
more
detail
on
the
next
chart.
But
the
big,
the
big
key
things
to
take
away
here
is
the
12
factor,
makes
it
easier
to
run
scale
and
deploy
applications.
A
The
factors
that
deal
with
code
factor,
one
of
twelve
factors,
is
one
codebase
tracked
and
a
revision
control.
So
what
don't
you
want
to?
Do
you
don't
want
to
have
five
different
versions
of
your
code?
You
know
different
people
run
it
and
and
deploying
from
those
five
different
versions,
because
you
know
what
eventually
you're
gonna
have
a
bad
day
and
bad
things
are
going
to
happen.
A
So,
ideally,
you
want
a
single
codebase
and
from
that
single
codebase
is
where
you're
going
to
be
deploying
and
building
and
etc.
We
want
separate
stages
for
a
build
release
and
run
so
strictly
separate.
Those
stages
I've
seen
this
at
many
container
talks
where
they
make
it
very,
very
clear,
listen.
You
may
have
your
containers
out
there
running.
You
don't
want
to
go
login
and
patch
that
container,
where
it
is
right,
because
you
know
what's
gonna
happen.
A
A
couple
weeks
will
go
by
go
out
and
have
friends
maybe
go
on
vacation
you're
gonna
forget
that
you
did
those
patches
and
when
that
eventually
crashes
and
it's
trying
to
new
a
new
build,
those
changes
are
going
to
be
lost.
So
it's
very
important
that,
instead
of
going
on
and
doing
that,
that
you
have
a
very
efficient
build
release
run
cycle
where
you're,
making
sure
you're
putting
all
the
changes
back
into
the
build
and
and
deploying
from
there.
A
A
So,
let's
move
on
to
the
deploys
right,
so
under
the
ploys
dependencies
we
want
to
explicitly
declare
and
isolate
our
dependencies
and,
more
importantly,
whatever
dependencies
and
software
that
that
your
application
relies
on.
We
don't
want
to
assume
that
the
right
version
is
there
on
production.
We
want
to
make
sure
that
you're,
taking
whatever
exactly
you,
need
with
you
and
going
in
production,
so
there's
no,
no
surprises
of
versions
or
what
have
you
another
big
12
factor
is
configuration
and
storing
the
configured
in
environment.
A
So
we
don't
want
to
take
your
configuration
information
and
hard
code
it
into
the
code.
That's
a
Henry
Nash's
favorite
trick.
He
loves
to
do
that.
Thank
you,
so
you
don't
want
to
do
that
and
the
reason
you
don't
want
to
do.
That
is,
if
you
can
keep
that
information
in
the
environment
and
not
in
the
code
that
if
you
need
to
move
the
service
and
move
it
to
another
environment,
then
it's
much
easier
to
port
the
code
to
a
different
environment,
because
all
your
environment
information
is
is
not
you
know.
A
Hard-Coded
in
the
code
factor
for
here
is
backing
services.
You
want
to
treat
your
backing
services
as
attached
resources.
The
best
example
of
this
is
being
able
to
attach
and
detach
databases.
So
if
you
have
your
database
and
something
goes
wrong
with
the
database,
you
should
ideally
be
able
to
detach
that
database
and
attach
a
new
version
of
the
database
and
not
have
the
world
crashing
down
on
you
factor
six
processes.
A
Obviously
we
want
to
make
our
application
run
as
stateless
processes,
it's
a
big
factor
in
12
factor
if
they
can
run
as
stateless
processes,
it's
much
easier
to
scale
them
up
and
have
a
lot
of
them
running
port
binding
having
your
application
built
as
services
that
are
exposed
as
a
port
enables
a
lot
of
reuse
anytime.
To
get
a
lot
of
reuse
is
another
excellent
factor
of
the
12
factors,
and
we're
almost
done
here
we're
going
to
go
to
the
operates,
and
these
are
pretty
easy
to
describe
so
we'll
go
to
the
operates
concurrency.
A
A
Another
factor
factor
9
is
disposability.
Ideally,
if
your
application
crashes,
it
shouldn't,
be
the
end
of
the
world
right,
it
shouldn't
be
the
end
of
the
world.
Some
way
that
should
be
able
to
be
restarted
and
and
life
is
good,
so
we
want
to
have
an
approach
for
handling
disposability
from
a
12
factor
perspective
on
logs.
Ideally,
everything
should
just
write
to
standard
out,
and
there
would
be
some
other
tool
or
mechanism
that
gathers
everything
up.
A
If
you
all
know
me,
that's
something
I
would
clearly
do
I'm
gonna
leave
the
hard
part
to
Michael
Michael's,
going
to
show
you
how
all
these
wonderful,
twelve
factors
can
be
mapped
to
mechanisms
and
and
things
that
are
provided
by
kubernetes
and
he's
even
gonna
demo
it.
So
at
this
point,
I'm
gonna
enjoy
my
easy
roll
talking
about
the
twelve
factors
and
I'm
gonna.
Let
Michael
do
the
hard
part.
B
All
right
thanks,
Brad
I,
appreciate
it.
So
what
we
wanted
to
highlight,
we
think
about
these
three
groups.
Okay,
how
do
we
begin
to
make
these
real
with
kubernetes?
So
one
of
the
neat
things
is
that
when
you
look
at
kubernetes
and
you
look
at
how
it
defines
its
architecture,
it's
heavily
influenced
by
these
twelve
factors.
So
the
way
that
I
think
about
codebase
I
can
capture
all
of
my
content,
whether
it's
docker
images,
whether
it's
the
amel
configuration
for
kubernetes.
B
This
is
text-based
content
that
can
be
easily
source
controlled
and
managed
and
can
feed
into
a
build
system
which
can
package
it
up.
So
we'll
see
some
examples
here
in
a
few
minutes
of
how
helm
provides
a
default
package
manager
for
kubernetes
and
how
it
brings
together
different
parts
of
that
that
API
layer,
that's
really
the
API
captured,
is
text
so
code
base
and
being
able
to
drive
everything
through
declarative
mechanism
becomes
a
critical
factor
in
building
containerized
applications
and
kubernetes
being
able
to
tie
this
into
a
continuous
delivery
system.
B
So
how
I
build
and
package
the
image
the
helm
chart
and
then
promote
that
built
artifact
from
development?
All
the
way
through
to
production,
what's
really
powerful,
then,
is
because
it's
simple
and
consists
to
deploy
this
containerized
workload
with
its
standard
configuration.
This
enables
me
to
drive
better
parity
between
a
development
environment
and
a
production
environment,
so
it
may
become
the
day
that
when
I
say
it
works
well
in
my
laptop,
what
I'm
actually
saying
is
that
I
took
the
containerized
version
of
the
database,
ran
it
in
the
correct
highly
available.
B
Topology
I
took
the
correct
version
of
my
app
server,
ran
it
in
a
correct,
highly
available
topology,
and
it
worked
there
and
that's
representing
exactly
how
I'm
going
to
run
it
in
production,
and
so
we
talked
about
parity
by
reducing
the
number
of
differences
between
a
development
context
and
a
production
context.
It
really
helps
eliminate
sort
of
errors
of
absence.
Sort
of
the
I
forgot
that
it
was
this
variable
in
production
or
I
forgot
that
it
was
configured
with
TLS
security
and
production,
but
it
worked.
B
Fine
and
development
in
the
issue
is
with
a
certificate,
those
nuances,
those
deltas,
those
differences
get
pushed
to
zero,
and
so
you
get
a
more
consistent
way
of
promoting
that
content.
From
one
stage
the
next,
this
becomes
very
powerful
when
we
think
about
the
deploy
factors.
So
kubernetes
introduces
a
few
key
concerns.
Each
of
these
objects
that
you
see
out
to
the
side
in
a
box
is
the
kubernetes
object,
so
how
many
of
you
are
writing
kubernetes
applications
today
on
a
regular
basis?
How
many
of
you
are
still
in
that
learning
mode?
B
How
many
of
you
are
writing
and
learning
at
the
same
time?
Hopefully
everybody
right.
So
when
you
look
at
kubernetes,
this
is
what
we
mean.
We
say
that
it's
heavily
influenced
by
12
factor
when
I
think
about
12
factor
and
I.
Think
about
how
I
manage
configuration.
Kubernetes
gives
us
constructs
for
the
config
map
and
the
secret
that
allow
us
to
mount
those
fields,
those
keys
those
values,
those
files
of
certificates
into
the
container,
naturally
as
part
of
the
deployment
process.
So
it's
not
burned
into
the
image.
B
It's
something
that
actually
gets
mounted
either
into
the
process
environment
table
or
made
available
through
files
on
the
file
system
for
the
container.
When
we
think
about
backing
services,
I
can
link
to
a
network
service,
so
I
have
a
standard
model.
Now
saying
here
is
the
way
that
my
application
exposes
its
network
endpoints.
B
This
also
relates
to
work,
binding
and
I
have
a
way
of
declaring
I
need
to
consume
an
existing
service
through
this
mechanism
right
so
I
get
sort
of
a
built-in
poor-man's
load
balancer
for
every
application
that
I
want
to
deploy,
and
this
also
makes
sense
for
persistent
volumes.
If
I
want
to
attach
the
data,
that's
actually
driving
my
backing
database.
B
With
this
sort
of
little.
You
know
shell
around
it
the
container
itself,
and
so
we
think
about
pods
as
the
way
of
structuring
running
a
container
or
running
a
collection
of
containers
as
a
unit,
and
we
think
about
the
the
notion
of
the
container
itself
is
just
the
simple
process,
that's
being
run
on
a
host
and
where
kubernetes
really
brings
a
lot
of
power
as
when
we
think
about
how
to
orchestrate
these
containers.
B
We
see
deployment
controllers
and
stateful
sets
applying
a
very
specific
opinion
of
how
pods
need
to
be
operated,
so
how
I
scaled
them
out,
how
I
add
additional
and
this
concept
of
disposability?
What
do
I
do
when
a
pod
fails?
Well,
the
great
thing
is:
pods
are
largely
unimportant
right.
It's
the
collective
use
of
all
of
the
pods
together
that
create
an
application.
So
if
one
pod
fails
because
the
node
failed,
because
it's
storage
went
belly
up
or
whatever,
ultimately,
I
have
other
instances
of
that
application.
B
Pod
running
each
of
those
again
are
backed
by
a
or
actually
providing
the
backing
to
a
service
which
is
then
consumed
by
my
my
applications
or
other
consumers
that
are
using
that
as
an
API
or
as
a
data
store.
So
ultimately,
each
of
the
12
factors
Maps
very
cleanly
to
these
different
aspects
of
kubernetes.
One
of
the
neat
ones
that
that
I
find
talking
to
folks
that's
kind
of
left
out
is
what
do
you
do
for
admin
processes
and
kubernetes?
Jobs
are
a
great
way
to
do.
B
High-Performance
computing
I
can
do
batch
processing,
maybe
I
process
payroll,
and
it
makes
sense
to
do
that
in
a
batch
as
a
job.
But
jobs
also
provide
us
a
way
that
we
can
deliver
admin
tasks
into
a
cluster
in
a
way
that
it's
very
predictable
I
can
capture
it
as
source
code.
I
can
manage
it
as
part
of
the
build
I
can
promote
a
migration
job
from
one
stage
to
the
next,
so
jobs
themselves
become
a
powerful
way
to
also
administrate
behavior
on
the
cluster
and
I.
B
Think
what
we're
seeing
now
is
the
evolution
of
things
like
operators,
making
that
more
of
a
first-class
controller
concept,
and
so
we
may
see
operators
take
over
that
role.
But
at
least
there's
a
way
to
do
it
today,
as
well.
So
I'll
show
in
a
simple
application
that
meets
12
factor
principles
and
we'll
see
this
in
just
a
moment.
But
let's
talk
about
sort
of
the
structure
and
then
what
I
want
to
show.
B
You
is
also
how
we
can
use
kubernetes
even
for
apps
that
weren't
built
with
strict
12
factor
principles
in
mind
how
the
support
in
kubernetes
that
maps
to
12
factor
can
carry
over
and
make
it
easier
to
manage
more
standalone
or
traditional
applications
or
workloads,
and
we'll
see
some
some
examples
with
helm
of
that
using
helm
to
do
that
in
just
a
moment,
but
just
a
simple
example.
So
this
is
just
a
node
application.
It
happens
to
talk
to
one
of
our
services
in
IBM
cloud,
but
this
is
true
for
any
application.
B
Any
12
factor
app:
you
want
to
build
generally
you're
gonna
have
the
app
itself
and
that,
typically
for
a
stateless
service,
you're
gonna
use
a
crew
Bonet
to
use
deployment
in
order
to
describe
that
pod
and
describe
how
to
scale
it
out
how
many
desired
replicas
do
I
want.
A
key
factor
here
is
that
these
instances
are
typically
stateless
because
remember,
one
of
the
principles
of
12
factor
is
I
use,
backing
services
and
port
bindings
to
isolate
other
dependencies.
B
So
if
I
need
a
cache,
then
all
of
the
pods
are
going
to
connect
to
a
shared
cache
that
cache
might
itself
be
running
as
a
collection
of
pods
right.
So
each
layer
of
the
dependency
tree
is
using
all
of
the
same
principles.
I
can
expose
this
application
through
a
service,
so
the
crew
Bonetti
service
basically
acts
like
a
local
load
balancer
it
can
reference
or
be
exposed
outside
of
the
cluster.
B
As
a
load
balancer
service,
it
can
be
used
locally,
where
it
simply
provides
a
local
facade
to
many
pods
that
are
behind
it,
and
you
can
even
use
a
trick
with
kubernetes
services
today,
where
you
declare
it
as
an
external
name,
and
now
it
becomes
kind
of
a
way
to
have
a
unique,
alias
that
says.
Well,
this
actual
dependency
is
an
external
service.
That's
off
cluster,
but
I
still
want
to
explicitly
declare
it.
So
when
I
do,
source
control
and
I.
B
So
if
you
look
up
my
repo
and
github,
you
can
find
this
out,
but
just
to
kind
of
show
a
simple
12
factor
micro
service
again
as
a
deployment
I'm
describing
things
like
the
number
of
replicas,
because
each
of
these
replicas
each
of
these
pods
is
stateless.
So
if
one
fails
ie
is
disposable,
then
the
deployment
controller
will
simply
create
new
replicas
to
take
over
that
role.
In
this
case,
the
pod
does
not
actually
interact
with
any
storage.
B
Thank
you
for
this
pause
for
the
public
safety
announcement
all
right
and
in
Elson
it
actually
binds
in
a
secret
into
this
model
as
well.
The
config
map
in
secret
aren't
shown
in
this
file
because
you
would
create
them
for
your
specific
application,
but,
like
we
saw
in
the
slide,
the
config
map
ultimately
loads.
B
This
workspace
ID
as
a
variable
in
the
process
table
of
this
container,
and
this
is
that
that
principle
of
separating
the
configuration
from
the
application
from
the
source
code,
so
so
that's
fairly
simple
to
take
a
stateless,
app
deployed
in
kubernetes
map
it
to
those
12
factor
principles.
If
we
kind
of
take
a
closer
look
here,
we're
looking
at
each
of
these
different
process,
each
of
these
different
characteristics
so
and
I'm
not
going
to
turn
around
because
that's
actually
a
little
bit
dizzying
just
to
see
it
at
that
angle,
that's
weird
anyway.
B
So
container
images
themselves
we're
capturing
that
as
docker
file,
stalker
files
are
easy
to
source
control.
The
configuration
the
example
we
looked
at
here
as
a
deployment,
that's
also
easy
to
source
control
and
because
they're
easy
to
source
control,
they're
easy
to
incorporate
into
a
continuous
delivery
pipeline,
and
this,
ultimately,
is
what
drives
the
culture
change
that
you
need
in
order
to
be
competitive,
it's
not
the
containers
or
kubernetes
are
magic
and
help
enable
new
entrepreneurial
business
models
or
help
enable
disruptive
business
models.
B
It's
that
they
provide
some
of
the
characteristics
and
the
tools
that
your
culture
needs
to
use.
In
order
to
be
more
adaptive
to
your
environment,
we
look
at
the
deploy
factors
again,
config
Maps
secrets
our
way
to
expose
that
information
into
the
pod
and
ultimately,
the
pods
themselves.
Are
these
disposable
instances
which
are
managed
as
processes
in
the
application.
So
this
is
kind
of
just
a
visual
picture
of
what
we've
been
talking
about.
The
pod
itself
contains
multiple
containers.
B
Those
containers
may
or
may
not
buy
into
additional
storage
volumes,
and
then
those
pods
might
then
expose
one
or
more
services
and
then
for
operate.
We
look
at
the
notion
of
different
controllers,
so
deployment
is
one
controller
that
supports
a
stateless
workload.
We
also
see
controllers
or
on
things
like
stateful
workloads.
These
ultimately
are
typically
used
for
databases
where
the
way
that
I
replace
a
pod
is
important.
So
if
I
think
about
something
like
at
CD,
it
has
maybe
three
replicas.
B
They
establish
a
notion
of
quorum
if
one
replicas
is
lost,
I
actually
want
the
new
pod
to
have
the
same
name
and
to
begin
to
look
like
the
replica
that
was
lost,
so
they're
slightly
less
disposable
I
can
recover
if
they
fail.
But
if
I'm
dealing
with
a
stateless
application,
I
can
add
ten
instances
all
at
the
same
time,
if
I'm
dealing
with
a
stateful
workload,
I
may
want
to
have
replicas
one
come
online.
B
Okay,
so
how
many
of
you
have
100%
of
your
applications
today
that
you
run
that
are
not
running
in
containers
that
are
already
running
in
12
factors
already
running
as
microservices?
How
many
of
you
have
pure
micro
service
architectures
from
beginning
to
end
today,
all
right,
so
we
got
one
guy
in
a
start-up,
probably
maybe
a
successful
one,
but
largely
this
is
not
the
case.
Most
enterprises
that
we
talk
to
have
a
large
amount
of
IT.
That's
not
fully
containerized
hasn't
been
built
with
these
principles,
because
state
of
the
art
ten
years
ago
was
different.
B
State
of
the
art
ten
years
ago
was
I,
build
Java,
runtimes,
Java
applications,
I
cluster,
those
applications,
I
roll
out
updates
to
the
schema
updates
to
the
application
updates
to
my
my
load,
balancer
layer,
all
together
and
I
do
very
specific
blue-green
zones
that
are
mirrors
and
if
one
zone
is
lost,
I
can
fall
back
to
the
other.
One
I
can
take
one
zone
offline
during
a
low
period,
upgrade
it
bring
it
back
online.
B
The
challenge
with
that
style
of
architecture
is
that
it
just
requires
more
human
coordination
right,
because
I'm
actually
coordinating
all
of
the
humans
making
changes
to
these
different
layers
when
I
go
to
containers
and
kubernetes.
More
of
that
intelligence
is
baked
into
the
platform
itself.
Okay.
So
how
does
this
help
me
if
I'm
running
an
application,
that's
different?
Well,
it
turns
out
that
characteristics
that
may
have
been
put
into
kubernetes
to
support.
Twelve
factor
also
make
it
easier
to
manage
these
traditional
workloads.
B
So,
for
example,
helm
charts
are
a
way
that
not
only
allow
us
to
represent
micro-services
and
twelve
factor.
Ops,
but
I
can
take
an
existing
stand-alone
application,
build
it
into
a
container
and
then
describe
how
to
provide
its
configuration
through
config,
Maps
and
secrets
can
describe
how
to
bind
its
available
services
through
a
kubernetes
service.
B
Definition
can
describe
how
to
differentiate
the
process
from
the
storage
using
a
Kerber,
Nettie's,
persistent
volume
claim
and
and
persistent
volume,
and
now,
even
though
this
large
container
is
bigger
than
a
traditional
micro
service
and
even
though
it
may
not
meet
all
the
principles
of
stateless
services
and
it
may
not
be
as
disposable.
It
still
enables
me
to
do
better.
Continuous
delivery.
I
can
begin
applying
things
like
canary
testing.
B
I
can
begin
replicating
development
environments
that
match
more
closely
to
the
same
versions
of
messaging
services,
database,
services,
caches,
etc
that
are
used
in
production,
and
so,
in
this
case,
I'll
pick
on
an
example
which
is
IBM
MQ
series
MQ
has
been
around.
There
may
be
some
of
you
in
the
room
that
are
younger
than
MQ.
It's
been
around
for
a
while
and
it's
a
core
part
of
messaging
layers
for
lots
of
financial
services
and
insurance
in
many
industries.
B
B
Zero
attachment
to
real
information
in
the
real
world
are
I'd
love
to
see.
If
you
have
interesting
examples,
but
I
find
they're
always
attached
to
these
other
things
that
don't
fit
neatly
in
the
12
factor
box.
Well,
look
at
the
operator
factors
here
and
I,
say
operator
I
mean
operate
in
this
example.
B
We'll
talk
about
a
stateful
set,
so
it'll
actually
have
MQ
running
as
a
stateful
set
running
as
pods
that
can
mount
persistent
volumes
and
ultimately,
these
pods
are
now
generating
logs
and
metrics
and
other
visibility
other
notions
of
observability
that
you
need
to
satisfy
when
you
build
out
a
kubernetes
platform,
you're
beginning
to
adopt
this
as
your
principal
way
of
delivering
your
applications.
Those
aspects
of
how
I
begin
to
manage
those
workloads
manage
those
pods.
That's
a
problem.
B
B
Now,
even
though
these
workloads
that
don't
fit
traditional
twelve
factor
are,
even
though
they
don't
fit
into
that
mold,
because
we're
using
principles
like
containerization
like
source
source
control,
to
manage
those
services,
those
declarations
of
configuration,
they
become
easier
now
to
integrate
into
your
continuous
delivery
pipeline
and
allow
you
to
begin
leveraging
a
platform
like
kubernetes
to
improve
your
entire
ecosystem,
not
just
that
percentage
of
micro
services
that
make
up
sort
of
the
tip
of
the
iceberg.
That's
maybe
the
big
punchline
I
want
you
to
walk
away
with
today.
B
So
in
this
example,
what
I'll
do
is
I'll
start
with
just
a
set
of
helmet
charts,
and
you
can
browse
these
on
github
if
you'd,
like
they're
at
github
com
and
what
I'm
using
are
the
ones
that
iBM
has
been
building
in
the
community.
So
these
represent
open
source,
middleware,
IBM
middleware
and
what
I
want
you
to
take
away
is
not
necessarily
that
you
should
go
and
adopt.
This
is
your
only
path,
but
they
do
represent
a
lot
of
good
learning
and
examples
that
we've
absorbed
and
begun
sharing
in
the
community.
B
And
so,
if
you
look
here,
what
you'll
find
is
that
there's
actually
many
helm,
charts
available
and
so
we're
gonna
pick
on
the
one
for
mq,
and
so,
if
you're,
trying
to
understand
how
these
principles
really
get
apply
to
this
style,
I
can
drill
into
the
helmet
chart
and
what
I'm
looking
at
now
are
a
collection
of
template
files.
Each
template
file
then
maps
to
one
of
these
concepts
that
we've
been
talking
about.
B
B
Alright,
so
I've
got
helm
installed
and
I
can
list
all
of
these
home
releases
and
it
doesn't
display
as
neatly
as
I'd
like
it
to
on
the
screen.
But
what
you
can
see
is
that
I've
got
certain
charts
that
are
deployed.
This
is
the
mq
chart.
I
can
see
the
version
that's
running
and
I
can
actually
now
deploy
this
workload
very
easily
using
Helms.
So
what
it's
going
to
do
is
it's
going
to
take
a
version
of
this
template
that
you
can
review
on
github
and
stand
up
a
live
running
instance.
B
Then
we're
going
to
take
a
look
at
that,
so
in
order
to
bring
all
of
these
parts
together,
helm
has
been
part
of
that
CI
CD
process
to
package
all
the
files.
It's
referencing
a
built
image
for
Maya
container
and
then
it's
going
to
deploy
all
of
those
different
parts
and
create
the
full
application,
and
so
this
command
is
saying
helm
install,
giving
it
a
name
and
I'm
actually
going
to
modify
the
name
here.
B
You
need
pods
as
an
example
kubernetes.
So
it's
running
that
pod,
that's
now
coming
online
I
need
configuration
for
how
I
want
to
specify
credentials
for
the
application,
so
I
have
a
secret.
That's
mounted
into
the
pod.
I
need
to
expose
not
only
a
network
service
for
the
admin
console
or
for
applications,
but
also
a
service
for
my
Prometheus
metrics.
So
I've
got
two
services
that
are
defined
in
this
example.
I
could
disable
one
or
more
services
if
I
chose
right
through
the
options
and
ultimately
it's
running
that
stateful
set
right.
B
B
A
B
Real
hard
copies
make
at
home
if
you
want
to
do
that
or
grab
a
digital
copy
and
I
think
we're
right
at
time.
So
maybe
we'll
take
questions
up
here
after,
if
there's
any
comments
or
questions
can
I,
do
one
quick
thing:
do
you
guys
mind
if
I
take
a
quick
selfie
of
the
room?
Is
that
okay
can
I?
Is
that
if
you
all
right,
can
you
get
in
all
right?
One,
two
kubernetes
all
right!
Thanks
have
a
good
one.