►
From YouTube: The Hidden Costs - How "free" is Kubernetes really? - Matthias Haeussler & Thorsten Jakoby
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.
The Hidden Costs - How "free" is Kubernetes really? - Matthias Haeussler & Thorsten Jakoby, Novatec Consulting GmbH
Kubernetes is often referred to as Container as a Service (CaaS) and is placed as an abstraction layer between the cloud service model Infrastructure and Platform as a Service (IaaS and PaaS). While from a developer perspective it focusses to appear rather as a PaaS model, from a financial perspective the costs incur from the IaaS model. The costs incur from the runtime of the assigned virtual machines - whether they are well utilized or not - as opposed to paying for the runtime of the containers. This is one of many adoption insights in terms of "hidden costs". In this talk Matthias and Thorsten describe their experience about those costs based on the experience of adopting CaaS in several client scenarios. In most cases it was set-up to achieve a "PaaS-like" self-service developer experience. This covers 5+ years of lesson's learned in on- and off-prem setups, GitOps, security, automation, application deployment, legacy integration, observability and skill enablement.
A
A
So
today
we're
going
to
talk
about
kubernetes,
what
a
surprise
here
at
uconn
and
as
part
of
this
new
business
track
we're
going
to
talk
about
our
experiences
in
adopting
kubernetes
for
clients
and
talk
about
the
hidden
costs
and
the
things
that
we
encountered
during
our
various
experiences
in
the
kubernetes
journey
and
called
it
like
how
free
is
kubernetes
really
so
a
few
words
about
us.
We
both
work
at
a
company
called
called
nova
tech
in
in
germany.
A
My
it's,
my
colleague
thorsten,
who
is
a
cloud
technology
consultant
at
nova
tech.
We
basically
both
comes
out
in
the
cloud
space
tarzan
has
a
bit
more
focus
on
the
side
of
security
things
I
am.
I
do
also
give
lectures
at
university
in
the
in
the
time
when
I'm
not
working
at
the
company
and
on
a
community
side,
I'm
also
engaged
in
the
cloud
foundry
community
as
an
ambassador
and
an
organizer
of
a
meetup.
A
So
so
much
for
that.
We
before
we
kind
of
dive
in
into
the
topic.
We
want
to
give
you
a
bit
of
an
idea
of
of
our
background.
So
what
we
do
normally
for
for
living
is
helping
clients
move
to
the
cloud
as
a
very
generic
term.
So
very
often
we
we
support
migrations
from
legacy,
I.t
implementations
to
to
a
modernization
level
re-platforming
and
making
things
cloud-enabled
and
cloud-native.
A
So
that
comes
in
a
kind
of
a
flavor
where
we
do
strategic,
consulting
where
we
do
hands-on
implementation
and
migration
and
and
also
education
and
skill
enablement.
So
how
we
got
to
kubernetes.
We
didn't
basically
go
there
all
directly,
so
to
say,
like,
as
you
can
see,
on
the
very
left,
but
the
traditional
things
we
did
was
mostly
java
based
and
java.
Enterprise
based
application
development,
mostly
in
in
on-premise
and
environments
and
data
centers
and
our
kind
of
gateway
drug
to
the
cloud
was,
was
actually
cloud
foundry.
A
We
discovered
on
the
way
things
we
probably
sometimes
did
not
expect
and
maybe
can
give
you
a
bit
of
an
advice
how
to
move
forward
based
on
our
learnings
so
yeah.
I
pretty
much
said
that
already
the.
Why
we're
here
today,
of
course,
we
will
not
only
talk
about
technology
and
and
and
the
costs
we
also
try
to
give
a
bit
of
a
of
a
business
perspective.
A
Torsten
will
do
a
bit
of
a
deep
dive
into
some
of
our
projects
to
see
that
it's
when
we're
not
making
this
all
up,
it's
really.
It
has
really
happened
and
it's
still
happening
and
and
what
we
took
out
of
that
so
one
little
disclaimer
here
is
this
presentation
will
like
not
provide
you
a?
How
does
it
say
a
golden
template
or
whatsoever
or
a
silver
bullet
to
do
kubernetes
right.
We
haven't
found
that
yet
so
in
case
you
have
feel
free
to.
A
It's
like
that.
We
were
used
to
we're
basically
coming
from
rather
development
and
operation
sites,
so
we
build
applications.
We
deploy
and
run
applications
and
looking
at
things
from
a
past
perspective,
we're
pretty
used
of
like
paying
on
a
per
use
model,
basically
depending
on
the
application
or
microservices
or
let's
say,
of
a
running
container,
and
the
container
runtime
was
mostly
like
one
big
cloud:
foundry
instance
with
multiple
tenants
and
one
of
the
things
that
significantly
changed.
A
So
that
means
we
had
to
worry
and
plan
a
lot
more
about
our
utilization
by
ourselves
and
also
it
wasn't
one
big
kubernetes
runtime
to
handle
them
all.
We
very
often
see
the
situation
that
we
have
or
managing
multi
multi
different
cluster
environments.
So
despite
multi-tenancy
options
with
with
namespaces,
which
we
of
course
use
it's
still
very
more
a
lot
more
case
that
we
have
like
different
clusters
for
different
stages
to
manage.
So
this
is
just
like
one
single
aspect.
A
There
will
be
more,
I
mean
some
of
the
cost
factors
we're
going
to
talk
about.
Is
things
like
provider
choice,
estimation,
size
that
are
mentioned
technology
evaluation
and
adoption,
then
toolings
around
kubernetes
for
security,
apm
logging
and
tracing,
and
also
one
thing
we
encourage
encounter
very
often
is
skill
enablement.
So
this
is
just
a
bit
of
a
teaser,
and
with
that
I
will
hand
over
to
to
torsten.
B
Let's
talk
about
our
journey
along
cloud
projects,
we
had
a
lot
of
projects
and
brought
to
you
some
of
the
most
recognizable
are
or
the
most
important
for
us
on
the
next
slide.
We
put
some
kind
of
time
frame
next
slide.
Please
we
started
back
then
in
2016,
with
a
cloud
migration
of
a
connected
vehicle
back-end
that
took
a
long
time
and
was
followed
by
the
cloud
migration
for
dealer
platform,
with
kind
of
the
same
technology
stack
as
of
now.
B
We
are
building
a
zero
trust
cloud
platform
where
we
will
also
hear
a
bit
afterwards
for
that
we
did
several
cloud
assessments
for
several
projects
with
several
technology
stacks,
but
what
they
also
can
recognize
is
that
since
2017,
we
providing
trainings
for
our
customers
and
also
for
our
colleagues
with
the
things
we
learned
along
the
projects
and
the
things
we
did
not
learn,
but
try
to
get
the
knowledge
there
before
we
dive
into
those
projects
we
will
want.
We
want
to
provide
a
big
thank
you
to
our
colleagues.
B
B
That's
probably
a
tech
stack
which
you
also
have
in
your
organization
or
recognized
from
some
other
projects.
Our
customer
asked.
Is
there
any
chance
for
that
stack
for
this
application
landscape
to
to
go
into
cloud?
They
want
to
have
shorter
release
cycle.
They
want
not
so
much
money
put
into
operations
or
capex
to
opex
migration.
That's
that's
what
they
want
to
do.
We
have
been
tasked
to
find
a
migration
path.
Considering
refactoring
versus
rewrite.
B
Is
there
any
chance
for
another
release
cycle
in
the
business
unit?
Can
we
have
service
contracts
versus
the
old-fashioned
communication
patterns?
On
the
next
slide?
We
will
see
which
technologies
that
we
found.
We
we
knew.
There
is
a
migration
path
and
we
knew
we
need
to
change
the
runtime,
because
one
thing
we
want
to
use
is
one
of
the
five
essential
characteristics
of
the
cloud.
Rapid
scaling.
B
B
B
We
need
to
integrate
old
im
systems.
There
are
many
things
all
around
the
application
which
has
nothing
to
do
with
cloud,
but
we
need
to
integrate
them
once
we
had
those
migration
path.
We
found
that
there
are
many
moving
parts,
many
moving
parts
that
we
need
to
be
put
together
in
order
to
enable
the
team
for
devops
building
a
cloud
platform,
all
around
kubernetes
means
having,
for
example,
secure
pipelines
designed
prior
to
deploy
anything
on
kubernetes.
B
B
B
B
B
We
know
that
one
of
our
abilities
because
they
are
stored
in
a
database
we
just
can
browse
through
it's
quite
easy
to
get
root
access
in
that
strat2
container,
which
has
been
put
into
humanities
cluster
from
there.
It's
quite
easy
to
get
the
metadata
of
those
instance
and
probably
get
root
access
to
those
linux
vm
and
then
which
robots
to
have
the
most
permissions
and
are
secured.
We
could
the
most
weak
death
roads.
B
So
the
road
of
a
developer
has
much
permissions,
probably
to
access
the
database,
and
they
are
very
easy
to
get
for
for
attack
next
slide.
Please
now
we
see
what
lateral
movement
means
we
find
one
weak
spot
and
move
to
another
weak
spot.
Probably
the
next
spot
is
our
database
with
customer
data.
That's
then
quite
interesting.
B
What
you
can
imagine
that
most
of
our
customers
do
have
something
like
trust
networks.
Probably
you
also
have
that
once
you're
in
a
network,
you're
trusted
or
authenticated
user,
that's
very
bad
with
ratchets
to
lateral
movement,
creating
a
zero
truss
architecture
means
each
each
resource
or
each
assets
of
of
the
architecture
needs
explicit
role,
assignments,
authentication
and
so
on
assume
compromised.
B
B
What
is
about
the
weak
technologies?
We
will
put
applications
on
the
kubernetes
cluster,
which
are
going
to
connect
to
in
cobol
monolith,
which
are
going
to
connect
to
an
oracle
database,
probably
application
with
with
spring
framework,
but
five
to
six
years
old.
Docker
images
were
five
to
six
years
old.
They
will
come
on
to
kubernetes
cluster
and
we
will
lift
security
vulnerabilities
with
them.
B
That
means
we
need
to
mitigate
that
risks
prior
to
any
kubernetes
related
tasks,
creating
robust
access
control
within
the
infrastructure,
but
also
within
kubernetes
cluster.
We
need
to
find
insecure
deployments
scan
automatically
for
them.
In
best
case,
they
will
not
be
deployed
on
the
cluster
in
worst
case,
they
are
deployed
and
need
to
be
isolated,
put
them
into
a
cm
having
ai
based
tools
like
defenders
that
are
things
we
need
to
build
around
all
those
kubernetes
cluster.
B
A
Well,
thank
you.
I
will.
I
will
try
to
answer
that
question
and
go
into
that
right
in
in
a
bit
before
before
that.
First
of
all,
well
thanks,
and
I
think
it's
also
very
important
for
our
audience
to
understand
and
see
what
are
the
the
business
drivers
and
the
business
needs
in
which
context
we
get
into
those
engagements
and
what
are
all
the
technologies
and
and
and
tools
that
that
surround
kubernetes,
which
is
basically
the
the
the
the
common
denominator
across
all
the
things
that
that
we
do
there.
A
Now
it's
going
a
little
bit
from
from
business
to
to
technology.
I
mean,
if
you
look
at
the
stack
that
that
toast
has
already
showed.
I
mean
these
were
the
two
that
were
in
there.
We
have
other
ones
in
this
example
for,
like
with
an
adoption
of
kubernetes
and
ibm
cloud
with
monitoring
stacks
with
instantagrafana
automation,
with
with
ansible
and
and
jenkins.
A
A
What
we
have
mentioned
before
was,
of
course,
the
observability
factor,
so
this
is
just
one
kind
of
tiny
sub
landscape
within
that
landscape,
and
even
there
it's
almost
impossible
like
to
evaluate
them
all.
So
a
lot
of
experience
is
definitely
helpful
there.
But
still
you
need
to
to
continue
learning
and
and
stay
kind
of
on
on
top
of
the
curve.
A
So
colleagues
of
ours
have
actually
come
up
and
created
a
tool
called
open,
apm,
it's
an
open
source
kind
of
documentation,
so
to
say
where,
like
parties
can
can
contribute
to
and
and
to
figure
out
which
technology
artifacts
would
actually
work
together
and
and
provide
useful
combinations
of
how
to
collect
data?
How
to
like
store
the
data,
how
to
present
the
data
of
all
the
monitoring
and
and
logging
metrics.
So
I
definitely
recommend
to
check
this
out
so
yeah
summing
things
up,
there's
the
business
side.
A
There's
the
technology
side,
there's
a
lot
of
learning
a
lot
of
things
you
need
to
do,
and
just
speaking
of
learning
brings
me
to
what
the
final
topic
here
and
tostner
has
already
asked
that
we
try
to
provide
training
to
all
of
our
clients.
Sometimes
we
just
do
dedicated
technology
training,
but
very
often
we
do
like
training
dedicated
when
we
feel
the
need
for
for
certain
participants,
but
for
the
eyes
of
the
training.
A
Of
course,
we
try
to
prepare
people
also
not
only
just
to
master
kubernetes,
but
some
of
them,
of
course,
also
want
to
go
into
a
direction
and
get
certified,
and
this
certification
also
comes
with
some
implications.
I
mean
I'm
not
sure
how
many
of
you
are
do
have
one
of
those
kubernetes
certifications,
there's
like
the
application,
developer,
the
architect
and
the
security
specialist
and
we're
probably
closest
to
the
to
the
ckad
and
what
I
took
out
here.
A
What
is
two
sample
scenarios,
so
this
is
like
all
hands-on
and
a
very
good
where
you
have
to
demonstrate
that
you
are
able
to
handle
the
api
and
walk
through
those
steps.
Now,
looking
at
the
things
and
say
well,
I
want
to
create
five
engine
x
ports
label,
something
like
that
and
label.
Other
ones
like
that
or
create
a
busy
box
called
an
echo
or
message
or
whatsoever
will
definitely
show
that
you
are
qualified
to
to
handle
the
api.
A
But
if
I
play
an
unfair
role,
I
could
also
say
none
of
my
clients
has
ever
asked
me
to
do
that.
So
I
mean
of,
of
course
they
haven't.
But
what
I'm
trying
to
say
here
these
these
trainings
are
very
much
on
an
how-to
level
like
they
learn
how
to
do
the
things,
but
you
don't
really
learn
a
lot
why
you
would
do
the
things
and
to
apply
which
ones?
Let
me
give
you
two
examples
what
we
saw
in
the
past
we
saw-
and
this
is
again
we're
not
making
this
up.
A
We
just
cannot
put
the
client
names
onto
that,
but
we
saw
scenarios
where
people
were
deploying
one
micro
service,
a
single
micro
service
like
busy
to
an
entire
cluster.
They
wanted
super
high
availability,
which
they
of
course
got,
but
it
was
a
very,
very
under-utilized
environment,
as
you
can
imagine,
on
the
other
side,
we
saw
people
putting
all
of
their
micro
services
and
into
all
of
the
containers
into
one
pot,
and
the
thing
would,
if
you
like,
relate
to
that
to
that
certification.
A
A
So
one
of
the
things
that
we
do
is
really
try
to
work
on
that
from
a
from
a
logical
example
which
makes
sense
so
we
have
like
a
coherent
micro
service
application
or
we
take
pieces
out
of
the
client
application.
Do
the
exercises
on
them
to
see
how
do
you,
trade,
stateless
and
stateful
things,
and
how
do
you,
the
communication
right
and
and
what
is
how
do
you
actually
write
your
application
or
transform
your
application?
A
Now
this
kind
of
brings
our
things
to
an
end,
I
mean
we
probably
could
tell
you
a
lot
more
stories
of
things
we
encountered
here,
but
time
is
short,
and
maybe
we
can
get
in
touch
about
this
anytime
later
on.
So
I
just
wanted
to
to
summarize
the
the
things
here
for
you
real
quickly
now
the
first
one
is,
as
I
already
said,
if
you
make
a
decision
of
adopting
or
not
adopting,
kubernetes
just
be
aware,
it's
not
about
kubernetes
itself.
Only.
A
You
basically
will
it
will
buy
you
in
into
an
entire
ecosystem
of
new
tools
and
technologies,
and
it's
a
lot
of
fun.
I
mean,
and
it's
also
kubernetes
is
an
awesome
technology
and-
and
you
can
do
a
lot
of
things
with
it,
that
you
wouldn't
be
able
to
do
without
it.
So
just
our
recommendation
is
to
plan
and
allow
yourself
enough
time
to
evaluate
those
things,
because
you
will
probably
need
it
and-
and
it
will
also
make
you
more
flexible-
to
exchange
certain
parts
which
make
your
overall
architecture
more
robust.
A
So
there
will
be
you're
not
going
to
have
decisions
about
provider,
options
on
off-prem
container,
build
mechanisms,
security,
apim
logging
tracing
and
a
lot
more.
So
most
of
them
still
relate
to
traditional
I.t
and
would
even
be
there
without
kubernetes,
but
with
kubernetes
the
the
your
options
will
multiply.
A
Then
this
is
probably
one
of
the
of
the
biggest
things.
Is
it's
a
lot
of
fun
to
play
around
with
the
technology,
but
it's
also
dangerous
to
get
stuck
into
like
a
level
with
where
you
don't
provide
business
value
in
another
or
put
it
in
other
terms.
It's
like
don't
try
to
solve
problems
which
have
already
been
solved,
because
a
lot
of
tools
might
already
have
pulled
together,
the
abstraction
which
might
be
the
right
one
for
you.
So
my
recommendation
is:
don't
probably
don't
build
everything
from
scratch.
A
There
is
a
tutorial
which
is
called
kubernetes
the
hard
way,
which
does
that,
and
there
is
a
reason
why
this
tutorial
is
called
that
way.
So
if
you
have
the
choice,
use
a
managed,
kubernetes
environment,
so
that
enables
you
to
focus
on
application
development
and
provide
the
value
quickly
to
your
clients.
A
A
A
A
Don't
go
all
in
make
it
like
on
and
off
the
kind
of
decision
do
pocs
do
lighthouse
projects
evaluate
get
familiar
with
things,
evaluate
pros
and
cons
which
will
help
you
again
later
on
the
way
so
summarizing
again
there
is
no
silver
bullet
and
I'm,
I
think,
I'm
running
slow
slightly
over
time
here.
So
with
that,
I
want
to
say
thank
you
for
listening
from
from
from
both
of
us
we're
gonna.