►
From YouTube: (Mis)Understanding Cloud Native Java - JakartaOne 2022
Description
Cloud is great, and cloud native is really nice. However, some misconceptions and terms are often thrown around—from JDK distributions and memory footprints to startup times, health probes, observability, serverless Java apps, zero downtime, and many more. Some can be confusing, and some even intimidating. We try to bust a few myths about cloud native development and give you some pointers on how you can develop better and more modern applications.
-
Jakarta EE gives developers a comprehensive set of vendor-neutral, open specifications that are used for developing modern, cloud native Java applications from the ground up. With Jakarta EE, technology developers and consumers can be confident they have the best technologies for developing cloud native, mission-critical applications. And they can build on decades of Java developer expertise to move existing workloads to the cloud.
Learn more: https://jakarta.ee/
Follow us on Twitter: https://twitter.com/home
Follow us on LinkedIn: https://www.linkedin.com/showcase/jakartaee/
Like us on Facebook: https://www.facebook.com/JakartaEE/
B
A
And
my
name
is
rustam:
I
am
joining
you
all
from
Norway.
Also
I
am
also
a
Java
champion
and
as
well
in
addition
to
that
I'm
also,
a
Google
developer
through
Cloud,
so
I
work
quite
a
bit
with
Cloud,
Technologies
and
I
am
also
very
happy
to
talk
to
you
about
Cloud
native
Java
and
how
people
tend
to
misunderstand
things
when
it
comes
to
it.
So
let's
get
started
right
so
I
mean
this.
Probably
this
talk
can
be
summarized
by
one
slide
and
that's
the
one
you
see
in
front
of
you
now.
A
So
that's
the
the
short
Universal
answer.
The
answer
of
a
consultant
I've
been
working
as
a
consultant
for
many
years.
Usually
the
answer
is.
It
depends
because
a
bit
longer
version
of
that
is
that
every
decision
has
some
kind
of
quantitative
or
qualitative
qualitative
pros
and
cons.
So
it
can
be
any
decision
that
you
make.
It
will
have
some
kind
of
influence
on
something.
A
Like
you
know
the
language
you
choose
to
to
write
your
application
in
the
application
you,
where
you
want
to
run
your
application,
the
platform
or
anything
like
that
will
have
some
kind
of
pros
and
cons.
Always
you
all
you
need
to
do
is
to
put
them
all
onto
the
you
know,
scale
and
see
it
make
sure
that
the
number
of
Pros
or
the
weight
of
Pros
is
actually
heavier
than
the
cons,
and
it
should
be
good.
A
So,
with
that
being
said,
let's
talk
a
little
bit
about
Cloud
native
I
mean
what
do
we
actually
mean
by
Cloud
native,
and
to
do
that?
It's
a
very
good
starting
point
is
to
look
at
the
cloud
native
definition
by
cncf,
so
Cloud
native
Computing
Foundation
has
a
definition.
It's
this
I
mean
it's
a
really
good
definition,
but
for
slides
this
is
a
wall
of
text,
so
we
made
it
a
little
bit
easier
for
you.
A
We
have
highlighted
the
most
kind
of
important
parts
of
of
of
this
definition
for
us
for
what
we're
going
to
use
in
this
presentation,
and
then
we
also
removed
all
the
or
kind
of
grayed
out.
All
the
other
words
so
now
you're
sitting
with
kind
of
well
in
the
gist
of
the
definition,
to
make
it
a
little
bit
more
easier
to
digest.
We
also
added
a
little
bit
of
separation
of
what
you
were
talking
about.
So
we
want
to
we'll
talk
a
little
bit
about
what
we're
building.
A
When
we
talk
about
Cloud
native
applications
like
what
do
we
actually
build?
How
do
we
do
that?
And
why
do
we
want
to
do
that
and
like
when
you,
when
you
try
to
convince
someone
to
do
something
or
were
you
trying
to
I,
don't
know,
sell
something
to
someone
I
mean
I,
don't
mean
to
sell
it
for
money
or
something
but
like
you
know,
sell
an
idea
or
convince
someone.
A
Well,
then,
you
need
containers
and
service
meshes
and
micro
services,
and
all
this
it's
like
okay,
cool,
yeah,
okay
and
then
you
can
actually
talk
about
more
like
what
actually
are
you
going
to
build
and
when
we
have
all
that
we'll
get
a
skill
applications
that
are
able
to
run
on
private
or
public
or
hybrid
clouds,
and
so
on,
so
on
so
on.
So
this
is
the
gist
of
the
thing
that
we'll
be
talking
about
like
the
cloud
native
applications
and
what
we
mean
by
that.
C
B
21.,
oh
well,
sorry,
true,
still
still
I'm,
not
actually
here
so
about
Cloud
native
Java
software.
I,
probably
you've
seen
this
when
you're
working
with
your
applications
and
if
you're,
looking
at
your
applications
from
a
platform
point
of
view
like
how
do
you
provide
the
entire
functionality?
Dna
users,
the
cloud
native
software
that
you're
building,
including
the
one
that's
based
on
Java,
is
currently
thought
as
highly
distributed.
B
It
has
to
evolved
with
the
language
with
the
tools
and
Frameworks
that
are
available
on
the
market,
because
everybody's
is
evolving,
is
going,
is
going
and
innovating,
and
your
software
has
to
keep
up
with
those
too
and
also
that
operates
also
in
a
constantly
changing
environment.
This
means
that,
well,
maybe
the
language
at
the
JK
or
the
tools
and
Frameworks
are
changing,
but
also
the
infrastructure
is
now
not
of
just
staying
in
place.
That's
evolving
as
well.
B
I
can
give
you
one
example
why
security
and
that's
very
important,
because
we
want
to
make
sure
that
our
software
is
always
prepared
to
survive,
attacks
or
any
other
issues
that
can
come
throughout
time.
Those
being
said
the
if
you're
looking
at
the
cloud
native
applications
and
why
we're
building
the
cloud
native
applications
in
the
context
of
cloud
native
software
is
because
they
match
a
few
points
that
we
always
wish
to
touch
as
developers.
B
The
current
landscape
of
cloud
native
applications
is
looking
at
making
applications
highly
available.
Those
applications
that
are
highly
available
also
are
good
in
terms
of
resilience.
The
redundancy
is,
they
are
minimized
and
they're
extensible,
so
they're
not
just
highly
available
and
highly
distributed,
but
they're
also
extensible.
You
want
to
be
able
to
evolve
your
architecture
and
that's
why
we
are
Distributing
and,
like
you
know,
splitting
the
concerns
of
our
the
architectures
nowadays
with
so
many
tools
and
Frameworks,
so
that
we
can
build
something,
that's
extensible
through
time,
and
we
don't
rewrite
that.
B
We
don't
rewrite
everything
from
scratch.
Every
time
that
a
shift
in
technology
happens.
That
gives
us
also.
Flexibility
need
to
have
frequent
releases.
So
that
makes
us
at
first
during
developing
and
actually
delivering
Innovation,
but
these
frequent
leases
can
be
done.
Reliable
can
be
made
maintainable.
B
B
You
know
probably
are
familiar
with
open
jdk
and
where
you
can
find
that
anyone
can
pick
up
that
source
code
and
produce
a
bill
and
post
that
to
our
URL.
However,
there's
a
certain
certification
process
that
is
going
on
that
must
be
used
in
order
to
ensure
the
quality
of
that
construction
that
is
being
created
there,
so
that
certification
is
being
performed
by
the
Java
Community
process.
B
You've
probably
heard
about
gcp,
which
provides
a
technology
compatibility
kit
called
tck,
and
if
an
organization
produces
an
open,
jdk
build
that
complies
to
in
the
entire
tck
that
build
is
described
as
compatible
with
Java
SE.
Now,
if
that
build
is
like
called
the
compatible
with
Java
I
see,
the
vendor
can
obtain
a
commercial
license
from
Oracle,
and
then
it
can
be
called
Java
SE,
so
in
short,
open
jdk
plus
vendor
process
transforms
a
source
base
into
several
different
bales.
B
Moreover,
if
you're
looking
at
you
know,
versions
of
jdks
that
are
available
in
the
in
the
landscape,
you
can
choose.
For
example,
GDK
builds.
If
you
only
use
the
default
features
even
look
into
those
six
month
releases
because,
for
example,
if
you
only
use
the
default
features,
I
mean
you
don't
heavily
rely
on
security
updates
for
your
business.
You
can.
You
can
also
opt
for
those,
but
if
you
want
to-
and
of
course
if
this
will
ensure
constant
updates.
B
Well,
maybe
you
should
look
into
the
more
long-term
releases
that
are
available
and
by
the
way
next
year
is
going
to
be
the
novelty
the
most
probably
a
very
expected
moment:
Gemma
21,
the
new
LTS
available.
So
if
your
application
is
cloud-based,
please
consider
a
build
distributed
by
a
vendor
because
well,
you
probably
would
need
somebody
to
support
to
support
that
and
it's
good
to
rely
on
on
security
from
from
vendors
as
well.
B
So
those
being
said
about
the
jdk
that
you
could
use
how
about
talking
about
the
compiler
of
choice
for
cloud
native
applications,
because
when
you're
working
with
Cloud
native
applications,
you
have
to
also
in
the
travel
landscape,
you
have
two
options:
ground,
VM
and
open
jdk.
Now
the
red
pill
for
Nate.
B
So
now
that
we
discussed
a
little
bit
about
the
GDK
and
the
compiler
that
are
available
in
the
in
the
landscape.
Let's
talk
about
another
misunderstanding:
that's
in
our
in
our
world
and
about
discussing
the
measuring
of
the
footprint
of
our
job
applications,
because
probably
you've
heard
that
the
syntag
reduced
memory,
footprint
or
minimize
the
memory
footprint
I'm-
probably
wondering
what's
that
coming
from.
Or
how
do
you
do
that?
How
do
you
measure
that
as
a
Java
developer,
so
to
understand
the
memory
usage
for
a
Java
application?
B
You
should
know
that
by
default,
the
jvm
allocates
comes
with
a
default
memory
value
set
as
a
starting
point
that
one
can
be
fine-tuned
afterwards
like
well.
The
JDM
uses
a
default
garbage
collector
implementation,
and
you
can
fine
tune.
The
GC
that
you're
choosing
the
garbage
collector
that
you're
choosing
and
based
on
that.
Your
jvm
will
choose
a
different
memory
value
at
starting
point,
so
always
think
about
when
you
want
to
fine-tune
something
you
can
start
with
the
defaults.
B
But
if
you
feel
that
okay,
you
can
improve,
or
maybe
like
look
what
can
be
done
better
look
into
the
other
collector
options
available
and
see
how
your
application
performs
with
those
with
those
set.
Moreover,
you
should
know
that.
Well,
the
jvm
is
running
your
application
and,
besides
that
default
memory
that
is
being
set.
B
Although
that,
most
of
the
time
for
the
measuring
of
memory
we
use
RSS
to
like
say
like
look
the
food
memory
footprint.
Is
this
small?
You
should
know
that
it's
not
just
RSS
when
it
comes
to
memory,
so,
for
example,
there
can
be
cases
when
some
the
same
shared
libraries
can
be
duplicated
or
counted
in
different
processes.
So
it
might
be
the
case.
It's
not
all
the
time
the
accurate
measurement
for
our
application,
but
by
looking
at
you
know
how
to
measure
memory.
B
These
are
very
useful
instructions
to
be
sent,
but
you
should
be
aware
that
when
you
are
enabling
nmt
you're,
also
adding
some
overhead
to
the
overall,
you
come
in
your
naming,
nmt
and
also
your
printing,
the
nmt
statistics
and
all
this,
if
you're
using
that
for
a
long
long
term
and
also
send
a
couple
of
Technology
commands
to
your
jvm
for
a
longer
period
of
time.
That
can
affect
your
performance
and
can
have
an
overhead
over
their
overall
performance
of
your
application.
But
you
can
also
measure
the
memory
in
containers.
B
So
you
can
get
information
about
how
your
application
performs
like
in
performance
tests
with
you
know
having
those
flags
set.
But
you
can
also
measure
the
memory
in
containers
by
using
the
command
Docker
top
the
one
that
you
have
there.
So
it's
always
good
to
like
measure
at
the
level
of
jvm
and
the
application
running
on
gvm,
but
also
measure
the
application
encapsulated
inside
the
container
as
well.
So
you
can
see
which
portion
does
what
and
how
much
it
consumes
at
every
level
of
integration.
A
Yeah,
that
is
a
very
good
question
too
I
mean
it
is
back
in
the
days
where
we
started
when
I
started
my
developer
career,
developing
job
applications
like
I,
don't
know
15
16,
something
like
that
years
ago.
It
was
not
really
a
big
thing
right,
because
you
would
just
deploy
everything
on
a
application
server.
Maybe
you
would
just
open
the
the
website
or
like
the
call
web
service
or
whatever
once
just
to
warm
it
up,
and
then
you
do
it
just
run
there
right
until
you
have
to
restart
it
again.
A
A
Actually,
starting
because
if
the
container
is
spinning
up
really
fast,
but
you
have
a
huge
ginormous
monolith
of
an
application
just
like
an
elephant
put
into
a
tiny
little
container,
that
I
usually
called
that
it
still
will
take
that
quite
a
bit
of
time
for
that
elephant
to
turn
around,
and
actually
you
know,
start
juggling.
You
know
the
the
data
or
whatever
that
that
application
should
be
doing,
and
that
really
sucks
I
mean
your
your
containers
up.
A
Another
thing
is
that
you
have
to
be
careful
when
checking
for
external
dependencies
and
Readiness
in
your
approach,
so
you
have
a
probe.
You
have
a
Readiness
probe
that
will
tell
you
that
exactly
what
I'm
saying
like
the
time
by
the
when
the
application
is
ready,
but
then
you
have
all
this
other
things
that
are
connected
to
it,
and
maybe
you
don't
need
to
load
all
this
at
the
same
time,
maybe
you
can
do
you
can
optimize.
So
the
point
is
long
story.
Short.
A
Is
try
to
optimize
the
startup
of
your
application
as
much
as
possible,
try
to
keep
all
the
third-party
things
outside
unless
you
have
to
have
them
inside
and
initialize
them,
maybe
lazy,
load
them
or
kind
of
initialize
them
at
later
points,
and
so
on.
So
on
so
on,
you
really
need
to
if
you're
going
from
something
that
used
to
be
running
on-prem
without
scaling
up
and
down
so
much.
A
A
A
Speaking
of
probes
and
speaking
of
so
now
we
talked
about
like
the
startup
time
and
Readiness
of
of
an
application,
but
there
is
also
something
that
comes
afterwards.
So
when
your
application
is
running
now,
you
should
be
able
to
keep
your
kind
of
hand
on
a
pulse
and
just
checking
that
your
application
is
doing
well,
and
you
know
everything
is.
A
We
did
not
do
that.
Will
that
consider?
Will
that
make
performance
worse?
Will
that
actually
influence
performance?
Maybe
not
or
you
know
all
these
kind
of
things
are
really
because
you
know
if
you
have
a
container
and
you
ask
your
elephant
like
you
know,
I'm
I'm,
just
saying
else
and
take
your
application.
You
know
every
every
time
you
ask
it's
like.
How
are
you
doing?
How
are
you
doing?
Are
you
good?
A
Are
you
good
and
then
it
takes
a
little
bit
of
time
for
it
for
for
that
elephant
to
answer
and
and
then
you
know,
continue
juggling
data
and
stuff,
as
as
as
it
was
so
probes
types
of
probes,
startup
probe,
it's
something
very
useful
to
know
how
like
I
said
like
when
your
container
is
starting,
then
you
have
Readiness
bro.
That
is
when
all
of
those
are
used
by
kubernetes
by
the
way
and
they're
all
any
other
native,
Technologies
and
stuff
like
that.
But
the
kubernetes
is
using
that
to
know.
A
Okay,
the
container
is
running
cool
okay,
Readiness
probe
is
responding
so
cool,
then
my
application
is
running.
Nice
live
Miss,
probe.
Okay.
That
thing
is
just
gone
crazy,
so
we
need
to
restart
that.
So
we
just
you,
know,
take
down
that
container,
create
a
new
container,
put
our
happy
elephant
in
that
container
and
let
him
do
its
thing.
I,
don't
know
why
I'm
talking
so
much
about
elephants
today,
but
that's
that's
happens
anyway.
So
mechanisms
for
implementing
probes
in
kubernetes.
How
can
you
do
that?
A
Well,
you
can
run
as
a
command
inside
a
container.
You
can
do
HTTP
requests
against
the
container.
You
can
do
grpc
requests.
So
it's
like
you
know
it's
all
about
like
how
do
you
want
to
do
that?
How
what
what
do
you
think
will
be
the
fastest
and
all
that,
so
you
can
do
HTTP
if
you
want
to
go
binary
and
do
jrpc
if
you're
gonna
do
like
really
kind
of
more
low
level
stuff,
you
can
do
TCP
sockets
and
talk
to
through
those.
A
B
I
can
add
a
little
bit
to
this
one.
The
short
PC
request
against
the
container
is
like
newly
added
I
mean
it's
probably
the
latest
edition,
and
probably
many
of
you
have
seen
this
in
the
landscape
that
well,
we
used
to
be
of
developers
focused
on
for
a
long
time
on
so
protocol
I
mean
silk
is
still
used,
then
we
move
to
rest,
and
nowadays
we
also
love
grpc,
so
pretty
much.
B
This
fourth
type
of
this
fourth
mechanism
was
added
to
serve
better
the
applications
that
use
grpc
so
that
we
don't
I
mean
back
in
the
day
when
you
had
the
grpc
eBay,
an
application
using
grpc.
You
used
to
do
something
very
interesting
to
say
so
in
order
to
do
a
probe
to
man
actually
Implement
a
pro
Bond
and
kubernetes
80s
level,
and
now
it's
working
natively,
which
is
a
great
advantage
in
terms
of
working
with
Pros.
Now
back
to
you
understand,
sorry
for
the
interruption.
No.
A
No,
but
that's
perfect
I
mean
that's,
that's
a
very
good
point
and
that's
that's
really
good
to
do
that.
More
often,
let
it
do
it
saying,
and
then
you
can
ask
in
so
many
seconds.
So
that's
that's
the
one,
but
then
you
have
saying
period
seconds
so
you
that
gives
you
an
opportunity
to
specify
the
the
Intel.
So
how
often
do
you
actually
ask
or
how
often
you
should
be
asking
default
value
is
10,
so
there's
default
values
here
as
well.
A
But
you
know,
if
you
want
to
do
class
or
more,
you
can
do
that
timeout
seconds
maximum
number
of
seconds
for
it
to
wait
until
it
says
nothing
happened.
As
you
know,
something
is
wrong.
Success
threshold,
this
number
of
attempts
until
the
probe
is
considered
successful
after
the
failure
right.
So
maybe
you
know
so
you
don't
have
this.
A
What
do
you
call
that,
like
fluctuating
flaky,
flaky
services
and
stuff,
and
the
same
thing
is
for
failure
threshold,
but
just
the
other
way
around
so
here
for
Success
thresholds
like
if
once
is
successful
cool?
You
know,
that's
the
default
value,
but
if
you
know
that
your
service
might
be
a
bit
kind
of
weird,
you
might
just
increase
that
number
right
failure.
Threshold
is
I
mean
you
probably
shouldn't
shouldn't.
Have
that
issue,
but
I
mean
things
happen.
We
do
write
bugs.
A
Sometimes
even
we
don't
really
accept
them
or
like
admit
them
all
the
time,
but
no
accounts
failure,
traditional
speaking
of
bugs
in
case
of
propeller.
What
happens
like
there's
how
many
failures
it
has
to
be
for
kubernetes
to?
Actually
you
know,
roll
up
the
sleeves
and
actually
do
the
Dirty.
Work
of
you
know,
throwing
up
the
container
and
creating
a
new
one
and
again
default
row
is
three
you
can
adjust
that.
But
it's
it's
it's
it's
a
very
nice
and
useful
thing
to
do
so.
A
Probes
are
good,
but
always
there
is
do's
and
don'ts,
and
there
is
always
something
that
you
know
you
should
or
should
not
be
doing.
So
configure
different
assessments
for
your
liveness,
Readiness
and
startup
probes.
You
should
have
them
and
you
should
have
them
a
little
bit
different
way
in
a
setup
in
a
little
bit.
C
A
Maybe
you
need
to
do
that
feather
threshold,
something
about
it
and
in
general,
I
would
probably
say
that
you
need
to
try
and
adjust
those
numbers
as
you
go
because
by
by
the
time
you
will
actually
know
your
application
know
how
it
behaves
and
know
how
things
are.
You
know
it
will
be
easier
for
you
to
just
to
adjust
those
and
fine-tune
those
numbers
as
well,
and
if
the
container
evaluates
a
shared
dependency
in
the
redness
probe,
coordinate
the
timeout
seconds
and
period
seconds
within
the
maximum
response
times.
A
A
That's
a
short
version,
know
that
so
more,
you
should
avoid
checking
dependencies
in
liveness
Pro,
because
those
should
have
response
times
with
minimal
variants,
and
that
is
when
you're
kind
of
dependent
on
all
the
other
things.
I,
don't
know
other
web
services
other
you
know
third
party,
whatever
you
are
introducing
a
lot
of
moving
Parts
there
right.
You
are
introducing
some
issues
with
Network
or
you
know
your
all
of
a
sudden
dependent
on
somebody's
else's
Ops
teams
to
actually
make
it
respond
faster
and
so
on
so
on.
A
Maybe
you
probably
don't
want
to
do
that,
so
keep
in
mind
those?
Maybe
you
need
to
rewrite
your
architecture
again,
going
clouding
so
set
the
initial
delay
seconds
parameter
conservatively
so
that
kubernetes
can
reliably
restart
your
container.
So
it
can,
you
know,
fail
fast,
fail,
quick,
you
know,
and
and
and
well
they
often
does
not
really
apply
here,
probably
hopefully,
but
you
know
at
least
fail
fast
and
just
restart
and
continue
going,
observe
an
exercise
container
restart
to
correct
Behavior
changes
during
initialization.
B
B
One
I
don't
know
what
happened.
The
things
that
I
want
to
say
is
like
you
can
use
the
instrumentation
methods
included
in
the
jdk.
So
there
are
a
few
jdk
tools
that
come
shipped
with
the
with
the
jdk
version,
Java
flight
recorder
being
one
of
them,
because
that
allows
both
administrators
and
developers
to
get
information
about.
B
But
you
can
also
use
those
in
your
automated
tests
to
run
and
see
how
your
application
is
behaving
from
monitoring
from
the
application
side,
upwards
and
last
but
not
least,
look
at
open
Telemetry,
because
that's
the
overall
protocol
and
and
specification
that
can
help
you
to
inspect
and
correlate
the
application
with
the
infrastructure
Telemetry
as
we're
thinking
about
Cloud
native
Java,
we're
thinking
about
like
applications,
job-based
applications
that
are
running
in
containers.
So
we
always
have
to
think
about
the
performance
and
what's
going
on
with
our
application
from
application.
B
B
So,
just
as
a
summary,
you
can
always
collect,
of
course,
logs,
because
logs
help
you,
when
debugging
also
metrics,
because
metrics
tell
you
how
well
your
application
behave,
but
also
tell
you
maybe
access
the
proof
that
you
can
do
things
better
and
think
about
what
to
improve
and
actually
compare
like,
for
example,
mentioned
earlier,
the
garbage
collector
configuration
try
to
see.
How
are
your
match
tricks
when
guard
different
garbage
collectors
are
being
fine-tuned,
then
traces,
because
they
can
tell
you
where
your
request
has
traveled.
B
So
you
can
identify
your
transaction
of
course,
multiple
microservices,
where
that
transaction
went
through
and
what
happened
to
it
and,
of
course,
last
but
not
least,
user
feedback.
Sometimes
we
can
design
the
best
applications
in
the
world
and
Implement
them,
but
if
they're
not
used
something
might
not
be
very
okay
with
them.
So
always.
This
is
all
this
work.
Yeah.
A
If
everything
looks
good
in
the
logs
in
the
traces
in
the
metrics,
you
know,
and
feedback
is
good
and
everything,
and
then
you
think,
okay
cool.
We
can
increase
it
to
20.
We
can
go
crazy
to
80
100
and
then
you
can
actually
do
like
a
slow
migration
of
users
and
all
that
as
well,
which
is
a
very
nice
nice
thing
to
to
do
to
do
so.
Yeah.
That
was
a
little
my
little
thank.
B
A
Oh
well,
I
mean
should
I
say
it
depends
again,
but
I
mean
so.
Serverless
is
a
very
nice
state.
So
this
is
a
very
nice
thing
for
many
reasons,
but
usually
it
will
imply
quite
a
few
things.
It
will
imply,
for
example,
very
often
not
necessarily
always,
but
it
will
apply,
I
imply,
stateless
applications
and
so
on
and
so
on.
So,
okay,
let's
look
into
that.
Let's
look
into
this
thing.
A
What
is
serverless
well
service,
complete
Computing
is
a
cloud
computing
execution
model
in
which
the
cloud
provider
allocates
machine
resources
on
demand,
taking
care
of
the
servers
on
behalf
of
other
of
their
customers.
So
that's
a
long
Wikipedia
definition,
I
love
equipment,
definitions,
they're,
usually
like
a
wall
of
text.
On
the
slide,
it's
perfect
the
short
version,
the
slide
version,
like
presentation,
version
of
that
it's
probably
shouldn't
be
called
serverless
but
manageless.
So
you
manage
less
of
your
application
by
letting
someone
else
do
that
not
humans,
but
computers,
robots.
You
know
kubernetes
and
stuff.
A
That's
the
short
unofficial
version
of
the
definition,
I
guess.
So
what
kind
of
tasks
are
actually
good
for
serverless?
What's
it
good
for
anything?
That's
asynchronous
independent
execution
units.
You
know
anything
that
can
be
just
it's
been
up,
good
thing
die
and
just
well
return
value
for
first,
hopefully,
and
then
die
or
go
to
sleep
or
whatever
intermittent
amounts,
with
a
large
and
predictable
variance
in
usage.
So
that
means
you
have
certain
peaks
of
like
surge
of
users
coming
to
your
application.
That's
really
nice
serverless.
A
It
will
spin
up
many
many
clones
so
that
your
application
serve
it
all
that
when
the
users
are
gone,
when
the
kind
of
the
peak
is
over,
it
scales
down
Slims
down
to
a
little
smaller
pool
and
keeps
on
running.
So
nobody
noticed
anything
everybody's
happy.
Your
your
credit
card
is
happy
as
well,
because
you
don't
have
to
pay
for
all
those
servers.
All
the
time
right
and
also
like
I,
said
already,
it's
something
about
being
stateless.
A
It
doesn't
have
to
be
necessarily
stateless
all
the
time,
but
most
of
the
cases
is
I
mean
it
will
make
your
life
a
bit
easier,
a
bit
too
much
easier
if
it
is
stateless,
short-lived
tasks
that
tolerate
High
latency.
So
if
you
need
to
store
a
state,
it
doesn't
really
works.
Well,
with
applications,
that's
being
killed
and
respawned
and,
like
you
know,
cloned
in
many
many
servers,
so
that's
that's
the
thing.
Another
thing
that
people
usually
talk
about
is
that
oh
serverless.
C
A
It's
not
it's
really
not.
It's
can
be
open
source
tools,
it
can
be.
It
can
be
a
specific
tools
that
are
to
specific
to
a
specific
Cloud,
but
also
it
can
be.
It
can
be
not
necessarily
also
adjust
to
an
application
running
platform
as
well
or
way
of
running
your
applications.
It
can
be,
for
example,
I.
A
Don't
know
there
is
a
even
data,
warehouses
that
can
be
serverless,
where
you
just
put
your
data,
you
put
your
everything,
it
kind
of
scales
up
and
down,
don't
really
notice
anything,
but
it
just
serves
you
data.
So
often
we
think
about
it
as
a
way
of
running
applications.
Then
let's
do
that,
but
there
is
more
than
that
as
well.
Just
so,
you
know
that
as
well.
A
These
techniques
enable
using
coupled
systems
that
are
resilient,
manageable
and
observable,
and
it
is,
does
not
have
to
be
a
specific
Cloud.
It
can
even
be
on-prem,
so
there
is
some
things
like
k-native,
which
is
a
open
source
initiative
between
several
big
companies
and
big
big
actors
in
the
Bose
community
and
generally
in
I.T
landscape,
which
have
gone
together
and
created.
This
thing
it's
on
the
CNC
app
now
and
it's
it's,
it's
really
cool
stuff.
You
can
install
on
your
machine
locally
as
well.
So
that's
really
nice.
A
There
is
also
always
a
way
to
make
your
application
better.
There
is
always
way
of
doing
things,
I
mean
so
one
thing
is
serverless
how
you
spin
it
up
and
down.
The
other
thing
is
like:
how
do
you
actually
automate
automate
automate
and
when
you
think,
you're
done
with
automating
your
ultimate
a
little
bit
more,
because
you
really
want
to
do
that
because
it
will
make
your
life
easier.
It
will
make
your
if
anything
goes
wrong.
If
anything
has
to
be
redone
recreated.
You
really
want
that
thing.
A
Automated
click,
Ops
is
not
a
thing
anymore.
Please
do
not
do
click
Ops,
because
it's
it
kind
of
error
prone.
It's
boring
it.
Well,
it
sucks
on
some
some
quite
a
few
levels.
So
infrastructure
is
code.
That's
one
way
of
automating
stuff
right
either.
Examples
like
terraform
pull
me.
There
are
different
ways:
different
a
little
bit
different
approaches,
a
little
bit
different
ways
of
doing
stuff
to
collaborative
or
programming.
You
know
all
that,
but
it's
easy
to
create
new
environments.
It's
easy
to
create
new.
Whatever
your
application
needs
create
new
deployments.
A
You
can
spin
up
like,
for
example,
test
environments
in
seconds
test,
your
stuff.
Do
you
think
and
just
delete
all
that
scrap
all
that
in
just
a
matter
of
seconds
minutes
whatever
and
save
again
save
a
lot
of
costs,
save
a
lot
of
actually
one
thing
that
we
don't
mention
so
much
and
we
should
mention
you're,
actually
saving
a
little
bit
of
environment.
You
know
you
don't
have
to
use
all
that
energy.
So
it's
like
Green,
Computing
and
stuff
I
mean
it's.
It's
actually
can
be
quite
noticeable.
A
If
you
have
the
environments
running
I
mean
if
you
don't
care
about
money
at
least
care
about
the
environment.
Okay,
that's,
and
if
you're
planning
to
deploy
on
your
kubernetes,
offering
you
know,
consider
looking
at
pinated,
that's
what
I've
mentioned
already.
So
now
we
have
another
misunderstanding:
we
haven't
been
bold
and
crazy
and
called
it
Obsession.
You
want
to
talk
about
that
Obsession
on
it.
Yeah.
B
B
Sometimes
it
can
be
a
misunderstanding
like
okay,
can
we
go
that
far
like
not
use
anything
and
like
be
so
much
savers
on
in
terms
of
memory
and
CPU,
or
how
can
we
get
to
the
almost
no
zero
downtime,
so
I
think
the
ideal
situation
would
be
like
to
scale
up
and
down
with
not
much
cost
involved
in
terms
of
memory
and
CPU,
but
well
we
need.
We
have
some
influencers
also
in
this
kind
of
strategy,
and
sometimes
the
serverless
world
is
influencing
our
zero
downtime
too.
B
So
if
you're
going
pure
kubernetes
well,
the
deployment
strategy,
of
course,
can
affect
the
way
that
the
downtime
is
perceived
now.
Kubernetes
has
the
rolling
update
as
the
whole
strategy,
but
if
you
want
to
improve
from
that,
because
well
rolling
up
data,
as
we
know,
can
can
run
to
versions
in
parallel
until
the
new
one
becomes
stable
to
serve
requests,
you
can
also
go
with
blue
green
deployments,
or
you
can
go
with
Canary
deployments
in
the
cases
that
you
want
to
test
how
your
different
versions
are
going
to.
B
B
Then
again,
the
way
that
the
Frameworks
that
we're
choosing,
of
course,
the
language
and
tools
that
we're
choosing,
can
influence
the
graceful
start
and
the
graceful
shutdown
and
the
fast
startup
application
and,
of
course,
the
size
of
the
container
image.
That's
why
we
were
talking
about
earlier,
like
you
know,
like
choosing
the
proper
runtime,
but
all
together
with
how
we're
layering
the
container
images.
B
It
matters
a
lot
in
terms
of
how
how
small
our
container
is
going
to
be
one
example
to
give
to
that
like
when
the
downtime
is
affected
by
the
you
know
the
size
of
the
container
image.
So,
for
example,
let's
say
that
one
kubernetes
node
is
not
going
to
be
available
anymore
and
you
have
a
service
that
you
know
you
have
the
option
of
like
another
node
to
be
scaled,
to
be
available
with
the
same
containers
as
the
previous
one.
That
is
no
longer
healthy.
B
In
that
case,
the
container
image
is
downloaded
again.
So
there's
some
time
spent
on
that,
so
the
size
of
the
container
image
is
going
to
be
influencing
what's
going
on
there,
maybe
for
you,
it's
unperceptible,
but
it
can
add
up
to
them
to
those
little
timings
in
time.
Health
problem,
customization
again
is
very
important
because,
as
rustam
has
mentioned
in
the
Pro
bar,
not
to
probe
section
fine-tuning,
each
of
the
parameters
can
help
you
with
the
restarts
of
your
containers,
So
the
faster
the
restart.
Well,
the
better.
B
The
end
user
doesn't
see
that
downtime.
Nowadays,
we
have
become
better
and
better
when
it
comes
to
Cloud
applications
regarding
not
showing
to
our
users
that
probably,
as
some
switch
has
happened,
but
we
are
always,
you
know
have
to
be
aware
that
nothing
comes
for
free
and
we
always
have
to
work
on
improving
our
application
Behavior.
So
those
being
said,
we
thank
you
for
listening
to
us,
we're
looking
forward
to
more
questions
and,
of
course,
more
issues
that
you
have
had
when
running
your
Cloud
native
applications.
A
Of
users,
probably
you
will
need
less,
and
the
cool
thing
is
to
actually
just
since
they're
film
questions,
yet
so
I'll.
Let
you
give
you
some
time
to
type
it.
If
you
have
any.
The
good
thing
is
that
if
you,
when
you
go
serverless,
actually
you
can
share
the
same
resources
like
Hardware
resources
in
between
applications,
because
maybe
your
applications
have
different
phases
of
number
of
like
the
users.
A
I,
don't
know
time
zones,
it
can
be
like
a
periodic
thing
like
some
month
or
more
used
using
one
application
users
using
one
and
the
other
monsters
using
some
meals.
So
you
can
actually
share
the
hardware
and
share
the
hardware
resources
between
your
applications
much
more
easier.
That
also
will
mean
that
you
will
have
less
servers,
because
you
don't
have
to
use
different
servers
for
different
applications
now,
and
that
goes
both
with
your
on-prem
Hardware,
but
also
goes
with
Cloud
infrastructure,
so
public
clouds
and
stuff
with
public
Cloud.
A
You
don't
really
control
amount
of
Hardware,
but
you
do
control
amount
of
money
you
pay
for
that
Hardware.
So
you
know
less
money
better
for
environment
better
for
you.
You
know
all
this
kind
of
stuff,
so
that
was
that
was
I.
Think
final,
my
comments
on
on
serverless
and
number
of
servers
and
all
that
I
do
not
see
any
more
questions
in
the
chat,
so
I
think
we
will
say
thank
you
very
much
feel
free
to
reach
out
reach
out
to
us.