►
Description
Containers, applications, functions: When deploying workloads to cloud platforms, developers have various OSS options. This talk focusses on Kubernetes and compares how Cloud Foundry and Knative relate to it and also how they can extend and improve it.
I’ll compare and contrast the latest experiences of those platforms in order to extract a meaningful comparison from a developer perspective, providing answers to the following questions:
How simple and user-friendly are they? Where are the differences/where are the overlaps? How mature are the individual solutions? Which type of workloads are suitable for which platform?
Additionally, I’ll measure and compare key metrics that affect the developer experience (e.g., time to deploy, time to scale, and more). The overall goal is to better understand what makes each individual useful in the best way and how they can work together. Each technology will be shown with live demos.
A
So
as
yeah
as
already
announced,
I'm
going
to
talk
about
cloud
platforms
and
cloud
platforms
with
mostly
like
open
source
flavor,
which
are
very
common
at
the
moment,
so
the
most
prominent
one
is
definitely
going
to
be
kubernetes
and
I'm
trying
to
put
that
into
relation
into
like
alternatives
or
complementary
extensions
which
could
be
cloud
foundry
and
and
k
native,
just
as
an
addition.
I
would
like
to
keep
this
as
interactive
as
possible.
A
A
Also,
if
you
can't
see
something
very
well,
which
was
my
experience
from
a
few
remote
presentations
that
my
screen
was
super
clear
but
the
but
the
the
streaming
or
the
recording
was
not
so
please,
please
feel
free
to
tell
me
and
I
can
try
to
increase
the
fund
or
whatsoever
change
the
colors.
Whatever
helps
you
to
make
things,
look
better
for
you.
A
Now
a
few
words
in
addition.
Well,
basically
what
race,
I
just
said:
I'm
also
a
meetup
organizer,
so
I'm
always
happy
to
speak
at
meetups,
but
I'm
also
happy
to
host
meetups.
I'm
doing
that
in
the
area
of
stuttgart,
mostly
for
the
around
the
topic
of
cloud
foundry,
but
not
really
totally
limited
to
that.
A
A
Migration,
technologies,
whatever
will
help
them
make
their
modern
software
experience
more
smooth,
yeah.
So
much
for
that,
maybe
two
words
about
nova
tech.
I
don't
really
want
to
go
into
much
advertisement
here.
You
will
find
the
things
that
you
need
on
our
homepage.
Something
I
would
like
to
highlight
is
we
are
very
active
in
exactly
that:
meetup
space
that
I
said
before
next
to
the
cloud
foundry
meetup.
We
also
have
like
the
docker
meetup,
a
scrum
tisch
for
the
agile
folks,
something
for
kamunda.
We
hosted
something
for
for
angular.
A
A
B
A
But
the
interface
to
the
platform
was
always
pushing
code.
We're
going
to
see
that
later
on
now
in
2013
and
14
things
changed
dramatically
with
docker
and
then
in
particular,
kubernetes
like
taking
the
world
by
storm
and
bringing
that
mass
adoption
to
the
world
of
running
software
in
containers
and
also
providing
an
open
source
enterprise
ready
platform
for
that,
and
so
this
influenced
some
further
developments.
A
So
in
2017,
istio
came
out
as
a
so-called
service
mesh
to
handle
the
traffic
between
the
workloads
in
kubernetes
and
enabling
a
lot
more
things
like
multiple
vision,
deployments,
automatic
scaling
based
on
on
traffic
within
the
cluster
and
so
on.
We're
also
going
to
see
that
later
k
native
was
a
technology
that
resulted
out
of
that
or
which
I
should
say
it.
A
It
requires
something
like
a
service
mesh
underneath
to
to
function
properly
and
also
cloud
foundry
transformed
slightly
in
a
way
that
the
internal
container,
runtime
and
scheduling
also
got
got
replaced
by
by
docker
and
kubernetes.
So
these
are
the
things
pretty
much
that
I
want
to
walk
through
today.
Some
things
with
a
little
bit
of
explanation,
mostly
I
would
like
to
to
to
demo
live
so
again.
If
you
have
any
questions
throughout
that,
please
feel
free
to
to
interrupt
me
now.
This
is
a
a
google
trend.
A
I
could
potentially
also
show
that
live
in
the
browser,
but
it
will
work
here
as
well,
where
I
show
the
the
amount
of
invocations
here
in
the
united
states,
but
you
can
also
do
that
worldwide.
It
wouldn't
look
much
different
about
the
search
terms
of
cloud
foundry
and
claim
native,
and
you
could
see
it
started
slightly
before
that
graph
in
around
2011
and
then
kind
of
kept
these
almost
steady
line,
kind
of
came
to
existence
fairly
later.
A
So
when
I
started
this
is
like
a
cloud
foundry
minimal
kind
of
diagram
to
just
show
you
what
kind
of
concepts
you
are
exposed
to
when
you
work
with
the
technology,
so
there
are
applications
like
stateless
applications.
Hopefully
their
services
stay
full
services,
so
the
entire
concept
is
aligned
on
like
a
12-factor
idea
and
like
routes
to
expose
those
applications
to
the
world.
So
the
concept,
as
you
can
see,
is
fairly
minimal
and
also
from
the
from
the
wording
of
things
it's
very
developer
focused.
A
A
The
application
is
just
part
of
the
container
and
that's
where
it's
basically
hidden
and
kubernetes
only
operates
on
that
container
interface.
Now
still
also,
you
might
think
the
first
one
looks
easier.
The
second
one
is
far
more
popular,
and
I
found
this
really
interesting,
tweet
by
by
aaron
gupta.
The
other
day
who
said
like
everybody
doing
kubernetes
seems
to
be
not
happy
with
it,
but
everybody
is
not
doing.
Kubernetes
seems
to
be
craving
for
it,
I
mean,
I
don't
think
this
is
entirely
true.
A
I
know
a
lot
of
people
which
are
very
happy
using
kubernetes.
I
use
it
myself
a
lot
and
I'm
also
happy
with
it,
but
it
still
implicates
that
it
is
not
the
easiest
thing
in
the
world
and
there
is
especially
in
the
beginning,
quite
a
steep
learning
curve
in
order
to
get
there.
We
also
see
that,
from
our
consultant
perspective,
we
are
also
teaching
kubernetes
classes,
and
so
we
we
have
a
bit
of
an
idea.
A
What
how
easy
it
is,
especially
for
the
first
steps
now
before
I
want
to
go
into
the
different
platform
technologies.
I
first
of
all
want
to
kind
of
give
an
idea.
So
what
what
do
I
understand?
If
I
talk
about
the
term
platform?
What
do
I
mean
with
that?
What
are
the
roles
of
people
that
interact
with
such
a
platform
thing,
which
are
the
parts
that
should
be
in
or
excluded
whatsoever?
A
Normally
you
have
back-end
systems
like
databases,
messaging
system
or
other
legacy
types
which
can
be
connected
to
by
some
kind
of
like
configuration,
either
secrets
or
connection
strings
or
whatsoever,
and
normally
those
two
things
are
going
to
be
baked
into
a
container
which
the
platform
will
then
operate,
run
scale
or
do
whatever
the
platform
thinks
is
right
for
them
now.
This
is
basically
the
boundary
where
we
can
draw
the
platform,
and
we
already
have
identified
two
rows
to
that
now.
There's
another
role,
which
is
like
the
administrator
of
all
that.
A
So,
if
you
buy
such
a
platform,
let's
say
from
amazon
or
azure
whatsoever,
you
basically
consume
this
as
a
managed
service
and
this
kind
of
platform
admin
goes
away
a
little
bit.
Nevertheless,
you
might
want
to
have
somebody
to
look
after
that
if
everything
is
still
stable
and
if
the
managed
service
works
as
as
desired.
A
In
addition
to
that,
there
is
another
role
which
is
normally
not
really
visible
straight
away,
which
is,
I
just
called
it
provider,
because
I
just
didn't:
couldn't
figure
out
a
better
name,
this
one.
Normally
they
come
into
play
if
things
don't
go
right.
So
if
your
application
suddenly
exposes
security
vulnerabilities
in
production
and
you
need
to
patch
things-
and
you
need
to
figure
out
where
things
go
wrong,
is
it
somewhere
in
a
deeper
layer
of
the
container?
Is
it
somewhere
in
the
application
whose
responsibility
is
it?
A
Who
is
going
to
patch
it
and
all
the
times
if
it's
outside
of
the
source
code
part?
So
somebody
has
to
be
responsible
and
take
care
of
that.
So
not
all
the
time.
Those
four
roles
are
separated
into
four
different
groups
of
people,
but
you
always
have
those
four
roles,
at
least
even
if
you
don't
know
that
you
have
them
or
even
if
they,
if
they
exist
in
in
a
single
person.
So
these
are
the
things
that
you
basically
need
to
have
in
order
to
operate
modern
software.
A
Now
we
could
say
that
looking
it
from
from
a
different
angle,
like
I'm,
not
sure
how
familiar
if
you
are
with
a
day,
0
to
day
3
operations
terminology.
But
if
you
say
on
day,
0
is
basically
where
you
build
your
software.
You
design
your
architect
to
build
your
software
up
to
a
point
where
it
goes
into
the
code
ripple
and
on
day
one
you
do
all
the
building
containerizing
up
to
like
the
deployment
onto
the
platform
and
on
day
two.
A
Now.
Another
way
to
look
at
at
platforms
is
about
what
kind
of
workloads
do
they
run
and
which
kind
of
workloads
are
they
capable
of
running?
So
today
we're
going
to
look
into
that
the
support
between
container
and
functions,
and
then
you
can
say
which
kind
of
abstraction
layer
is
suitable
for
which
kind
of
platform
type.
So
this
is
also
a
differentiation
which
you
might
might
make
and
say.
These
are
the
things
that
I
want
to
run.
So
this
is
the
right
platform
for
me
to
take
all
right.
A
So
you
could
sum
things
up
and
say:
the
platform
takes
a
lot
of
things
away
from
you
and
makes
it
easier
for
you
to
do
the
right
thing
good.
So
before
I
start
diving
into
kubernetes,
because
now
I'm
going
to
like
look
into
the
platforms
themselves,
I
want
to
just
ask:
are
there
any
any
questions
up
so
far.
A
Not
not
hearing
anything
okay,
so
I'm
gonna
continue
with
this
and
talk
about
kubernetes,
as
this
seems
to
be
the
the
one
that
the
platform
that
everybody
wants
and
it
has
the
the
the
most
search
terms
in
google,
the
highest
adoption
and
so
on.
So
as
this
is
the
the
cncf
meetup
in
berlin,
I
would
expect
a
lot
of
people
to
know
things
about
kubernetes,
so
I
would
probably
rather
go
to
this
quicker.
A
A
That
also
means
it
basically
spawned
an
entire
ecosystem
of
technologies
which
which
are
now
home
in
the
in
the
cloud
native
community
foundation,
landscape.
Where
kubernetes
is
it's,
it
itself
is
the
major
or
the
main
project.
Now
again,
I
want
to
look
at
at
things
from
a
development
perspective.
So
what
would
a
developer
have
to
do
in
order
to
deploy
things
onto
two
kubernetes?
A
A
So,
first
of
all,
you
will
have
to
do
some
kind
of
container
image
building
process.
So
you
need
a
base
container
image.
You
need
some
certain
runtime,
depending
what
language
or
framework
your
application
is
being
written
in
and
then
basically
put
your
application
on
top
and
wrap
this
all
up
into
an
immutable
image.
A
This
image
will
then
go
into
a
container
registry.
So
now
I've
already
went
through
the
first
slide
without
ever
mentioning
kubernetes.
So
the
reason
why
I
do
that
it's
just
because
these
are
tasks
that
everybody
has
to
do
and
you
need
to
standardize
and
bring
them
into
a
proper
shape
for
continuous
deployment
in
an
enterprise
world.
Now.
A
Can
start
thinking
about
kubernetes
in
itself,
so
cube,
ctl,
create
or
other
things.
What
we
might
see
later
would
be
a
way
to
start
running
your
workload
in
kubernetes,
so
kubernetes
will
reference
that
image
from
your
repository
build
a
so-called
pod,
which
is
the
most
like
basic
unit
of
a
kubernetes
workload.
A
Artifact
a
pod
can
host
one
to
many
containers
for,
for
the
sake
of
simplicity,
I
will
consider
for
today
that
a
pot
equals
to
one
container,
at
least
for
application
workloads,
and
so
once
you
want
to
scale
those
you
need
a
so-called
replica
set,
as
the
name
implies
it
takes
care
about.
The
replicas
are
basically
the
amount
of
pods
that
you're
currently
running
the
top
level
object
in
this
hierarchy
is
the
so-called
deployment.
A
The
deployment
in
turn
manages
the
replica
set
and
is
responsible
for
updating
the
replica
sets
in
case
there
have
been
any
configuration
changes
or
there
was
a
new
image
of
the
application,
basically
a
new
version
that
you
want
to
deploy
to
expose
all
that
to
an
end
user.
You
have
a
service
endpoint,
which
will
then
make
your
deployment
accessible
either
inside
of
the
cluster
or
outside
to
the
public.
An
ingress
is
another
object
or
an
artifact
to
achieve
that
goal.
A
B
A
I'm
going
to
to
jump
into
to
the
codes
so
not
sure
how
familiar
you
are
with
java
or
not.
It's.
I'm
gonna
have
a
very,
very
easy
code
snippet
here,
so
the
only
thing
you
need
to
understand
basically
is.
I
have
two
rest
end
points.
One
is
called
hello.
Another
one
is
called
fail.
Hello
will
just
basically
return
the
instance
id
of
the
container
and
say
hello,
berlin
and
the
other
one
will
basically
cause
the
container
to
crash
so
fairly
simple.
This
is
basically
the
main
logic
of
my
application
now,
basically
to.
A
To
build
that
application
in
java
there's
a
building
mechanism
called
maven,
so
this
is
basically
the
first
step
in
the
chain
that
I
need
to
do
so.
I
have
to
package
my
application
from
a
source
file
into
a
jar
file
which
doesn't
take
super
long.
After
that
I
have
to
put
this
into
a
container.
I
have
built
a
docker
file
to
do
that.
A
A
A
While
the
other
one
is
still
pushing
pushing
the
code
so
once
this
is
all
away
now,
this
good
timing,
so
we
have
basically
a
totally
naked
kubernetes
cluster
here
and
now,
I'm
at
the
point
where
I
can
say
I
want
to
to
create
a
kubernetes
deployment,
so
I
used
the
the
in
the
slides.
I
used
the
call
create
deployment
and
I
call
it
simple
web.
I
take
the
image
that
I
had
just
pushed,
which
you
can
see
here
and
I
can.
A
A
A
Once
it's
on
the
platform,
I
can
do
a
couple
of
things
with
it,
so
I
can.
First
of
all
I
need
to
create
that
service,
which
I
said
before
I'm
gonna
call
this
service
also
simple
web.
This
is
a
type
load
balancer
and
I
export
port
8080,
because
I
know
that
is
the
port.
Where
my
application
is
listening
on
now,
you
can
see
that
service
is
being
created,
it
doesn't
have
an
external
ip.
Yet
that
is
because
I'm
running
my
cluster
on
microsoft,
azure
and
it's
like
a
public
cloud
provider.
A
A
A
A
So
this
basically
pings
the
application
continuously
now
and
if
I
want
to
see
how
it
reacts
on
that
failure,
so
I
can
also
curl
that
end
point
with
fail,
and
in
this
case
I
can
quickly
see
the
connection
has
refused
the
application
has
crashed
over
here.
I
should
basically
see
it
very
soon
going
into
an
arrow
state.
A
So
even
if
I
had
to
have
a
severe
crash
in
my
application,
I
can
rely
on
the
fact
that
that
it
will
actually
recover,
and
the
other
thing
I
wanted
to
show
is
basically,
I
want
to
scale
my
deployment
so
now
I'm
getting
two
new
containers
here
and
they
go
into
running
mode
very
quickly,
and
now
you
can
also
see.
I
had
one
outage
here,
just
in
the
in
the
in
the
scaling
process,
but
I
have
different
ids
in
at
the
end
here.
A
So
that
means
kubernetes
is
automatically
load
balancing
between
the
three
instances
that
I
have
here
and
if
I
like
fail
another
instance
now
that
one
can
be
excluded
by
kubernetes
automatically,
we
still
see
a
couple
of
outages
here.
The
reason
for
that
is
also
very
important
to
understand.
In
that
context,
kubernetes
only
know
the
way
I
built
the
container.
I
didn't
tell
kubernetes
what
is
inside
of
the
container,
so
kubernetes
only
knows
about
the
container,
and
once
the
container
is
started,
it
will
assume
the
application
was
started
as
well.
A
A
A
A
That
I
should
probably
see
check
it
out
right
so
that
the
application
switched
from
version
one
to
version
two,
so
it
started
a
a
new,
a
new
version
of
that
application
and
and
the
the
takeover
was
basically
just
like
from
one
call
to
the
other.
In
the
end,
the
end
user
wouldn't
really
see
that
there's
a
version
two
of
the
application
here,
the
the
call
would
just
continue-
and
I
can
also
see
that
I
have
a
new
idea
of
the
replica
set
here.
So
for
some.
A
A
A
So
this
is
already
very
helpful
for
me
and
probably
a
reason
why
a
lot
of
people
use
it
now,
switching
over
to
cloud
foundry,
which
comes
more
under
the
umbrella
of
like
platform
as
a
service,
which
is,
I
always
find
it
very
helpful,
describe
it
this
way
here
is
my
source
code
running
on
the
cloud
for
me.
I
do
not
care
how
so
the
idea
is
really
full.
Development
focus
just
give
a
platform,
the
development
which
is
easy
to
consume
and
which
avoids
all
unnecessary
overhead.
A
A
Now,
looking
into
this,
I'm
gonna
switch
my
screen
here
and
I
am
logged
in.
I
hope
this
is
all
big
enough,
otherwise
feel
free.
To
tell
me
I'm
connected
to
a
cloud
foundry
instance,
which
is
in
turn
also
running
on
a
kubernetes
environment
so
over
here,
or
we
can
also
do
that
here
and
say
the
namespaces
that
I
have
here.
So
I
have
my
typical
kubernetes
namespaces,
and
this
is
the
namespace,
and
I
also
have
these
cloud
foundry
names
spaces.
A
So
this
is
done,
and
now
I
don't
need
to
build
a
container.
The
only
thing
and
basically
to
say,
is,
as
I
said,
cf
push,
this
command
will
now
say.
Okay,
I
have
found
a
this
jar
file
which
just
has
been
built
and
on
the,
why
it
says
staging
app
and
tracing
logs.
A
couple
of
things
are
going
to
happening
over
here.
A
A
Yeah
so
there's
a
new
part,
starting
called
simple
web
dev,
it's
initializing
and
now
going
into
running
state.
Also
over
here
it
says
my
application
is
now
running.
So
if
I
do
cf
apps
now,
I
automatically
get
a
route
out
on
the
on
the
internet,
where
I
don't
have
to
expose
it
as
a
service
or
route
by
myself.
A
A
So
this
is
basically
pinging
the
application
here
too.
What
else
can
I
do?
If
I
do
the
same
girl
called
to
like
that?
Failing
end
point
same
thing
happens,
the
the
pod
is
gonna
crash.
We
will
be
able
to
see
that
over
here
I
mean
the
important
thing
to
say
here
is
everything
is
on
the
left
hand.
Side
is
basically
the
developer
and
consumer
view
and
everything
on
the
right
hand,
side
is
the
the
operator
and
under
the
umbrella
I
like
under
the
under
the
hood
view,
so
to
say
so
in
a
similar
style.
A
The
application
is
coming
back
and
and
is
ready
to
continue
in.
I
have
also
there's
also
a
scaling
command,
where
I
can
say
scale
the
application
up
to
three
instances.
That
will
then
mean
we
get
a
cup
not
a
few
more
parts
to
to
be
initialized
and
once
they
also
enter
the
state
of
running.
We
will
see
here.
You
see
that
little
index
at
the
end.
It
says
two
here.
A
So,
basically,
from
a
technology
perspective,
the
behavior
of
the
app
remains
the
same.
However,
the
the
user
interaction
changes
significantly
because
now,
I
can
just
say,
blue
green
blue
green,
deploy,
simple
web.
That
will
basically
push
a
new
version
of
that
image,
so
it's
gonna
create
and
you
can.
A
It's
gonna
create
a
new
container
with
the
new
jar
file
that
I
have
just
built
and
and
then
run
it
now,
I'm
running
out
of
time,
as
I
can
see
here,
so
I'm
gonna
switch
over
to
to
the
creative
section
soon.
So
what
we
saw
here
is,
as
the
cloud
found
responsibility,
extends
somewhat
to
the
left
and
goes
basically
into
the
build
packaging
part
and
containerizing
part.
There
is
less
responsibility
for
for
people
here
and
more
capacity
to
spend
here
on
day
zero
activities
actually
with
the
next
version.
A
A
So
this
one
I'm
gonna,
fly
through
real
quickly.
I
mean
in
the
end.
This
is
probably
the
important
picture
here,
so
you
you
can
see
if
push
and
you
can
keep
cl
ctl
create
to
the
same
kubernetes
cluster.
You
can
use
both
apis
or
you
could
also
say,
I'm
going
to
use
cf
push
for
deploying
my
my
my
own
applications,
but
I
use
helm
charts,
for
example,
to
deploy,
deploy.
Other
standardized
containers
that
I
already
have
and
both
will
work
seamlessly
together
for
an
an
integrated
user
experience
there.
A
A
This
one
didn't
have
a
life
prior
to
kubernetes
that
this
was
basically
born
as
a
as
a
kubernetes
native
project.
It
required
either
istio
or
other
service
meshes
beneath
and
it
comes
with,
let's
say
two
and
a
half
components
so
serving
is
like
the
main
component
that
we're
going
to
have
a
look
at
here.
Eventing
is
a
component
that,
as
the
name
says,
focuses
on
event
driven
and
like
message
message:
driven
infrastructures
or
like
application
infrastructures,
while
techton
is
like
a
pipeline
solution
that
wraps
up
the
entire
platform
scope.
A
So
this
one
I'm
going
to
focus
on
the
serving
part
today
as
the
other
ones,
which
just
like
be
too
time
consuming
to
to
deal
with
again
same
as
kubernetes.
Is
you
need
to
build
a
container
image
here?
First,
so
you
can't
push
code,
you
can
do
application
con
application
containers
and
then
run
them.
However,
as
you
can
see
here,
the
the
use
of
interface
is
fairly
friendly.
A
It's
just
a
few
different
artifacts
different
names.
You
need
to
learn,
but
all
of
those
things
happen
automatically
one
of
the
cool
things
is.
You
can
have
multiple
revisions
of
your
application
at
the
same
time
and
you
can
configure
the
routing
on
a
percentage
basis.
So
you
can
say
I
want
to
deploy
something
new,
but
I
want
to
only
give
it
five
percent
of
the
traffic
and
I'm
going
to
increase
that
once
there
is
more,
which
is
a
very
cool
feature.
Also,
it
listens
on
the
traffic
to
adapt
to
the
scaling.
A
So
from
a
concept
perspective.
We
have
routes,
services,
revisions
and
images
here.
So
also.
This
is
much
closer
to
an
to
an
application,
focused
view.
Now,
I'm
I'm
going
to
reuse
the
containers
that
I
had
initially
built.
So
I'm
going
to
switch
to
my
cooper,
my
k
native
cluster.
I
have
a
couple
of
I
mean
technically
you
could
run
them
all
in
one
cluster.
I've
done
it
before,
but
I've
also
made
the
experience
that
one
can
also
affect
the
others.
A
A
A
A
So
yeah
this
one
took
the
right
container.
I
don't,
I
still
don't
know
what
happened
to
the
other
ones
that
I
pushed
earlier
out
now.
This
one
does
the
same
thing,
so
I'm
not
gonna
show
you
all
the
failure
and
recovery
thing.
I'm
going
to
show
you
a
couple
of
other
things
that
are
specific
to
k
native,
so
I'm
going
to
update
the
service
and
I'm
going
to
switch
this
so
concurrency
limit
that
basically,
a
single
service
is
only
capable
of
handling
one
request
at
the
time.
A
The
reason
why
I
want
to
do
this
is
I
want
to
try
to
flood
it
with
a
lot
of
services
and
I'm
gonna
say
I'm
gonna
fire.
A
hundred
requests
onto
that
now
and
just
basically
see
how
it
reacts
on
that.
So
you
can
see
here
automatically
many
many
new
parts
are
gonna
getting
created,
so
the
the
traffic
on
the
wire
will
immediately
say:
okay,
there's
something
to
do.
Please
please
catch
that
and
be
prepared
for
that.
A
However,
if
the
traffic
goes
back,
it
will
take
all
the
containers
out
all
the
ports
out
again.
Actually,
it
will
even
go
down
to
ace
to
single
instances
like
a
scale
to
zero
behavior
if
there
is
no
load
on
the
container.
So
this
is
what
I
would
call
like:
serverless
behavior,
so
you
don't
need
to
worry
about
the
infrastructure.
The
infrastructure
takes
care
about
that.
It's
about
itself
and
another
cool
feature.
A
A
A
Maybe
I'm
not
so
super
confident
about
that
version,
and
I
want
to
say
I
don't
want
to
do
all
the
traffic
onto
that
one.
Let's
say
I
want
to
give
this
one:
only
10
percent
and
90
percent.
I
want
to
give
to
the
traffic,
which
was
instance
2,
which
was
called.
Oh.
I
typed
that
right
g
k
on
the
c
e.
This
is
not
the
most
elegant
way
to
do
that.
A
We
had
zero
instances
of
that
second
deployment
because
it
was
inactive
for
a
while.
Hence
it
doesn't
respond.
It
needs
to
restart
the
container
and
now
it
works.
So
this
is
the
previous
version,
and
now
every
10th
call
or
so
whatsoever.
It
should
come
up
with
version.
Three
which
hit
now-
and
it
was
just
instead
of
terminating
and
now
it's
going
to
come
back
with
also
two
instances.
So
once
this
level
is
reached,
okay,
we
have
two
overlapping
demo
versions.
Now
we
have
berlin
and
reutlingen.
A
A
Good
so
again,
here
we
have
the
same
the
same
diagram
as
we
had
in
kubernetes
before.
However,
the
day
two
power
of
canadian
is
is
is
much
much
stronger
than
what
what
plane
communities
would
give
you,
and
so
this
would
basically
bring
things
to
a
certain
conclusion.
So
with
kubernetes,
we
have
the
technical
capabilities
of
such
a
modern
container
platform.
It
can
recover,
it
can
scale
it
can
fail,
it
can
bring
things
back
and
and
do
be,
very
provide
lots
of
high
availability
and
robustness
to
your
application.
A
Cloud
foundry,
on
the
one
hand,
would
bring
easy
developer
experience
to
kubernetes
and
basically
take
the
container
handling
out
entirely
where,
whereas
canadian
would
bring
scale
0
revisions
and
percentage
routing.
Of
course,
an
ideal
world
would
have
be
like
k
native
and
the
cloud
foundry
combined.
Maybe
we're
going
to
get
there
eventually,
but
it's
already
good
to
see
those
options
are
out
now
and
I'm
gonna
skip
this
one.
The
only
thing
I
would
encourage
people
to
do
really
is
there
are
a
lot
of
kubernetes
offerings.
A
A
lot
of
free
offerings
that
are
free
trials,
basically
get
yourself
either
a
local
or
a
public
kubernetes
cluster
and
try
those
things
out.
There
are
brilliant
tutorials
from
red,
ted
suicide
and
wayne
vmware,
and
many
more
if
you
can't
find
them
I'll,
be
happy
to
point
them
out
to
you
to
run
those
platforms
on
top
of
kubernetes
and
improve
your
your
kubernetes
experience
with
that.
I'm
kind
of
coming
to
an
end
here
and
first
of
all
I
want
to
thank
you
say
thank
you
for
listening.
A
B
B
Thank
you
for
your
talk
was
very
interesting.
I
have
a
question
regarding
k,
native
and
easter
eu,
so
we
can
have
history
also
on
the
plane,
kubernetes
cluster.
So
what
is
the
advantage?
I
understand
is
all
integrate
with
k
native,
but
I
can
do
the
same
with
the
stereo.
What
you
show
me
with
a
plain
kubernetes
cluster.
A
Well,
I
mean
istio
provides
the
the
fundamental
things
to
I
mean.
Let's
say
the
way.
I
understand
it
that
those
service
measures,
be
it
istio
or
others.
They
inject
those
those
sidecar
proxies
into
the
into
the
pots,
and
then
we
are
able
to
listen
to
the
traffic
flow
and
control
that
flow
inside
of
the
cluster
k
native
exploits
that.
So
I
wasn't
aware
that,
with
plain
istio,
you
could
easily
trigger
an
application
to
auto
scale
down
to
zero
or
to
to
to
scale
up
directly
on
on
on
demand.
A
I
mean
you
can
configure
it
that
way,
but
the
way
what
I
found
is
that
the
k
native
api
is
much
more
user-friendly.
To
achieve
that,
I
mean
I
haven't
worked
with
plain
istio
in
a
while.
To
be
honest,
so
maybe
what
I'm
saying
here
is
not
entirely
true,
but
k.
Native
from
what
I
found
is,
is
focusing
more
on
an
application
or
functions
perspective.
I
mean
it.
A
It
provides
an
a
platform
for
deploying
applications
which
are
meant
to
to
start
up
fast
because
we
solve
the
scale
down
to
zero
and
once
they
get
traffic
they
need
to
restart
and
come
back
real,
quick.
So
like
a
three
minute
application
server
startup
time
is
totally
not
acceptable
there
and
is
still
I
mean
if
you
look
at
sorry.
This
was
the
wrong
window.
A
A
B
A
So
these
are
sorry
I
mean
it
is
a
little
smaller.
I
mean.
Basically,
one
of
the
important
features,
of
course,
is
the
is
the
ingress
because
it
for
for
the
routing
to
the
traffic
and
the
automatic
route
generation.
This
is
also
something
which
you
wouldn't
get
from
kubernetes
straight
away,
other
than
that
it
will
collect
the
the
the
metrics
for
our
prometheus
and
then
having
that
consumed
through
through
through
k
natives.
A
So
if
I
do
the
same
thing
for
k
native
serving
you
would
all
see,
there
isn't
really
much.
So
you
have
things
like
the
two
two
components,
interfering
directly
with
istio
and
then
other
ones
for
activating
the
the
the
applications
for
auto
scaling.
So
I
think
I
don't
know
the
exact
numbers,
but
from
an
overhead
perspective
the
the
installation
isn't
higher
than
than
istio
itself.
A
So
I
mean
it's
again:
it's
only
I'm
just
trying
to
show
options
here
I
mean
if
you
use,
kubernetes
have
istio
on
top
and
it
gives
you
all
you
need.
Then
it's
absolutely
fine.
I
found
istio
on
its
own,
not
so
super
intuitive.
When
I
used
it
first
time,
I
use
it
a
lot
for
like
visualizing
things
via
chiali,
but
I
didn't
really
exploit
istio
other
than
that
a
lot
by
myself,
but
I
might
do
istio
injustice
here.
So
apologies
for
that.
I
just
know.
B
A
Yes,
I
mean
you
would
have
to
install
if
you,
if
you
look
on
the
docks,
it
will
tell
you
to
install
istio
first
or
use
another.
I
think
it
works
with
with
with
linkedin
too,
but
it
requires
a
bit
of
different
configuration
but
yeah
this
that's
what
I
said
when
I
said
here
this
there's,
this
red
hat
provides
some
excellent
and
easygoing
tutorials
or
like
the
basically,
the
canadian
home
page
will
get
you
started.