►
From YouTube: Panel: Knative, Kubernetes & Istio: A New Cloud Stack? OpenShift Commons Gathering Seattle 2018
Description
Panel: Knative, Kubernetes & Istio: A New Cloud Stack? Moderated by William Markito Oliveira, Red Hat | Mark Chmarny, Google | Paul Morie, Red Hat | Klaus Deissner, SAP | Idit Levine - Solo.io | Doug Davis, IBM
at OpenShift Commons Gathering Seattle 2018 https://commons.openshift.org/gatherings/Seattle_2018.html
A
B
D
So
my
name
is
ed:
Levine
I'm,
the
founder
of
the
CEO
of
company
coastal
I
own,
a
small
company
we
just
launched
today.
So
it's
a
special
day
for
us.
What
we
doing
so
so
we've
been
playing
a
lot
of
trying
to
bring
everything
that
related
to
several
s
and
micro
services
to
get
it
in
your
legacy,
application
so
kind
of
like
glue
them
together.
So
yeah.
That's
what
we're
doing
so
we're
working
a
lot
with
several
s.
The
kinder
cloud,
K
native
everything
that
is
Doug.
E
F
A
Right
great
so
I'll
start
by
asking
I
would
say
the
the
most
important
question:
I
think,
which
is
so
kubernetes,
east
EO
and
k
native
or
or
kick.
Is
it
the
new
cloud
stack
or
is
it
a
yak
and
we're
just
yet
another
cloud
stack
and
we
are
here
just
shaping
yaks
again.
So,
let's
start
with
that.
First
got
the
mic:
I'm
gonna
start
video.
For
now.
C
Well,
I
think
if
anybody
knew
the
answer
to
that
question,
we
probably
wouldn't
necessarily
need
to
have
the
panel
right
for
one
reason
or
another,
I
tend
to
think
of
these
things
like
the
the
great
adage.
If
you
build
it,
they
will
come
so,
for
example,
back
when
the
the
concept
of
easily
extending
kubernetes
with
new
API.
C
It
was
like
a
glimmer
and
a
couple
folks
eyes:
I,
don't
think
anybody
could
anticipate
the
extent
to
which
custom
resource
definitions
and
all
of
the
attached
concepts
like
operators,
kubernetes
native
applications
etc
would
affect
our
ecosystem
and
community
in
the
way
that
they
have
so
we
we
won't
know
unless
we
continue
to
build
it,
and
since
we
will
build
it,
we
want
it
to
be
the
best
thing
that
it
can
be,
but
I
personally
think
there's
a
huge
amount
of
potential
to
affect
things
in
a
very
significant
way.
Just
my
two
cents.
F
D
So
we're
not
going
to
what
stack
right.
So,
let's
kind
of
like
separate
the
stack,
the
first
one
is
kubernetes.
I
think
this
is
ends
down.
There
is
arena
right,
it's
kubernetes!
We
all
agree
about
it.
There's
no
question
about
that
anymore.
So
now
we're
talking
about
SEO
and
SEO
is
interesting.
So
what
we
do
know
is
that
service
mesh
is
here
to
stay.
That's
something
that
we
definitely
know
is.
They
still
will
be
the
winner.
It's
a
good
question!
D
Well
right
now
there
is
a
lot
of
people
that
you
know
a
lot
of
new
services.
Software
out
there
right
up
match
was
for
many
WS
last
week.
So
if
you're
running
on
AWS,
it's
free
you're,
most
likely,
we
want
to
run
use
that
right,
so
you're
not
you're,
going
to
use
STL.
There
is
stuff
like
console
connect
in
their
own
firm.
That
could
be
interesting,
so
I
think
there
is
no
definition.
This
is
worse.
That's
why
we
actually
created
superglue
recently,
which
is
exactly
that
is
an
abstraction
layer,
fold
the
service
mesh.
Okay.
D
So
that's
that
now
we're
talking
about
kna.
So
that's
even
more
interesting
because
several
Isis
even
make
sense
on
Prem.
That's
a
good
question
right
I
mean
it's
definitely
makes
sense
for
the
cloud
and
the
reason
it
is
is
because
you
know
it's
work
much
better
on
rent
when
you're
renting
stuff
you're
paying
for
me
what
you
using
the
question
if
it
makes
its
own
form
and
that's
a
good
question,
but
what
I
do
like
about
service
from
a
creative
is
the
packaging
right?
It's
the
past
experience
and
I
think
that's
here
to
stay
so.
E
Actually
she's,
so
my
Thunder
I
agree.
I.
Think
kubernetes
is
the
de
facto
sort
of
standard
everybody's
using
that's
great
until
the
next
big
thing
comes
along
is
geo
is
interesting,
but
it's
it's
more
for
the
the
ops
guide.
You
can
understand,
wrap
their
head
around.
It's
just
it's
more
complicated.
E
How
does
it
interact
with
the
routing
that's
native
inside
kubernetes
already
but
k
native
is
where
I'm
more
excited
by,
because
that
hits
the
end
user
and
that's
where
you
I'm
wanting
what
the
end
users
to
actually
live,
not
with
the
rest
of
the
stuff
and
so
I
think
you
had
the
two
extremes
of
the
most
important
interest
to
me.
The
core
infrastructure
in
which
were
building
on
kubernetes
and
then
the
user
experience
which
is
Kay
native
is
geo
cool
technology
and
great
functionality,
but
I'm
more
interesting
out.
Un's
yeah.
A
D
B
D
Other
one
is
routing
again:
we
probably
need
to
route
your
functions
specifically
for
when
I
run
between
micro
service
and
sterilized
or
something
like
that's
kind
of
like
an
organic
environment
and
the
last
one
is,
is
security
again,
I
think
it's
no-brainer
one.
We
need
that
so
for
most
of
that
reason,
I
mean
it
just
make
a
lot
of
sense.
Okay,.
F
Gonna
say
to
bring
kit,
maybe
make
it
a
little
more
real,
because
I
think
those
three
categories
are
exactly
spot-on,
but
you
know
if
anybody
has
ever
written
more
than
you
know,
5
to
10
micro
services.
You
quickly
realize
that
the
problems
you've
had
with
2
or
3
was
probably
not
something
you
were
worried
about.
Suddenly
you
have
things
that
are
connecting
to
each
other
and
getting
calls
from
outside
logging
to
places.
B
E
For
me
at
all,
but
the
abstraction
and
all
the
categories
you
laid
out
are
exactly
right,
and
people
have
been
doing
that
for
a
long
time,
but
the
problems
they
had
to
do
it
themselves.
If
we
can
do
that
for
them
and
then
expose
it
in
a
really
cool
way
through
something
like
a
native,
so
they
don't
have
to
see
all
the
guts
and
glory
unless
they
really
need
to
that's
where
I
think
the
end
goal
is
have
the
service
mesh,
but
exposing
a
user
friendly
way.
Yeah.
This.
C
Is
actually
I
think
we're
touching
on
one
of
the
most
salient
parts
of
the
value
proposition
and
Kay
native,
which
is
that
the
the
end
goal
is
that
you
get
to
focus
on
the
things
that
are
important
to
you
and
focus
on
your
value-add
without
having
to
become
an
expert
in
the
underlying
technology
is
necessarily
so
for
me.
I
will
just
full
disclosure
I'm,
not
an
SEO
expert,
but
I've
been
able
to
get
K
native
to
do
things
for
me,
with
ISTE
o
and
in
doing
so.
C
I
actually
didn't
have
to
learn
a
whole
lot
about
sto
and
was
able
to
leverage
it.
That's
the
kind
of
like
force
multiplication
effect
that
I
think
is
really
key
to
the
value
that
K
native
provides
that
you
can
stand
on
the
shoulders
of
people
who
I
can't
speak
for
anybody
else,
but
are
definitely
smarter
than
me
that
have
figured
out
how
to
make
these
things
work
together
and
harness
it
without
doing
the
work
yourself.
A
D
Okay,
so,
let's
see
so
I
think
that
usually
the
computer
is
not
really
interesting
right.
Why
are
you
running
function?
It
doesn't
matter,
let's
run
it
somewhere
else.
So
that's
not
where
the
problem
real
problem
is
the
data,
and
today
is
there
right.
There
is
nothing
we
can
do
so.
So
that's
the
real
problem
that
we
need
to
solving
in
terms
of
an
inventory,
locking.
D
The
only
thing
that
I
will
say
is
that
with
the
new
you
know,
buzzword
multi-cloud,
when
everybody
talking
about
it,
I
think
that
it
could
help,
because
theoretically,
but
it
could
cause-
is
that
let's
say
that
all
my
storage
right
now
is
in
AWS.
The
only
thing
that
I
need
is
to
run
one
little
function
whenever
I
need
this
data,
but
all
the
rest
of
my
workload
can
run
all
over
the
cloud.
E
So,
obviously,
being
part
of
that
cloud
working
group
out
of
these
standards
and
cloud
events
is
porn
to
us
from
an
interval
Billy
perspective.
Obviously
everybody
wants
in
our
bill
the
portability
of
stuff,
but
I
think
you
have
to
put
it
in
context
right.
It's
not
a
showstopper
for
most
people,
it's
a
it's
a
pain
in
the
butt,
it's
a
hindrance
to
port
your
stuff
over
to
their
platform,
but
most
people
aren't
going
to
be
moving
there,
their
plot
their
workloads
to
divert
platforms
every
other
day
right.
E
It's
not
the
kind
of
thing
you
do,
because
it's
it's
the
function
of
signatures,
or
whatever
are
just
one
part
of
the
entire
equation.
It's
the
functionality
through
performance.
Everything
else
is
good.
There
are
lots
of
other
things
to
lock
you
in
and
enter
our
ability,
and
portability
is
one
of
them,
so
you
seem
to
put
it
in
the
context
with
everything
else.
So
in
our
bill
is
important,
but
do
it
at
the
right
time
at
the
right
scale
and
at
the
right
spots.
E
F
Nobody
said
it
so
I'm,
gonna,
say
I.
Think
developers
want
to
write
applications,
don't
strive
for
writing
for
the
minimum
amount
of
people
right,
everybody
who
ever
wrote
an
application
wants
to
write
for
the
largest
amount
audience
that
it's
possible,
so
the
Utopia
of
a
portable
workload
that
just
magically
works
on
every
single
cloud
is
something
that
we
strive
for.
F
Obviously
it's
not
reality
today,
so
I
think
it's
probably
important
to
break
that
that
kind
of
fear
of
locking
into
smaller
chunks
and
kind
of
understand
what
does
it
mean
with
regards
to
the
actual
runtime
definition
and
enabling
at
least
the
application
to
be
portable?
What
does
it
mean
with
regards
to
a
control?
Plane
were
the
way
we
interact
with
the
api's
and
the
the
runtime
application,
so
in
principle,
locking-
probably
not
something
we
strive
for
it
when
nobody
wants
that,
but
I
think
the
problem
is
probably
more
nuanced
than
just
saying
it's.
A
Right
so
diving
more
into
that,
because
we
we
are
talking
a
lot
about
hybrid,
hybrid
cloud
and
hybrid
servicenow,
and
it's
specific
about
servlet
I
would
say
in
function
as
a
service.
We
are
starting
to
see
more
and
more
moving
to
the
edge
on
pram
on
multi
clouds,
so
hybrid
servlet
like
that,
is
that
real,
or
are
we
coming
up
with
this?
Yet
another
buzzword
like?
Is
that
our
real
need
that
you
already
see
in
the
market
or
from
customers
to
do
hybrid
servers?
And
can
you
talk
more
about
that
I
I.
C
Have
a
strong
gut
feeling
that
hybrid
service
is
a
real
thing,
so
I
mean
in
going
back
to
the
last
beat
of
this
panel.
Doug
I
think
you
made
the
point
that,
like
there
is,
that
lakhan
is
only
a
problem
when
you
want
to
move
right
and
there
I
think
there
are
a
cluster
of
use
cases
that
speak
to
that.
But
then
there
are
also
reasons
that
people
seek
diversity
in
their
cloud
platforms.
So,
for
example,
you
wouldn't
really
want
to
have
a
single
cloud
providers.
C
Low
level
bug,
knock
your
entire
production
snacking
out,
not
that
that
would
ever
happen,
but
theoretically
right.
So
there
are
four
for
folks
that
want
to
do
that
kind
of
planning
and
risk
mitigation.
There's
a
strong
use
case
for
distributing
functions
or
any
other
kubernetes
workload
to
multiple
clusters
that
may
run
in
different
cloud
providers
as
just
one
example
of
a
dimension
in
which
hybrid
service
could
be
a
real
thing.
Okay,.
F
Think
that's
where
the
ability
to
deliver
that
kind
of
developer
experience
kind
of
starts
getting
a
little
more
complex,
because
you
have
to
have
that
same
level
of
network
capability
of
storage,
elasticity
or
compute
on
demand,
as
well
as
a
number
of
other
orchestration
tools
that
are
delivering
the
very
same
experience.
Fortunately,
with
projects
like
kubernetes
like
easter,
like
a
native
that
surface,
is
becoming
much
smoother
and
and
starts
kind
of
hide
a
lot
of
that
underlining
differentiation
between
what
you
can
deliver
on
premise
versus
in
a
cloud.
F
It's
still
not
gonna,
go
to
the
store
and
I'm
gonna
buy
you
a
server
to
bring
it
into
your
into
your
data
center.
We're
still
working
on
that
one,
but
but
to
some
degree
the
developer
would
be
potentially
be
able
to
achieve
that
same
level
of
experience.
So
I
think
it's
very
much
possible.
It's
gonna
depend
on
our
ability
to
to
deliver
those
core
services
on
Prem
and
a
cloud
and
hopefully
enable
that
the
portability
of
workloads
that
it
won't
force
the
developer
to
be
concerned
about
whether
whether
they
deploy
on
or
in
a
cloud.
A
D
So
I
would
say
that
no,
you
know
explore
whatever
mean
okay
like
I,
don't
know
how
many
people
are
using.
Cyril
is
right
now
introduction
here,
not
that's
exactly
my
point
right.
The
people.
Actually,
you
know
we're
talking
about
I,
but
people
are
not
even
using
journalists.
There
is
going
to
use
you
ever
less
most
likely
in
the
cloud
which
probably
will
be
AWS
the
first
one
because
the
other
most
mature
and
that's
what
it
will
be
for
a
long
long
long
time
until
we
need
to
take
care
of
the
things.
A
A
D
We
tell
you
what
I
think,
maybe
it
will
happen
where
we
on
the
back.
What
you
need
to
know
right
now
is
this.
The
reason
people
will
go
to
use
AWS
is
because
it's
really
easy,
nothing's
easy.
You
know
what
it's
integrated
seamlessly
with
every
services
that
you
have
right
now.
You
can
see
one
place
of
all
the
logs
and
all
the
observability
I.
A
Kind
of
explain
you
on
that,
because
you
mention
application
and
I.
Think
mark
also
talked
about
service
and
again
more
in
a
more
broad
sense,
but
quite
often
at
least
when
I'm
talking
with
customers,
people
get
confused
about
function
as
a
service
and
service
may
be.
Can
the
panel
here
help
us
clarify
that
and
talk
a
little
bit
about
service
and
function
as
a
service,
the
differences
and
should
we
be
concerned
about
actually
breaking,
though,
that
that
difference
right,
yeah.
E
So
from
my
from
my
point
of
view
that
I
really
want
to
say
it
matter,
because
I
don't
care
about
the
buzzwords
I
tell
people
yeah
fine
talk
about
server.
Let's
talk
about
function,
so
you
understand
the
overall
concepts
in
general,
but
really
when
you
go
to
look
at
a
piece
of
technology
for
hosting
your
application,
look
at
the
functionality
right
if
it
makes
sense
to
break
up
and
tie
little
pieces,
so
they
easily
scale
functions
might
be
a
way
to
go.
Are
you
gonna
do
entire
application
of
the
function
as
it
right
now?
E
Probably
not
right.
Do
you
want
something
that
scales
down
to
zero?
Well,
then
you're
starting
getting
to
service
right
and
but
then
is
it
if
someone
says
oh
yeah
I
do
service
because
I
Scout
on
the
zero?
Well,
okay,
that's
fine,
but
what's
the
cost
for
Skinit
for
scaling
from
zero
to
one
right?
The
cost
is
ten
minutes.
E
Typically,
given
the
source
code,
they'll
host
it
for
you
and
then
server.
This
is
where
you
add
more
the
operational
aspect,
which
is
scaled
down
to
zero,
zero
cost
and
stuff
like
that.
But
they
are
so
closely
related.
I
try
to
get
hung
up
on
the
on
the
buzz
words
between
the
difference
between
those
two
buzz
words
mark.
F
Close
to
my
heart,
I
mean
to
large
degree
if
we
kind
of
talk
about
service
as
this
developer
experience
like
I
was
talking
before
about
hiding
the
underlying
infrastructure
ability
to
only
pay
for
what
you
actually
use.
Those
are
properties
that
are
not
unique
to
compute
or
function
or
application.
Those
are
properties
that
you
want
to
potentially
have
in
UML
platform
or
in
your
query,
or
a
sequel
platform
so
to
to
large
degree
in
my
strong
feeling
is
that
this
is
not
a
compute.
F
Only
problem
is
much
bigger
than
function
is
much
bigger
than
compute
and
and
applies
to
a
lot
of
different
disciplines
within
the
technology
within
function
itself.
I
think
we
have
some
established
notion
what
that
may
particularly
mean
because
of
dominance
of
one
one
Patinkin
particular
player
in
that
space,
but
I
think
developers
are
getting
smarter
every
day
and
they
expect
that
same
expect
experience
at
the
same
kind
of
capabilities
from
multiple
different
platforms,
including
now
Kay
native
there.
Hopefully
we
can
live
up
to
I.
C
Think
it's
important
to
differentiate
just
in
terms
of
expectation
management
where,
for
example,
if,
if
you
came
to
K
native-
and
you
were
looking
for
an
experience
similar
to
lambda,
you
wouldn't
get
that
yet
and
that's
really,
where
I
kind
of
draw
the
line
in
terms
of
I.
Think
of
the
function
as
a
service
as
being
an
experiential
thing,
primarily,
whereas
service
is
more
technology
patterns.
C
In
my
own
mind,
especially
focused
on
software
delivery,
and
you
service
is
a
necessary
but
insufficient
ingredient
to
get
to
faz,
where
you
get
that,
like
ability
to
really
focus
very,
very
clearly
on
just
my
own
business
logic
and
forget
about
the
rest
of
the
things
that
go
into
delivering
it
into
production,
rolling
across
versions
of
it,
etc.
I.
B
Think
one
reason
that
it
began
with
functions
as
a
service
was
the
pure
technical
one,
those
simple
status
pieces
of
logic.
It
was
easy
for
a
framework
to
hook
in
and
do
the
autoscanning,
long
term
or
I
think
it's
already
beginning
those
service
qualities
like
paper
use
and
then
auto
scaling
will
be
adopted
by
all
other
platforms
as
well.
What
maybe
remains
for
functions
was
the
special
programming
model
like
stateless,
event-driven
and
lightweight,
which
may
be
suitable
for
certain
use
cases.
A
That
makes
sense,
yeah
and
explain
it
a
bit
more
than
on
K
native.
The
the
constructs
are,
the
modules
we
have
in
K
native
I
mean.
Is
it?
Is
it
just
for
service
because,
for
example,
build
is
a
clear
one
that
it's
super
useful
outside
of
the
service
context,
as
well
I
mean
we
have
been
doing
that
for
a
while
with
open
shift.
Build
starts
to
image.
But
how
do
you
see
the
users
of
parts
of
K
native
outside
of
the
service
context,
or
he
said?
Is
that
even
possible.
F
Take
a
take
a
stab
at
this
quickly,
I
think
when
we
first
started
looking
in
into
Canada
itself,
and
we
start
identifying
some
of
the
properties
that
we
would
want
that
platform
to
have.
We
quickly
realized
that
those
are
not
something
that
developers
would
say.
Oh
I
want
four
functions,
but
I
don't
wanna
four
applications.
I
do
I
want
my
applications
to
spin
up
from
very
fast.
Yes,
I
would
want
that.
F
Would
I
want
my
application
to
scale
horizontally
based
on
the
amount
of
requested
receives
yeah,
one
of
that
four
functions,
all
under
four
applications
so
to
a
large
degree,
I
don't
see
that
that
differentiation
with
regards
to
the
type
of
scope
of
the
application,
whether
it's
just
one
function
or
a
whole
application,
but
I,
don't
think
that's
unique
to
that.
Yeah.
E
I
totally
agree,
which
is
why
I'm
actually
very
excited
by
Canada,
because
I
think
and
then
ice
relates
the
previous
question
of
a
Western
Swing
fast
and
serve
lists
like
I.
Don't
care,
I'd,
spawn
home
host
my
application
and
all
the
app
properties
of
server
lists
or
functions.
They
all
apply
to
every
single
application
right.
I
don't
want
to
care
about
networking.
I
don't
want
have
to
care
about
the
routing
stuff.
I
don't
want
to
cover
auto-scaling.
E
D
I
mean
just
say
that
I
mean
I,
think
that
it's
even
if
I
remember
correctly,
it's
actually
being
told,
but
actually
can
ad
packaging
is
worst
part
of
something
from
Cloud
Foundry
or
was
related
or
was
donated
by
a
foundry.
X
is
built
back
exactly
say,
I
mean
basically,
if
we
think
about
what's
going
on
right
now
with
Kane
editing,
it's
a
very
I
mean
there
is
a
lot
of
silver
mark
similarity
of
what
happened
before
that,
with
the
pass
right
with
a
little
bit:
Club
boundary,
for
instance
an
example.
So
then
the
different.
D
So
of
course
it
can
be
also
for
container
right,
because
I
mean
why
not
that's
what
we're
doing
for
all
this
time.
So
I
think
that
that
definitely
all
those
those
think
that
anyway,
I
think
it
was
born
for
the
first
place
from
pan
can
be
used
and
I.
Think
yeah
I
mean,
if
you
think
of
we
think
about
it,
as
he
said,
like
an
ad
should
be
used
for
service
and
fun.
Okay,.
C
F
C
So
one
of
the
things
that
I'm
especially
curious
to
see
is
I
have
two
two
components:
one
is
the
like:
server,
listen,
fast
and
I'm,
really
looking
forward
to
seeing
in
the
next
year
faz
offerings
that
are
based
upon
K
native,
because
you
know
that's
the
the
last
20%
to
get
to
the
experiential
things
that
you
would
expect
from
a
lambda.
For
example,
getting
there
is
an
interesting
journey.
C
The
the
kubernetes
nerd
in
me
is
also
extremely
interested
to
see
how
we
can
make
progress
in
kubernetes
and
and
for
example,
we
talked
about
scaling
performance
right.
We've
already
I
had
cause
to
find
at
least
one
thing
that
I
can't
remember
the
pull
request
number
now
to
kubernetes,
but
I.
Don't
think
anybody
really
cares
to
increase
the
performance
of
scaling
up
from
zero.
C
Where
going
back
to
my
like
pet
area
of
interest,
the
sub
area
of
interest
in
eventing,
where
one
of
the
the
novel
the
about
Canada
venting,
is
that
you
define
your
own
event
source
right,
and
that
gets
you
back
into
the
kind
of
like
cloud
native
application,
facet
of
life
and
kubernetes,
where
I
expecting
to
see
a
lot
of
event,
sources
get
produced
and
managing
them
and
making
them
work
together
and
just
giving
the
kubernetes
and
K
Native
communities
time
to
digest
exactly.
How
do
we
slice
and
dice
these
api's
for
event?
B
Speaking
of
eventing
today,
already
this
cluster
Federation
was
the
topic
sometimes
I.
Think
that
could
also
be
quite
interesting
for
Canadian
eventing,
because
events
usually
don't
start
at
the
edge
of
a
cluster
and
do
not
end
there.
So
you
usually
want
to
look
at
that
event
flow,
maybe
across
clusters,
or
also
across
or
with
regard
to
outside
sources,
and
that
could
be
interesting
to
combine
cluster
Federation
and
eventing.
It's.
C
Funny
you
mention
that
since
I
lead
a
team
at
Red
Hat
that
works
on
kubernetes
Federation
during
my
my
break
time
this
year,
I'm
really
looking
forward
over
the
holidays
to
to
getting
Federation
to
deploy
cane
native
resources,
which
is
I
I,
can
just
pitch
you
now.
I
will
be
able
to
do
this
without
writing
any
code
and
I'm
really
looking
forward
to
messing
around
with
like
a
native
services,
I.
D
Really
think
they
want
to
go
to
that
she'll.
Do
that
very
quick,
but
here's
what
I'm
thinking
right,
white
container
actually
catch
its
catch,
because
the
benefit
of
actually
using
container
was
a
huge
versus
using
legacy
application.
So,
first
of
all,
in
order
to
sterilize
to
become
something
in
my
opinion,
we
need
to
see
a
huge
benefit
of
someone
to
use
that
I.
Don't
know
that
it's
there.
Yet
that's
number
one
number
two!
D
Okay,
so
you
want
to
use
several,
so
you
want
to
use
micro
services,
but
what
about
the
other
stuff
that
you
using
already
so
people
using
more
legacy?
People
want
to
use
my
question
now.
There
is
couldn't
several
eyes
and,
in
my
opinion
the
problem
is
that
it
shouldn't
be,
or
it
should
be
end,
and
this
is
it
by
the
way
I
will
just
preach.
This
is
what
my
company
is
doing
so
look
at
out
for
that
glue,
but
that's
exactly
the
purpose.
What
if
we
can
take
the
legacy?
D
Application
actually
extended
it
to
my
core
service
and
service
and
edit
functionality
there,
which
makes
sense,
use
the
right
architecture
for
the
right
problem
to
solve,
and
that's
why
I
always
say
so.
The
future
and
honestly
I,
don't
think
that
it's
matter,
if
it's
cane
a
knee
or
something
else,
I
think
what
is
matter
is
that
for
those
people
to
use
it-
and
this
is
what
I
really
hoping
that
will
happen-
we
need
to
make
it
easy
for
them
and
tie
it
all
the
way
to
the
legacy
application
and
that's
what
we're
hoping
to
do.
D
F
Yeah
I
mean
I,
think
that
underscores
the
kind
of
the
right
way
of
thinking
about
it,
I'm
hoping
that
next
year
or
two
years
from
now
when
we
meet
at
a
conference
like
this
services,
just
assume
a
de
facto
use
usage
patterns,
you
as
a
developer
really
should
not
have
to
worry
about
a
lot
of
those
concerns.
I
know
we
Google
would
like
to
deliver
a
already
delivering
set
of
service
functions,
but
to
some
degree
we
want
you
to
come
to
a
platform
as
a
developer
and
not
have
to
make
a
choice
for
us.
F
A
Is
exactly
why
we
were
so
interested
in?
Can
natives
because
we
saw
that
again:
I,
don't
I,
don't
want
to
choose
right,
I
can
do
functions.
Applications
micro
services,
I,
can
have
my
integrations
with
even
sources
legacy
code
or
new
event
sources
that
that's.
Why
I
think
we're
so
interested
in
in
that
project.
I'd
like
to
thank
the
panel
to
join
us.
Thank
you
all
for
staying
with
us
and
I.
Think
that's
it.
Thank
you.