►
From YouTube: 7 Missing Factors for Your Production-Quality 12-Factor Apps - Michael Elder & Shikha Srivastava
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
7 Missing Factors for Your Production-Quality 12-Factor Apps - Michael Elder & Shikha Srivastava
We've all heard of and practiced the 12-factor principles for effective microservices. With Kubernetes, many of these factors are directly supported. In this talk, we ask the question: are the 12 factors sufficient for building production-quality, scalable, and secure microservices? Based on our experience creating enterprise-grade production-ready apps based on Kubernetes, we identified 7 missing factors that are often overlooked. These additional factors ensure that you can upgrade, secure, and scale your apps all the way to production. We'll describe these 7 factors and provide specific guidance on how to adopt them in the delivery of your next Kubernetes microservice.
https://sched.co/NrlN
A
B
A
So
when
you
think
about
what's
required
for
a
production
application,
there's
a
number
of
key
factors
beyond
just
as
my
code
function
correctly,
you
need
to
think
about
how
secure
is
the
application,
so
managing
TLS
certificates
becomes
a
really
important
aspect.
You
have
to
think
about
how
resilient
is
the
application?
Does
it
respond
correctly
to
failure?
But,
as
you
manage
the
application,
how
does
it
tie
into
the
observability
aspects?
How
do
I
actually
measure
its
help?
How
do
I
ensure
that
it's
running
correctly
on
an
ongoing
basis?
A
Okay,
twelve
factor
is
a
methodology,
and
it
just
says
there
are
twelve
specific
practices
that
you
should
follow
when
you're
building
scalable
micro
services
and
we'll
talk
about
those
in
just
a
moment,
but
it
just
gives
you
a
way
of
defining
sort
of
step
by
step.
Here
are
some
best
practices
that
you
want
to
use
as
you
create
applications,
and
it
turns
out
that
kubernetes
really
has
taken
a
lot
of
these
factors
into
account
in
designing
the
kubernetes
api
and
things
like
deployments
and
stateful
sets.
We
talked
about
this
at
coop,
convar
Salona.
A
You
can
watch
that
recorded
session
where
we
explain
the
relationship
of
12
factor,
applications
to
kubernetes
and
the
link
is
a
article
that
walks
through
how
that
lays
out.
But
today
we're
gonna
go
a
little
bit
further.
So
when
you
look
at
the
12
factors,
there's
well
a
dozen
of
them
right
and
they
focus
on
many
different
aspects
of
the
application,
and
sometimes,
if
you're
not
familiar
with
them,
they
might
seem
a
bit
overwhelming.
Why
do
I
need
to
do
all
of
these
different
things?
A
So,
let's
talk
about
these
just
briefly
and
then
we're
gonna
go
beyond
these
basic
factors
and
we're
going
to
look
at
what's
missing
what
are
some
of
the
best
practices
and
for
context
Shikha
and
I.
We
work
for
IBM
and
we
build
products
that
use
kubernetes
as
part
of
the
foundation
and,
as
we've
been
doing
this
over
the
last
three
or
four
years,
we've
identified
several
common
practices
that
we
think
are
required
to
run
applications
in
production.
So
that's
what
we're
going
to
go
through
in
this
conversation,
but
let's
look
at
the
basics.
A
First,
with
a
12
factor
app.
What
you're,
really
thinking
about
are
sort
of
three
parts
of
the
lifecycle.
How
do
I
write
the
application
and
manage
its
code?
How
do
I
deploy
the
application
and
then
how
do
I
operate
it?
So,
if
you're
not
familiar
with
12
factor
as
a
general
set
of
principles,
this
is
just
a
way
to
think
about
it,
we'll
talk
through
this
here
and
and
and
break
it
down.
A
But
ultimately,
this
may
give
you
a
simple
way
to
get
that
introduction
to
what
you
would
need
to
do
with
12
factor
apps
so
code
base
when
we
think
about
the
code
base.
We're
really
thinking
about.
How
do
I
define
the
application
and
how
do
I
manage
it?
The
great
thing
about
the
kubernetes
design
model
is
that
it
allows
you
to
represent
everything
as
text.
All
parts
of
the
application
are
code.
Therefore,
I
can
manage
them
with
revision
control
with
source
control.
I
can
make
it
part
of
an
automated
build
process
for
developers.
A
Now
this
is
true
from
the
container
image
and
how
I
represent
that,
using
a
docker
file
all
the
way
through
to
the
kubernetes
api
and
representing
things
like
a
deployment
or
networking
services
or
how
it
talks
to
persistent
storage,
so
code
base
and
really
what
you'll
notice
is,
will
represent
the
factors
with
this
sort
of
F
number
and
a
letter
I
to
eyes,
etc.
Roman
numerals
here,
where
represent
that,
so
that
we
can
tie
it
back
to
12
factors
through
the
conversation.
A
A
What's
neat
about
this
is
that,
within
the
various
factors,
one
of
the
key
principles
is
separate.
The
configuration
from
the
code
base
and
kubernetes
introduces
specific
types
called
config
map
and
secret,
which
help
you
manage
that
configuration
in
a
way
that's
still
declarative
and
can
still
be
source
controlled.
So
on
the
picture,
this
is
sort
of
representing,
what's
called
a
kubernetes
pod
kubernetes
runs
containers,
one
or
more
containers
in
the
pod
and
then
mounts
those
volumes
that
storage
into
the
pod
itself.
A
A
So
if
I
use
a
port
binding,
it
gives
me
a
very
simple
way
of
exposing
any
service
in
the
system
on
a
port
and
as
I
wrap
that
service
in
a
container
it
means
I
can
actually
have
multiple
versions
of
that
service
running
side-by-side,
believing
that
they're
using
the
same
port.
What
we're
doing
is
we're
using
network
namespaces
in
the
container
to
isolate
its
networking
layer,
and
that
becomes
a
very
powerful
principle.
If
you
were
to
test
multiple
versions
side-by-side
in
the
same
environment.
A
The
key
thing
here
is
what
you're
seeing
in
this
picture
is
it's
changing
from
one
state
to
another
and
it's
demonstrating
a
deployment
which
is
a
crew,
brunet,
ease,
controller
and
API
object,
using
a
replica
set
to
add
or
remove
pods
and
what's
powerful?
Is
that
I
can
simply
change
the
text
of
my
deployment
apply
that
text,
maybe
as
a
developer
from
my
command
line
or
as
a
developer,
using
a
continuous
delivery
pipeline
as
part
of
an
automated
ongoing
process.
A
Concurrency
also
becomes
a
really
powerful
way
to
really
take
on
and
establish
more
capacity
more
subscribers,
more
users,
more
transactions
and
I
can
use
the
built
in
Auto,
scalars,
also
part
of
the
foundation
and
kubernetes
to
add
or
remove
pods
dynamically
and
again,
I
can
describe
in
a
declarative
way
the
policies
and
the
descriptions
that
I
want
and
the
horizontal
autoscaler
will
add
additional
pods.
The
vertical
autoscaler
simply
makes
those
pods
bigger.
It
adds
more
memory
more
CPU.
It
allows
them
to
use
more
of
the
compute
infrastructure.
A
B
Thanks
Michael,
so,
as
Michael
mentioned,
we
work
at
IBM
and
we
are
creating
these
services
on
kubernetes
who
run
incumbent
kubernetes
and
as
we
were
looking
at
all
our
services,
we
wanted
to
standardize
some
principles
of
some
design
principles.
Each
of
the
services
follow,
so
twelve
factors
were
very
handy.
Map
to
kubernetes
were
following,
but
then
we
figured
that
these
are
others.
Seven
factors
am
I,
echoing
am
I
echoing.
B
These
are
additional
factors
which
unconsciously
we
are
applying
to
every
service,
because
we
need
to
get
these
services
running
in
production
environment,
and
these
are
very
critical
for
running
any
of
the
services
in
a
production
environment
in
an
enterprise
organization.
So
that's
where
these
originated,
and
this
were,
as
a
matter
of
fact,
we
were
writing
down
all
the
principles.
All
the
guidelines
for
the
services
and
these
stood
out
did
not
map
to
the
existing
12
factors.
B
So
Michael
and
I
got
together
and
categorized
this
as
seven
missing
factors
that
we
need
to
take
care
of
in
any
services
that
we
create
in
IBM
and,
of
course,
it's
good
to
share
with
rest
of
all.
You
two
I
want
to
go
through
here
in
detail
because
there's
light
for
each
one
of
them,
observability
in
a
distributed
environment,
it's
really
hard
to
manage
and
make
sure
every
piece
is
running
properly
because
it's
distributed.
B
There
are
multiple
moving
parts
moving
at
the
same
time,
anything
can
go
around
impacting
the
other
service
think
about
100
micro
services
and
one
goes
wrong
and
the
it's
empathic
impacting
99
or
ten
other
micro
service.
So
you
really
need
something
inbuilt
to
make
sure
their
services
or
your
apps
are
resilient.
B
Kubernetes
has
some
features
and
accepted
us
to
take
advantage
of
it.
Readiness
probe
is
a
great
one
to
make
sure
that
you
have
it
in
each
of
your
micro
service
or
each
of
your
pods,
and
that
really
helps
make
your
system
resilient.
As
you
can
see
in
that
animated
chip,
each
of
the
pod
or
each
of
the
micro
service,
you
can
check
for
the
readiness
of
readiness
of
all
your
dependent
or
your
dependencies
and
of
all
your
dependencies
are
ready.
Then
your
part
is
ready.
The
way
kubernetes
uses
it
is.
B
It
only
sends
the
traffic
to
your
pod
if
it
finds
out
that
your
pod
is
responding
success
to
the
readiness
probe
so
think
about,
like
the
front
end
dependent
on
a
database
and
a
Bismarck
micro
service.
You
want
to
check,
in
your
front-end
micro
service
that
your
biz
logic
is
responding
and
your
database
is
responding
and
ready
as
well.
So
that's
kind
of
checking
one
other
thing
that
we're
using
this
readiness
probe
heavily
now
for
is,
as
your
dependencies
change,
their
versions,
API
versions.
B
We
want
to
make
sure
that
my
micro
service,
that
is
dependent
on
other
services,
does
have
API
to
raishin
and
that's
what
I
check
on
the
in
the
readiness
probe
as
well
to
make
sure
I
have
the
right
api's
of
the
dependencies
in
the
system
before
I
can
respond
to
the
traffic
liveliness
probe.
It's
there
to
kubernetes
checks
for
the
liveliness
probe,
and
if
it's
not
live
it
actually,
dis
replaces
the
pod.
B
So
it's
very
important
to
make
sure
that
initial
delay
ii
is
set
right,
because
if
your
initial
delay
ii
is
less
than
your
application
boot
time
guess
it
gets
into
the
the
cyclic
nature
and
your
application
will
have
a
hard
time
coming
up
so
something
there
to
keep
in
mind.
Well,
is
this
enough?
My
application,
for
example,
the
front-end
application
that
I
described
it's
dependent
on
its
accepting
traffic?
It's
doing
some
transactions,
so
I
might
be
interested
interested
in
transaction
per.
B
Second,
that's
not
something
that
urban
areas
gives
out
of
the
box
as
part
of
the
health
check.
So
I
can
introduce
my
own
metrics
I
can
have
my
node.
My
custom
metric
introduced
I
can
have
an
exporter
for
it
collected
in
Prometheus
have
a
refiner
dashboard.
So
that's
what
you
can
use
if
you
have
Prometheus
and
Griffin
now
as
a
monitoring
system
in
in
your
kubernetes
environment
in
the
cloud
provider
that
we
have
at
IBM,
we
do
have
the
Griffin
and
Prometheus
as
our
monitoring,
out-of-the-box
monitoring
solution
and
to
help
with
this
last
use
case.
B
B
You,
your
organization,
creates
kubernetes,
wants
to
venture
into
kubernetes
and
sets
up
the
kubernetes
environment,
and
you
are
the
first
team
to
pioneer
an
application
that
runs
in
kubernetes.
It
comes
up
well
coded.
Well,
it's
running
up
and
running.
Everything
is
awesome,
performance
is
great,
and
another
team
comes
in
and
starts
to
experiment.
They
also
come
up
with
their
their
application
application,
be
it's
working
well,
but
slowly,
your
performance,
your
application
performance,
starts
going
down.
B
The
first
thing
to
check
is:
do
your
pods
or
your
containers
have
the
resources
that
it
needs
the
compute
resources
it
needs?
That's
the
first
place
to
check,
because
what
kubernetes
does
is,
if
your
containers
do
not
have
the
request
and
the
limits
to
find
requests
for
the
CPU
and
the
memory
and
limits
for
the
city
of
memory
defined
for
the
compute
resources,
it
just
forwards
it
to
somebody
else,
and
your
your
application
will
get
start.
So
that's
where
it
comes
to
define
the
resource,
compute
resources
for
your
pots.
B
Another
neat
thing
is:
if
your
non-
traitor
and
you're
setting
up
your
kubernetes
environment
and
you're
having
different
namespaces
for
different
dev
staging
and
production,
you
may
you
might
want
to
allocate
the
resource
for
it.
It's
just
not
only
the
CPU
limit
and
the
memory
limit
you
can
define
as
a
resource
quotas.
You
can
also
define
number
of
thoughts
persist
in
volume
claims
so
and
so
forth.
So
that
really
helps
make
sure
your
environment
is
set
up
right
and
really
useful
useful
in
production
environment.
B
All
right,
let's
go
to
upgradability
when
applications
are
running
in
production.
There
is
always
security
enhancements
feature
enhancements
that
we
have
to
put
in
that
are
that
are
required
to
be
backwards
compatible.
It's
not
just
that
it's
a
new
version
of
the
application,
but
it
fixes
that
you
apply
to
the
application.
B
That's
where
the
rolling
of
grades
is
very
handy.
What
that
does
is
kubernetes
provides
a
really
great
way
of,
as
shown
in
the
animation.
Here,
you
can
introduce
version
2
of
your
deployment.
Your
pod
comes
up
and
slowly
the
kubernetes
will
take
the
service
when
the
whole
application
is
up.
Your
service
will
point
to
the
new
version
2
of
your
application.
B
We
find
this
very
handy
for
for
applications
that
need
fixes
on
regular
basis
for
security,
for
feature
enhancement,
for
any
other
fixes
that
you
can
think
of.
That
goes
in
the
production
couple
of
things
to
keep
in
mind.
It's
I
did
not
find
it
in
the
kubernetes
dock,
but
it's
important
that
the
Mac
search
is
defined.
Mac
search
is
one
additional
pod
that
you
that
you
want
to
be
available.
Besides,
the
number
of
replicas
said
that
you
have
set
up
it's
an
important
one,
to
define
there.
Otherwise,
you,
your
kubernetes,
might
take
away.
B
B
All
right
least
privilege
Michel
touched
on
the,
how
you
create
your
containers
in
a
trusted
image
from
the
source
cetera.
This
is
additional.
These
are
some
additional
things
to
keep
in
mind
when
you
are,
when
you
have
the
containers
up
in
running,
you
want
your
containers
to
have
as
minimal
privileges
as
possible,
because
any
additional
privilege
is
a
source
of
attack.
B
There
is
a
port
port
security
policy
in
kubernetes
that
you
can
use
for
limiting
or
restricting
any
actions
that
see
that
you
can
allow
your
containers
to
have
in
your
environment,
access
to
the
hosts,
access
to
the
file
access
to
the
type
of
volume,
etc.
So
that's
another
thing
we
find
it
useful.
We
also
have,
when
you
create
namespace
in
the
cloud
provider
that
we
have
when
you
create
namespace.
You
can
also
tell
kubernetes
what
kind
of
ports
are
secure.
B
Auditable
when
you
are
working
in
production
environment,
an
enterprise
where
maybe
you
are
allowing
credit
transactions
to
happen,
you
definitely
want
each
and
every
critical
create
update,
delete
operations
to
be
locked
because
you
never
know
when
you
have
to
go
back
and
do
the
post-mortem
with
all
the
audits
that
you
have
taken
account
of
or
you
may
have
to
figure
out.
You
know
who's,
you
know
who's
violating
or
who's,
not
doing
the
right
actions.
So
that's
important
from
the
from
the
production
or
enterprise
application
or
setup
point
of
view.
B
We
we
follow
the
care
of
open
source
format
which
helps
log
each
and
every
detail
which
is
initiator
ID,
who
is
starting
the
operation
target
fury,
which
is
what
specific
target
is
getting
operated
on
and
the
action
the
action
along
with
the
resource
type.
That's
getting
looked
at.
So
that's
the
another.
One
is
an
important
one
to
have
as
a
factor
of
when
you're,
creating
your
application.
B
Access
controls,
so
this
whole
topic
can
be
session
by
itself
or
can
be
a
session
for
the
whole
day.
There
is
several
aspect
for
your
application
when
it's
running
really
at
the
enterprise
scale
to
make
sure
that
it
is
secure.
It's
has
the
right
attend,
occasionally
zation.
When
a
user
accesses
your
application
network
policies,
security
policies,
it
has
the
right
level
of
network
policies
and
security
policies
applied
it's
running
in
an
environment
where
it
has
the
right
to
level
of
policies.
For
example,
the
policies
could
be.
B
B
Certificate
management-
this
is
part
of
the
previous
factor.
Any
communication
between
the
part
to
pod
should
be
should
be
through
TLS.
If
you
are
letting
your
front-end
to
be
accessed
from
the
browser,
then,
if
there
should
be
a
certificate
established,
that's
going
to
this
one
in
the
cloud
provider
that
we
have.
We
use
OpenStack
as
our
cert
manager.
It's
an
open
source
project.
We
use
that
to
make
sure
that
we
can
have
this
certificate
manager.
We
can
have
the
certificate
in
rotation.
B
Ultimately,
whatever
you
set
up
in
your
kubernetes
environment,
somebody
has
to
pay
for
it,
so
make
sure
that
your
application
has
a
way
based
on.
However,
your
cloud
provider
provides
the
mechanism
so
that
it's
measurable
they,
you
know
how
much
resources
you
are
consuming
from
the
kubernetes
environment.
B
That's
the
last
factor,
I
believe
we
have
the
next
slide.
So
what
really
makes
a
production
ready,
app
ready,
there's
three
things
that
we
touched
on.
If
you,
our
twelve
plus
seven,
factors,
goes
through
or
is
covered
in
each
in
it,
it's
one
of
the
other
categories
here.
How
are
you
building
the
containers
trusted
small
image,
how
you
are
configuring,
the
kubernetes
configuring,
the
oak
kubernetes
to
post
your
containers?
That's
the
second
one
and
then
finally,
the
cloud
provider
you're
using
the
cloud
provider
is
providing
all
the
capabilities.
B
B
Alright
reusing
Michael's
temper
laptop
here
for
the
demo,
so
what
we
did
here
so
there's
a
lot
of
topics
we
touched
on
I'm,
not
sure
if
we
can
demo
all
the
aspects
of
it.
What
we
thought
we
could
demo
is
creating
resource.
We
have
already
created
the
resource
here
with
three
replicas
sets,
so
we'll
bring
that
here
and,
let's
see
if
it's
running
okay,
we
still
have
the
problem.
It's
not
coming
up
yet,
but
we
have
the
nginx
demo
system
in
the
next
demo
resource
created.
B
What
we're
trying
to
demo
in
here
is
maybe,
if
I
look
here
better,
then
I
can
my
eyes
are
not
that
great.
What
we're
trying
to
demo
here
is
we
create
the
resource
I,
as
a
production
environment
operator
wants
to
create
new
dashboards.
What
we
have
provided
in
our
environment
or
in
cloud
provider
is,
you
can
create.
We
have
Griffin
RCR
DS,
so
you
can
create
create
that
refine
our
dashboards
on
the
fly
and
that's
what
I
wanted
to
show
here.
B
Let's
talk
to
the
Ameth
first,
so
in
the
mo5,
it's
we're
creating
the
regaling
nginx
resource,
the
important
things
that
we
talked
about,
the
number
of
replicas
we
have
three,
then
the
type
is
rolling
update
and
the
two
fields
that
are
two
parameters
that
are
important
is
maximum
surge
in
maximum
unavailable.
Never
set
that
to
zero,
because
the
hotel
kubernetes
that
you
can
have
maximum
money
unavailable
at
zero
or
maximum
additional
as
zero.
And
then
the
liveliness
and
readiness
probe
that
we
talked
about.
B
There
are
three
protocols:
TCP
command
line
and
TCP
command
line,
and
there's
one
more
I
forget,
but
those
two
you
can
apply
to
check
for
the
readiness
and
the
liveliness
of
your
probe,
but
is
important.
That's
what
you
use
for
enabling
or
we're
enabling
or
putting
down
all
your
health
checks
where
you're
checking
or
for
your
dependencies.
If
your
dependencies
already
or
not
part,
is
less
redness.
B
And
then
here
is
the
important
one
where,
when
you
are
doing
your
TLS
setup
or
your
making
sure
all
your
communication
is
through
certificate,
you
want
to
make
sure
that
you
have
your
certificate
authority
in
place.
You
have
your
certificate
authority
in
place.
You
have
issuer
in
place,
your
registered
your
certificate
to
the
certificate
manager
and
you
do
have
your
certificate
mounted
to
get
you
the
secrets,
and
you
apply
your
secrets.
You
use
your
secrets
in
your
custom
resource,
so
so
right
here
at
the
bottom,
is
your
secret
name.
B
B
Where
is
okay,
so
that's
the
one
certificate
is
defined
in
the
secret
I.
Think
I
touched
that
one
the
certificate
is
defined
in
I
actresses
through
the
secret,
and
it's
going
to
add
anything.
Oh
yes,
so,
just
like,
we
have
been
F
on
our
dashboard
as
the
CRTs
we
talked
about,
we
any
custom
resources
we
are
bringing
in
or
any
new
resources
that
we
are
bringing
in
so
that
applications
can
take
advantage
of
is
all
through
CR
DS,
so
Griffin,
our
dashboard
is
a
CRT
certificates
is
through
CRT.
B
A
B
So
that's
the
dashboard
42
minutes,
that's
the
dashboard.
We
created
right
before
we
started
the
session
we
created
through
the
command
line
as
a
as
a
resource
and
that's
the
dashboard
that's
coming
up,
which
is
few
minutes.
Packets,
collecting
the
memory
for
the
application
of
nginx
resource
that
I
just
created.
A
A
The
next
problem
really
becomes
how
do
I
manage
many
clusters,
so
I'd
invite
you
to
take
a
look
at
some
of
the
things
we're
doing
with
our
multi
cloud
manager.
This
actually
brings
a
language
to
deploy
and
manage
applications
using
the
application,
sig
CRT
and
then
also
brings
a
policy
language
to
manage
security,
while
also
providing
visibility
of
the
health
of
applications
and
the
readiness
of
these
clusters
for
compliance
and
then
a
few
additional
resources.
The
three
titles
that
you
see
here
are
articles
on
medium,
these
kind
of
go
into
more
detail.
A
The
12
factor
base
example,
this
seven
missing
factor
which
has
really
been
the
core
of
this
talk,
some
additional
guidance
on
readiness,
probes
and
myself,
and
a
few
other
folks
from
IBM
co-authored
a
book
around
kubernetes,
just
to
highlight
some
of
the
introductions
how
to
run
applications,
how
to
run
clusters
and
you
can
download
a
free
copy
from
that
link
if
you'd
like
and
with
that
we're
I
think
almost
at
time.
So
maybe
we'll
take
questions
up
here.
A
If
there
are
any
questions,
if
you
want
to
hang
out
and
if
I
can
gently,
maybe
request
if
you're
open
to
it,
I'd
love
to
get
a
quick
selfie
before
we
close.
Is
that,
okay
with
everyone
all
right
so
check?
Oh,
you
want
to
jump
in
with
me
real,
quick
yeah
and
maybe
on
the
count
of
three.
If
we
can
say
kubernetes
all
right,
all.