►
From YouTube: KBE Insider (E12) - Daniel Oh & James Falkner
Description
This month, KBE Insider interviews Daniel Oh, Sr. Principal Technical Marketing Manager at Red Hat and CNCF Ambassador as well as James Falkner, Director of Product Marketing at Red Hat. In this KBE Insider episode we’ll dive into the work Daniel and James do to evangelize cloud-native microservices and serverless functions. We’ll cover open source projects such as Quarkus, Spring Boot, NodeJS and how you can contribute!
A
All
right
now
we're
actually
here
hello,
everybody.
So
this
is
kubernetes
by
example,
insight
and
we
do
a
show
where
we
try
to
talk
to
people
who
are
deeply
involved
with
the
kubernetes
ecosystem
as
contributors,
so
that
we
can
find
out
what's
happening.
You
know
coming
soon
because,
unlike
you
know,
a
typical
product,
for
example,
we
try
to
find
you
know
when
we
talk
to
product
managers
in
a
typical
product.
They
have
a
good
idea.
A
What's
gonna
happen
with
the
open
source
world,
it's
often
better
to
actually
talk
to
the
engineers,
because
then
we
might
have
some
clue
of
what
might
really
happen.
So
that's
what
we're
doing
today.
So
I'm
langdon
white
and
I
am
a
faculty,
a
faculty
member
at
boston
university.
Now
I
used
to
work
for
it
and
joining
me
is
my
co-host
today
is
josh
josh
fergus
and
he
will
introduce
himself.
A
A
C
Yeah,
so
thanks
for
having
me
so
james
faulkner,
I
run
product
marketing
and
technical
marketing
for
some
several
of
red
hat's
application
development
projects,
certain
products,
many
of
which
are
not
only
compatible
with,
but
as
you
mentioned
use
and
can
have
native
integrations,
with
serverless
capabilities
on
kubernetes
things
like
k-native
and
and
other
ways
of
executing
code
across
container
orchestration
platforms,
cloud
platforms
et
cetera,
et
cetera.
So
I'm
a
former
I'm
a
recovering
developer.
C
B
C
A
A
I
hear
you
I
hear
you,
I
don't
have
anything
so
the
reason
we
wanted
to
invite
both
of
you
today
was
to
kind
of
talk
about
what
you're
seeing
is
kind
of
the
future
of
microservices
on
you
know
kind
of
on
the
kubernetes
platform.
Why
is
it
interesting?
What's
you
know
kind
of
what's
new
and
different
about
microservices
versus
our
traditional
service
awareness,
architectures.
A
D
Yes
for
sure
so,
yeah
just
once
again
that
daniel,
oh
I'm,
actually
working
the
james
fox
team
like
the
developer
of
advocate
and
technical
marketing,
as
well
as
cnc
investor
yeah.
So
the
microservices
was
grown
like
like
seven
and
eight
years
ago,
and
then,
but
for
that
we
are
all
working
with
the
monolith
application
to
run
multiple
modules
to
implement
business
application,
but
things
changed
there.
So
cloud
platform
came
out
and
then
we're
looking
for
the
more
optimized
and
then
more
portable
and
standardized
application.
D
Runtime
like
a
java.net
or
python
node.js,
whatever
you
need
so
main
purpose
of
the
market
service
architecture,
you're
going
to
run
independently
the
application
runtime,
but
also
you're,
going
to
serve
the
single
business
domain
or
capabilities,
and
then
it
really
fit
into
your
container
orchestration
platform
like
a
kubernetes
you're,
just
packaging,
one
containerized
application
with
a
single
microservice
application
and
the
running
on
top
of
the
kubernetes
or
cloud.
And
then
you
have
a
huge
high
scale
ability
and
the
flexibility
and
probability
as
well.
C
Yeah
one
of
the
interesting
things
josh
you
mentioned
soa,
I
think
earlier
I've
come
commonly
heard.
The
phrase
microservices
is
so
done
right,
which
is
kind
of
funny,
because,
like
the
concepts
and
and
and
the
the
way
you
develop
microservices
that
daniel
mentioned
it's
like
well,
we
had
this.
You
know
20
years
ago
with-
or
maybe
it
probably
was
20
years
ago
by
now
for
service
oriented
architecture.
The
problem
with
soa
wasn't
the
concept
of
a
service
oriented
thing.
C
It
was
the
way
that
it
was
implemented
and
the
the
the
centralization
of
the
the
contracts
between
the
different
services
into
like
the
central.
You
know,
integration
team
and
it
kind
of
produces
a
big
bottleneck
and
slowdowns
in
terms
of
making
changes
to
or
developing
new
and
making
changes
to
existing
applications
that
need
to
talk
to
different
services,
so
microservices,
in
addition
to
the
like
the
the
architectural
benefits.
C
It's
also,
if
you,
if
you
it
split
these
services
across
business
domains,
and
you
also
match
that
to
your
development
teams,
so
that
you
can
have
these
autonomous
teams
building
these
services
and
then
independently
publishing
them.
Then
you,
the
benefits
of
microservices,
start
to
really
shine
through.
It's
not
like
the
apple.
The
application
is
getting
simpler.
C
Actually
microservices
makes
things
more
complex,
but
if
you,
you
know
adopt
the
the
idea
of
these
independent
services
being
developed
independently
by,
as
we've
all
heard,
the
phrase
two
pizza
teams,
then
that's
where
the
real
benefit
comes,
and
that's
really
the
big
difference
between
the
microservices
of
two
decades
ago,
which
we
called
soa
versus
what
we're
doing
these
days
and
then
serverless.
You
know,
as
we
will
probably
discuss,
improves
upon
that
even
further.
A
Yeah
conceptually,
I
mean
it's
funny
right,
because
we've
actually
been
doing
that,
I
mean
you
can
kind
of
trace
back.
You
know
various
implementations
of
how
to
do
services
for
a
long
time.
You
know
if
we
look
at
things
like
corba
or
whatever
you
know.
Clearly,
the
concept
of
a
service
is
a
service.
You
know
whether
it's
a
you
know,
you
call
it
architecture
or
whatever
comes
with
the
service,
is
really
fundamental
to
building
scalable
applications
and
what
I
think
at
least
for
me,
one
of
the
big
differences
as
well.
A
You
know
you
kind
of
mentioned.
You
know
kind
of
services
done
right,
except
I
also
added
is
also
the
approach
you
know.
Soa
was
very
much
a
top
down.
You
know
it's
like
this.
This
ivory
tower
of
architects
would
come
up
with
this
perfect
plan,
and
you
know
it
would
take
them
months,
if
not
years,
to
develop
that
part,
and
then
they
would
feed
it
out
in
bits
and
pieces
down
to
the
development
teams.
A
What's
so
interesting
about
the
microservice
model,
even
conceptually,
it's
actually
a
very
similar
idea,
you're
actually
kind
of
going
bottom
up,
so
you're
only
building
things
that
people
are
actually
using
will
actually
meet
and
what
we
found
right.
This
is
also
similar
to
the
transition
of
waterfall
to
agile.
Is
that
when
you,
if
you
kind
of
approach,
soft
development
in
terms
of
building,
only
what
you
need
when
you
need
it,
you
end
up
with
a
much
better
end
product.
So
that's
the
other
big
thing,
at
least
for
me,
why?
I
think
microsoft.
C
Yeah
one
thing
we
have
to
be
careful
about
is
is
making
everything
microservices
like
there
are
cases
where
it
doesn't
make
sense,
depending
on
the
size
of
the
team
and
the
culture
of
the
organization
that
that
is
building
the
application.
You
know
monolith
might
be
perfectly
fine,
I
think
was
it
the.
I
can't
remember
his
name
that
the
the
founder
of
base
camp
actually
just
made
a
conscious
decision
not
to
do
microservices
because
of
the
the
nature
of
their
team
and
the
fact
that
they
were.
C
D
C
D
Know
yeah
sure,
so
serverless
is
more
like
a
deployment
model,
so
the
microsoft
microservices
is
some
kind
of
architecture
how
to
build
application.
How
to
run
independently
in
a
serverless.
Serverless
is
kind
of
deploying
model,
which
means,
regardless
of
any
application
runtime.
It
makes
you
have
application
just
run
and
scale
down
to
zero
without
network
traffic.
D
So,
for
example,
the
monitor's
application,
also
microsoft,
application
running
all
the
time
like
a
24
7,
regardless
of
the
container
or
like
a
virtual
machine,
even
bare
metal,
but
in
the
end
a
lot
of
enterprise
companies
figure
it
out.
Oh
our
the
most.
Our
business
application,
don't
need
to
run
all
the
time
and
we
also
need
to
reduce
our
cost
to
run
and
maintain
application
in
order
to
solve
the
kind
of
business
challenges
and
technical
problems.
The
serverless
actually
enable
developers,
as
well
as
like
enterprise
companies,
solve
that
kind
of
problem.
D
This.
So
that's
why
the
serverless
we
already
talked
about
serverless
platform
like
amazon,
render
or
google
function
or
azure
function,
it's
all
kind
of
a
deployment
model.
So
when
you
deploy
application
into
serverless,
it
should
be
running
on.
If
you
shouldn't
be
running
all
the
time,
it
should
be
long
very
certain
periods
of
time
and
the
e
will
be
high,
but
not
the
like
scales
down
to
zero,
like
a
30
second
or
for
upper
mini.
D
C
I
just
wanted
to
add
that
when
you,
when
you're,
when
the
application
is
quote,
unquote,
running
and
not
scaled
to
zero,
it's
also
tracking
and
responding
to
load
so
that
anyone
can
scale
up
to
you
know
multiple
instances
to
handle
additional
load.
This
is
the
idea
that
you
want.
You
want
your
compute
resource
to
track
the
load
on
it.
D
Things
like
that
yeah,
that's
a
really
good
point.
So
that's
really.
I
want
to
really
talk
about
so
a
lot
of
enterprise
companies
really
care
about
like
a
climate
change
like
a
the
carbon
dioxide,
the
reducing
and
then,
for
example,
google
cloud
they
currently
co2
neutral
cloud
platform
and
they
are
aiming
for
the
co2
free
by
2030.
C
So
for
developers
it
it
so
we
often
present
this
or
actually,
we
started
to
present
this
slide
years
ago,
showing
the
evolution
of
software
right.
We
have
the
monolith
on
the
left
and
then,
as
we
move
to
the
right,
we
go
from
monolith
to
mini
services,
to
microservices
to
serverless,
and
it's
like
this
architectural
progression
and
the
benefit
to
developers
for
serverless.
Is
they
like?
C
But
you
don't
want
them
worrying
about
how
those
applications
going
to
be
deployed
and
what
server
input,
what
what
server
apis
they
have
to
call
to
get
this
one
function
done
and
they're.
Just
one
task
done.
You
want
them
to
be
able
to
write
the
the
logic
for
their
service
and
and
be
done
with
it,
and
you
know
not
have
to
worry
about
how
to
package
it
up
and
and
and
run
it
on,
like
an
application
like
a
traditional
application
server
like
the
java
ee
app
server.
That's
really
the
benefit.
A
Well,
and
and
similar
to
kind
of
the
whole
kubernetes
idea
right
is
that
you
know
you're
just
kind
of
separation
of
concerns.
We
actually
had
somebody
remark
in
the
in
the
chat
right,
you
know.
Basically,
the
difference
is
that,
while
there
is
still
a
server
there,
the
the
operational
control
for
the
server
is
managed
by
somebody
other
than
the
person
who
is
trying
to
run
the
functionality,
and
that's
that's
really
what
we
mean
by
servers,
but
it's
actually
kind
of
the
joy
of
containerization
as
well.
A
You
know,
and
arguably
also,
the
goal
of
a
virtual
machine
is
just
that
the
separation
isn't
good
enough
right,
so
you
know,
as
we
get
further
and
further
away
from
it.
What
we're
trying
to
do
is
just
separate
those
concerns
across
you
know
different
different
responsibilities
so
that
we
can
kind
of
have
an
expertise
in
you
know,
running
operational
and
expertise
and
working
in
building
software
that
are
not
necessarily
the
same
people,
but
also
can
operate
independently.
C
Now
there
are
there's
certain
languages
and
frameworks
that
early
on
had
a
kind
of
a
a
head
start
on
java
in
particular,
and
I'm
thinking
of
things
like
node.js
and
golang
or
and
and
python
and
languages
that
were
a
lot
more,
shall
we
say,
dynamic
and
easier
to
kind
of
write
and
get
running
really
fast
with
javascript
right.
It's
like
you,
write
a
couple
lines
of
javascript,
and
maybe
you
get
the
types
right.
C
Maybe
you
don't,
but
it's
still
gonna
run
so
like
framework
or
sorry
platforms
like
amazon
lambda
had
you
know,
kind
of
first
class
support
for
node
in
javascript
for
running
serverless
workloads
java
came
along
a
bit
later,
but
it's
it.
You
know
some
of
the
some
of
the
historical
architectural
decisions
and
trade-offs
made
by
the
java
platform
early
on.
C
You
know
built
built
for
big
iron
built
for
two
carats.
How
long
it
takes
to
start
up?
Who
cares
how
much
memory
it
takes
as
long
as
it
can
maximize
its
throughput?
Those
kinds
of
trade-offs
made
it
a
little
less,
actually,
a
lot
less
friendly
to
use
in
a
serverless
infrastructure
environment
like
aws,
lambda
or
k-native
on
on
on
kubernetes,
so
yeah,
so
node.js
had
a
bit
of
an
advantage
there.
But,
like
I
said
you
can
you
can
write
them
in
any
language
that
the
platform
supports.
A
Well,
and
as
much
hate
as
j2e
has
gotten
you
know
kind
of
over
the
years
right
I
mean
at
the
end
of
the
day
that
that
whole,
like
that
ee
part,
really
was
service
contracts
right,
you
know
like
maybe
not
called
that,
but
that
was
really
what
was
going
on,
as
you
were
doing
service
contracts
between
the
various
components.
So,
in
some
ways
in
java
the
you
know,
the
hp
is
the
word,
but
the
orientation
around
you
know
being
service.
A
Modeled
right
was
was
early
early
on
in
java
and
did
a
really
nice
job
of
it.
It
was
just
that
it
required
it,
but
much
like
soap
would
sell
out
right
and
there
you
go.
I
did
it
for
you.
What
you
do
it
like
the
overhead
to
describe
the
service
was
so
high
that
people
kind
of
reacted
poorly
to
it,
but
you
know
so
now
we're
kind
of
getting
into
maybe
a
happy
medium
where
you
can
describe
a
service
and
with
that
service
take
a
lot
of
the
same
code.
A
You
know
like
a
better
term,
and
you
know,
node.js
brings
a
lot
of
that
to
the
table.
Python
also
brings
a
lot
of
table,
which
is
super
nice,
so
we
did
actually
have
a
question
from
the
audience,
which
was
so
if,
if
you're
a
developer,
right
or
you're,
should
you
be
preparing
your
developers
to
continue
the
working
moments
or
thinking
about
serverless?
D
D
They
don't
need
to
actually
prepare
or
training
or
kind
of
application,
skill
or
technology
based
on
serverless,
because
the
serverless
is
a
very
specific
use
cases.
So
you
don't
need
to
change
your
own,
existing
microservice
application
or
even
monitor
the
application
to
suffer
less
so,
for
example,
james
already
mentioned
earlier,
so
your
application
sometimes
scale
down
to
zero
or
a
very
you
know,
optimized
for
compute
resources,
specifically
kubernetes
or
cloud
environment.
D
D
In
that
case,
you
don't
need
to
change
your
application
architecture
or,
like
a
little
bit
considerable,
no
need
to
consider
about
the
serverless
as
well,
but
so
any
in
a
project
company
always
think
about.
Okay,
so
some
specification
like
a
business
requirement,
we
needed
to
evolve
existing
application
to
serverless
at
any
time
soon.
D
B
Imagine
imagine
I'm
a
cs
student
though
looking
at
graduation
and
getting
on
the
job
market
right.
What
should
I
be
learning
first?
What
should
I
be
assuming
that
if
I
develop
a
greenfield
application
from
scratch
right
or
I'm
working
for
a
startup
where
I'm
writing
all
new
code,
you
know
what
should
be
my
sort
of
default
pattern.
D
Actually,
I
got
some
very
similar
questions
in
a
developer
conference,
so
specifically
the
college
student
they're
really
looking
forward
to
what
is
what
is
the
most
popular
and
the
valuable
like
the
program,
language
for
the
seeking
new
job?
And
then
they
said,
like
a
python
or
like
a
ph
like
a
data
scientist,
something
like
that
and
if
I
would
say
java
and
then
they
say:
oh,
this
is
kind
of
old
stuff.
Like
you
know,
so
we
all
almost
the
same
age.
D
We
really
talk
about
cobbles
and
then
oh,
it's
maybe
20
years
ago,
old,
school
style
and
actually
the
college
student.
They
said
java
so
maybe
30
years
ago,
like
some
old
school
thing,
but
I
want
to
say
so:
whatever
they
choose,
the
application
or
java
pro
like
a
program
language,
their
programming
language
could
be
flexible
and
then
dynamically
changing
for
the
adopting
new
environment,
not
just
cloud
but
also
maybe
coming
iot
edge
or
like
a
machine
learning
or
artificial
intelligence
and
then,
if
they
needed
to
restart,
was
start
over
running
new
application.
C
Right
right,
right,
right,
absolutely
you're,
100,
right
and
the
reason
yeah.
So,
like
you
said
it's
not
about
languages,
it's
important
to
know
a
few
languages,
but
they
all
are
kind
of.
They
have
similar
similar
constructs
and
similar
ideas
because
computer
programming,
computer
programming,
you
know
for
loops
and
so
forth.
C
More
importantly,
the
architectural
patterns.
I
think
that
it's
important
to
learn
the
value
proposition
or
it's
important,
to
learn
that
the
bit
the
like
the
main
tenets
of
of
each
of
all
of
the
major
kind
of
buckets
of
of
architecture
like
monolith
versus
microservices
versus
serverless.
Those
aren't
the
only
three,
but
I
think
that
it's
good
to
have
a
grounding
in
in
several
of
them,
because
at
the
end
of
the
day,
there's
going
to
be
a
different
right
answer
for
each
of
the
problem
that
you
face.
C
C
I
think
there's
a
lot
of
a
lot
of
attention
right
now
on
things
like
microservices
and
serverless,
but
the
the
value
proposition
of
microservices
is.
Is
you
know
it's
pretty
compelling,
but
it's
not
always
like.
I
said
the
right
answer
and
it's
just
a
special
case
of
distributed
computing,
which
we've
had
for
a
number
of
years.
So
if
you're
looking
at
a
high
performance
like
cpu
intensive
application,
microservices
is
probably
not
the
right
way
to
go.
If
you're
building
a
a
highly
con,
you
know
a
high
transaction
or
high
concurrency
need
web-based
application.
C
A
But
then
I
would
just
kind
of
like
add
that
little
bit
is
that
I
think
you
bring
up.
A
really
good
point.
Is
that
the
challenge
that
a
lot
of
people
I
think
are
having
right
now
is
that
they
don't
actually
understand
that
there
are
all
these
architecture
types
and
they
are
all
different
and
they
all
different
have
different
use
cases
and
not
every
you
know,
not
everything
that
looks
like
a
nail
needs
to
be
hit
with
a
hammer.
A
B
Right
when
you're
building
a
monolithic
application
in
java
java
is
much
more
object,
oriented
in
its
design.
Right,
I
mean
people
who
are
work
on
more
recent
languages
will
quibble
with
that,
but
but
that
is
the
basic
theory
of
design
for
java.
But
then,
when
you
move
into
serverless,
or
at
least
either
event
driven
applications
or
function
as
a
service
right,
which
are
two
sort
of
halves
of
serverless,
you're,
actually
kind
of
a
necessity
for
force
to
adopt
a
more
functional
programming
approach.
B
C
C
So
the
concept
of
this,
this
event-driven
architecture
comes
into
play
because
it
gives
you
things
like
this.
We
call
temporal
temporal.
I
can't
remember
the
word
is
basically
your
your.
The
call
that
you
make
you
know
eventually
is
going
to
either
succeed
or
fail
in
a
good
way
so
that
you
can
respond
accordingly.
It
also
doesn't
have
doesn't
matter
where
these
other
services
are
running
so
yeah.
I
think
you
definitely
have
to
change
your
mindset
when
you're
when
you're
thinking
about
serverless,
driven
or
serverless
centric
architecture
patterns.
A
I
was
speaking
as
a
old-school
com,
so
windows
com
developer
from
many
many
years
ago,
which
was
an
actual
adventure
in
architecture.
I
totally
miss
it.
You
know,
like
I,
I
think,
there's
actually
a
lot
of
opportunity
in
a
monolithic
architecture.
Serverless
or
you
know,
microservice,
there's
a
lot
of
opportunity
for
adventure
and
architecture.
So
you
know,
I
think,
they're
a
little
bit
orthogonal
to
kind
of
the
you
know
it's
a
lot
actually
easier
to
do
than
with
a
service
model,
but
there's
so
much
more
scalable,
they're,
so
much
easier
to
identify.
C
C
Yeah,
and
one
thing
to
close
that
chapter
on
is
that
when
you
as
we
start
to
move
into
event-driven
serverless
things
like
she
said,
debugging
gets
hard
right,
stack.
Traces,
no
longer,
look
like
the
stacked
traces
of
old,
where
you
can
kind
of
see
from
you
know
the
the
from
the
beginning
of
the
thread
all
the
way
through
all
the
calls
that
ended
up
in
failure.
Now
you
get
this
super
short
stack
trace.
That
said,
something
failed,
but
you
have
no
idea
why
and
what?
What?
What
called
that
to
cause
that
to
fail?
C
C
So,
like
things
like
open
telemetry,
which
recently
enjoyed
their
first
release,
is
becoming
very,
very
much
more
important,
even
in
a
serverless
context,
because
even
in
the
serverless
context
right,
the
service
lives
for
a
few
milliseconds
and
if
there's
a
problem
in
there
and
you
you're
you're
unable
to
observe
that
problem,
you're
never
going
to
be
able
to
fix
it.
So
observability
is
super
super
important
and
that's
one
of
the
other
things
that
I
think
any
college
student
when
they're
learning
this
modular
model
or
modular
distributed
patterns
that
they're
going
to
be
using.
D
One
thing
I
want
to
show
on
the
add
one
one
thing
I
want
to
share
something:
so
they
eventually
went
all
the
scaling
specifically
like
a
kubernetes
and
the
kubernetes
are
basically
using,
like
the
hpa,
horizontal
part
or
scalar
based
on
cpu
and
memory.
Realization,
it's
really
good
to
enable
your
workload.
Auto
scanning
depends
on
this
resource
utilization.
The
problem
is
when
you
build
on
like
event,
driven
application
and
architecture
on
kubernetes.
D
It
should
be
auto
scale
based
on
evangelion
magic
rather
than
cpu
memory.
It
takes
a
long
time
to
figure
it
out.
Okay,
my
application,
like
a
pause,
get
out
based
on
cpu
memory,
memory,
realization,
it's
a
really
latency
problem.
So
that's
why
you
have
some
kind
of
new
auto-scale
infrastructure
based
on
events,
mastery
like
a
cloud
events
or
a
prometheus
metrics
or
like
a
aws
monitoring
or
even
kafka
topics.
So
this
is
one
of
the
reasons
why
the
cada,
the
kubernetes
evangelical
scaling
the
one
of
the
cncf
project,
which
is
super
popular.
A
Yeah,
that's
a
really
good
point.
I
mean,
I
think,
that's
you
know
one
of
the
things
that
we're
seeing
with
you
know
kind
of
environments
like
kubernetes
that
were
you
know.
We
were
talking
before
right
about
separation
of
operational
things
versus,
like
you
know,
business
logic,
things
increasingly
we're
moving
more
and
more
of
the
operational
things
into
automatic
engines
right.
So
you
know
what
I
I
don't
know
if
this
is
actually
like
a
quote
from
anything
really
to
link
safety
liability,
but
it's
the
way
I
think
of
it.
A
Like
I
explain
it
is
like
you
know,
you
want
to
fix
the
recipe,
not
the
cake.
You
know
so
you
know
just
putting
frosting
on
the
cake.
You
can
fix
this
individual
cake
and
you
know
and
make
it
all
better.
But
really
what
you
want
to
do
is
fix
the
recipe
and
the
more
we
can
do
things
like
auto
scaling,
for
example,
especially
when
we
scale
to
zero
the
more
we
can.
You
know,
fix
the
recipe
so
that
we
can
put
these
applications
in.
A
You
know
some
environment
that
will
deal
with
the
operational
stuff
around
it
and
then
kind
of
just
monitor
it.
It's
working,
okay,
one
thing
I
also
wanted
to
bring
up
there
except
james.
I
think
that
was
a
good
point,
which
is
that
you
know
what
how
do
you
you
know
you
all
feel
about
the
kind
of
future
of
the
observability
stuff.
Is
that
something
that
people
should
be
paying
attention
to
is
an
important
focus?
Is
it
you
know
just
something
people
are
doing
on
the
side
because
they
look
cool
graphs.
A
C
I
mean
that's
one,
that's
that's
the
one
that
is
very
it's
it's
very
much
on
the
forefront,
at
least
from
the
red
hat
side
of
things,
in
terms
of
being
able
to
observe,
because
it
has
sort
of
that
that
quote-unquote
native
ability
for
java
applications
to
use
it
and
it's
being
integrated
in
a
number
of
different
frameworks.
Like
things
like
quercus,
I
know
the
the
microprofile
specifications
which
we
can
talk
about
specs
later,
but
they
they
also
have
a
number
of
observability
capabilities
in
that
specification,
feature
set,
which
is
fantastic.
C
I
think
that
is
that
is
sort
of
it
shows
you
that
the
observability
is
important
and
becoming
more
increasingly
so
as
we
move
into
this
more
distributed
environment.
So
the
the
open
telemetry
is
a
good
one.
To
follow
the
you
know,
projects
for
doing
distributed,
tracing
things
like
jager
have
been
around
for
forever
and
we
have
you
know:
lots
of
products
that
red
hat,
support
and
and
use,
and
you
can
use
jager
to
do
that
distributed
tracing.
I
think
the
concepts
are
more
important
to
learn
and
understand.
C
C
A
B
B
D
Yeah,
let
me
let
me
let
me
try
to
answer
that.
So
you
know
so.
Everybody
has
different
software
as
a
problem
like
ms
around
google
and
azure
and
a
lot
of
stuff
and
then
the
one
interesting
part
from
cncf
they.
Actually,
the
serverless
working
group
try
to
standard
standardize.
The
serverless
like
a
not
just
problem,
it's
more
like
a
processing
model.
D
You
should
fulfill
this
mandatory
requirement
for
the
standard
serverless
platform
and
then
so
because
so
you
know
also
many
many
enterprise
companies
looking
forward
to
like
a
go-to
adopt
like
a
multi-cloud
or
like
hybrid
cloud
strategy,
which
means
your
application
could
be
what
should
be
running
on
amazon
lambda
as
well
as
azure
function
or
google
cloud
anytime
soon.
So
you
know
today
we
definitely
need
to
standard
serverless
like
a
model
or
architecture
rather
than
tied
into
specific
cloud
provider.
D
So
that's
the
reason
why
cnc
for
working
group
actually
working
on
that
and
then
we
don't
have
any
okay
amazon
render
is
in
the
standard,
we're
not
going
to
say
that
in
the
in
the
open
source,
community
and
ecosystem.
But
we
can
say:
okay.
This
is
a
standard
serverless
processing
model
with
the
like
some
mandatory
architectural
characteristics
and
the
features.
C
Yeah
one
thing
I'd
like
to
add
to
the
interface
or
the
interface
question
is
like
when
microservices
started
to
become
really
popular.
However,
many
years
ago,
seven
or
eight,
the
other
thing
that
became
really
popular
was
like
using
http
and
rest,
and
no
one
really
got
the
rest
thing
like
they.
They
call
it
rest,
but
it
was
really
just.
You
know,
one
simple
interface
that
there
was
no.
There
was
no
actual
urls
and
uris
and
ability
to
address
objects
it.
C
D
A
really
good
point,
and
then
also
to
including
the
cloud
I
mean
eventually,
an
application
with
this
server
lasts,
maybe
cloud
event.
Maybe
you
might
heard
about
that
before,
because
the
cloud
event
provides
the
standard,
the
event
driven,
I
mean
messaging
formats.
So,
for
example,
you
have
a
reactive
application
based
on
multiple
ranking
platform.
Okay,
I
want
to
use
json
format
like
a
restful
api.
Well,
I
want
to
use
xml
or
binary
or
a
pro
bulb.
D
It
depends
on
what
kind
of
application
you're
going
to
do
that,
but
the
problem
is
with
the
serverless
platform
or
serverless
application.
Maybe
you
have
to
interface
with
the
different
like
a
evangelical
messaging
format,
which
is
totally
like
a
hassle
not
easy
so
and
the
cloud
event
actually
pro
solve
that
problem.
Okay,
whatever
you
take
the
application
language
or
go
javascript
or
java
python,
the
cloud
event
standard
format,
you
can
easily
communicate
the
evangelion
architecture
with
the
serverless
application.
A
Yeah
that
was
kind
of
funny.
We
were
talking
about
kind
of
a
venture
in
architecture
and
we're
kind
of
giving
some
examples
of
those
implementations,
and
I
think
people
don't.
You
know,
really
realize
this,
because
very
few
people
use
it
this
way.
But
node.js
actually
is
intrinsically
an
adventure
in
architecture
like
that's
exactly
what
it's
supposed
to
do,
but
because
event,
driven
architectures
are
so
complex
right
that
people
find
it
so
difficult
to
use
they
slapped
a
plug-in
on
top
of
them
called
express,
and
then.
A
A
So
I
was
going
to
kind
of
move
on
a
little
bit
like
where's
the.
Where
do
you
feel
like
the
advantage
of
looking
at
these
architectures
and
thinking
about
you
know
whether
we're
talking
about
something
like
corpus
or
serverless
or
whatever?
Where
is
the
advantage
of
open
source
in
those
models
like
why?
Why
is
open
source
a
better
solution
to
that
problem?.
C
B
B
C
It's
more
fun
to
to
be
a
committer
on
a
project
or
to
to
feel
like
you're
giving
back.
So
those
are
all
good
things.
I
think
that
I
think
that
I
open
source
one
a
long
time
ago,
in
my
opinion,
and
so
even
though
we
have
things
like
aws
lambda,
I
think
that
in
the
long
run,
open
source
will
continue
to
win.
C
There
are
other
you
know,
frameworks
like
things
like
k-native
that
run
on
top
of
open
source
platforms
like
kubernetes
that
will,
at
the
end
of
the
day,
I
think,
become
more
widely
adopted,
as
as
lambda
is
sort
of
a
stepping
stone
to
a
number
of
other
aws
services,
none
of
which
are
open
source.
I
think
that
that,
as
diminishing
returns
to
to
organizations
that
are
looking
to
standardize
their
practices
in
terms
of
hiring
and
training
and
purchasing
of
you
know
supporting
products.
C
I
think
that
that
that's
going
to
be
decreasingly
a
value
proposition
to
a
company
or
to
an
organization,
because
your
things
like
vendor,
lock-in
and
and
other
concepts
that
are
not
really
technical
in
nature.
But
more,
I
don't
know
what
the
word
right
where
it
is,
but
non-technical
considerations
I
think
open
source
is,
is
a
better
there's,
a
better
thing
for
for
companies
to
adopt.
But
that's
just
my
opinion.
D
Yeah
I
I
I
strongly
agree
with
that.
So
so
just
one
thing
I
want
to
share
like
open
source
of
value
proportion.
I
mean
not
just
a
subless,
all
kind
of
like
a
technology
ecosystem,
it's
so
flexible
and
then,
whenever
you
are
looking
for
like
a
next
feature
or
more
flexible
things
happening,
you
don't
need
to
wait
for
the
next
release
like
it's
like
a
bender
product.
D
So
you
just
pull
recast
and
then
you
can
contribute
it
directly
and
then
there
are
so
many
like
an
individual
contributor,
but
also
like
a
like
a
user
group
or
even
vendors,
trying
to
make
it
better
make
it
more
flexible,
not
tied
into
specific
product
or
specific
technology.
So
summerless,
of
course,
is
to
keep
evolving
super
fast,
just
not
like
a
monolith.
D
It's
a
really
fast,
like
a
iot,
so
anytime
soon
what
happened,
who
knows
and
then
the
open
source
community
so
flexible,
adopted
that
kind
of
fast
change,
rather
than
like
a
like
more
like
a
vendor
rifle
cycle
like
a
product
thing.
So
there
is
one
of
the
value
proportion.
I
mean
open
source,
community
and
open
source
project
to
keep
chasing
fast.
Changing
the
new
technology
yeah.
C
Yeah,
if
you're
going
all
in
on
serverless
for
your
organization,
do
you
really
want
to
have
that
dependency
long
term?
Or
do
you
want
a
platform
that
you
can
not
only
understand
yourself
but
also
find
other
folks
who
have
either
contributed,
or
also
part
of
that
community
to
to
help
out
when,
when
you
need
something,
it
just
seems
like
a
better
value
proposition
if
you're
just
doing
a
one-off
thing,
then
yeah,
maybe
it'll
it'll,
work
and
work
for
you,
but
longer
term.
You
know.
C
A
big
bet
paid
by
an
organization
is
better
to
be
bet
on
an
open
source
project,
because
I
mean
also
the
business
continuity
concern
right.
If
that
vendor
suddenly
goes
out
of
business,
maybe
aws
might
not
do
that
overnight,
but
you
know
having
those
dependencies
on
open
source
means
that
you
can
continue
to
run
yourself
if
needed.
A
Yeah
I
mean
it's,
it's
not
all.
You
know
roses,
but
you
know
I
mean
we
have
open
source
projects
fail
as
well.
You
know,
and
that
happens,
but
at
least
you
know
at
the
end
of
the
day,
it's
actually
like
really
really
old
school
software
acquisition.
Right,
where
you
know
as
part
of
your
software
acquisition
you
would
actually
get,
but
basically
they
would
give
you
a
copy
of
the
source
code,
but
you
couldn't
actually
see
it.
It
was
like
a
safe
held
by
a
lawyer.
C
A
A
Really
interesting
about
the
open
source
school,
a
lot
of
these
models
or
these
architectures
is
that
the
innovation
is
there
in
the
sense
that
like
if
I
can
just
go
off
and
like
build
this
chunk
of
k
native
or
whatever
I
can
say
hey.
This
is
this
is
what
I
think
should
happen
with
serverless
and
that's
a
huge
advantage
because,
like
even
if
I'm
wrong
right,
at
least
at
least
an
idea
has
been
tried
right
that
people
have
rejected,
or
if
I'm
writing
you
know,
there's
no
barrier
right.
A
C
D
D
I
think
this
serverless
can
be
integrated
any
like
a
workload,
not
just
a
web
application,
but
also
you
could
integrate
software
less
with
the
service
mesh
or
aml,
or
any
kind
of
the
use
cases
and
workload
pretty
easily
and
the
one
good
thing
for
the
developers.
Maybe
they
need
to
choose
the
right
program,
language
or
runtime
environment,
to
make
them
easily
enable
the
kind
of
integration
on
the
just
auto
box
feature,
rather
than
you
I
needed
to
add
some
kind
of
other
party
library
or
some
other
complex
configuration
yeah.
A
Yeah,
I
think,
a
lot
of
people,
don't
really
think
about
the
fact
that
you
know,
like
a
bus
architecture.
You
know
internally
to
the
big
iron
enterprise
corporation
right
in
a
lot
of
ways
is
an
event-driven
architecture,
if
not
entirely,
and
that
serverless
solutions
can
be
a
great
answer
for
those
and,
in
fact,.
A
Trading
apps,
like
stock
trading
apps,
you
know
it's
kind
of
like
you
look
back
on
it
and
you're
like
oh,
that
actually
was
kind
of
like
a
serverless
application.
You
know
there
was
a
venture
and
it
was
fire
and
forget,
and
that
was
how
the
system
worked,
because
it
was
the
only
way
it
could
scale
successfully
to
the
you
know,
to
the
workload
and
so
yeah.
A
There's
a
ton
of
there's
a
ton
of
examples
out
there,
where
you
know
microservices,
certainly,
but
I
think
serverless
is-
is
really
a
good
solution
and,
as
serverless
gets
stronger
or
gets
more
sophisticated,
I
think
that
we'll
see
even
more
opportunities
for
why
you
know
designing
your
application
around
a
serverless
architecture
might
work
for
60
70.
Even
you
know,
90
of
your
application,
which
I
think
is
that
really
interesting
movement
forward
so
josh
see
we
have
questions.
B
A
A
A
Now
we
hope
to
all
right,
so
thanks
so
much
to
our
guests.
I
really
appreciate
it
again.
I
apologize
for
my
location
found
that
conference
and
I
thought
it
would
be
kind
of
cool
to
do
something
in
kind
of
a
public
place,
but
apparently
my
mic
is
not
doing
as
well
as
my
old
apache
helicopter
bike,
where
I
used
to
be
able
to
like
do
a
meeting
from
anywhere.