►
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
CNCF Serverless WG: Where Do We Go From Here? - Doug Davis, IBM
Come explore the history, goals, outputs and future direction of the CNCF Serverless WG. With the CloudEvents specification nearing its completion, the question of what (if anything) should come next has started to come up. One of the top pain-points mentioned for people using Serverless is the lack of interop and portability of their functions - does this open the door for a second sandbox project? Is it too soon? In this session we'll discuss, with the audience, these options and gather feedback to help influence what the WG does next. Come prepared with your thoughts and ideas!
https://sched.co/NrqS
A
All
right
so
I'm,
Doug
Davis
from
IBM
I,
am
the
co-chair
of
the
service
working
group.
A
working
group
under
industry
and
CF
I'm
also
co-chair
of
the
cloud
events
project,
which
we'll
be
talking
about
a
little
bit
in
a
second
first
of
all.
The
agenda.
First
talk
a
little
bit
about
the
service
working
group.
How
it
got
started
a
little
bit
of
an
overview
talk
a
little
bit
about
cloud
events,
just
a
quick
intro,
because
it
came
from
the
service
working
group
a
little
bit
about
workflow.
A
A
We
actually
had
an
80
minute
long
session,
where
we
covered
the
first
couple
things
in
like
15
minutes,
and
then
we
put
the
rest
of
85
minutes
on
that
burglar
feather
session,
and
for
me
anyway,
it
was
really
really
useful,
whether
you
guys
think
of
that
I,
don't
know,
but
I
need
to
get
input
from
you
guys,
so
that
of
the
birds
was
better
at
the
back.
So
just
a
warning.
Okay.
A
So
let's
talk
about
the
service
working
group
in
mid
2017,
the
CNC
F
decided
they
wanted
to
take
a
look
at
what's
going
on
with
surveillance,
it
was
a
relatively
new
technology
and
they
weren't
sure
what,
if
anything,
that
C&C
have
to
do
about
it.
So
they
started
the
service
working
group
for
the
main
purpose
of
doing
that.
Investigation
come
on
in
basically
doing
that
investigation
and
what
the
serve
of
this
working
group
did
was
basically
produce
a
white
paper
that
gave
an
overview
of
the
technology
itself.
So
what
is
service?
A
How
does
it
compare
to
the
other
technologies
out
there
containers
as
a
service
platform
as
a
service,
with
difference
between
server
list
versus
function
as
a
service
that
kind
of
stuff?
Okay,
also
gave
an
overview
about
the
technology
itself
in
terms
of
what
usually
goes
into
a
service
platform.
Right
talked
about
the
state
of
the
ecosystem.
What's
going
on
there
relative
to
the
open
source,
community
and
pitaya
Terry
type
stuff,
we
didn't
give
any
recommendation
in
terms
what
was
good
or
just
bad
just
provide
an
overview
of
what's
out
there
today.
A
That
overview
is
also
manifested
in
not
just
the
white
paper,
but
also
that
landscape
document
which
we
produced,
which
is
basically
nothing
more
than
a
spreadsheet,
of
all
the
various
service
platforms
out
there.
What
types
of
features
each
one
has
stuff
like
that
it
wasn't
a
judgment
about
which
one
was
good
or
bad
didn't
try
to
compare
them.
It
was
just
for
someone
trying
to
figure
out
what's
going
on
in
sir
list,
here's
a
list
of
things
to
choose
from,
as
you
want
to
play
with
it.
That's
all
it
was
just
to
overview.
A
What's
going
on.
These
are
systems,
and
then,
finally,
in
the
white
paper,
we
did
a
recommendation
set
section
which
basically
gave
recommendations
for
the
technical
oversight
committee
in
terms
of
what
should
they
do
next
relative
to
service
and
most
of
the
recommendations
were
around
things
like
education,
right,
educate
the
community
about
service,
where
it's
appropriate
to
use
it,
where
it's
not
appropriate.
Isn't
that
kind
of
stuff
but
wonder
important
thing?
There
was
what
can
I
serve?
A
What
can
the
thought
of
what
can
CNCs
do
next
relative
to
interoperability
or
solving
pain
points
for
the
community
itself,
and
one
of
the
things
we
noticed
was
that
service
in
many
cases
is
really
about
events
right
events
are
flowing
around
and
they're,
using
the
events
to
actually
kickoff
invocations
of
functions
or
serve
with
something.
So
we
start
looking
at
what
around
events?
A
Pasta
was
an
inner
ability
problem
and
we
realized
that,
while
all
these
events
are
flowing
around,
there's
no
real
standard
way
to
sort
of
analyze,
events
just
to
help
them
get
from
point
A
to
point
B
and
that's
what
cloud
events
was
really
all
about
and
that's
what
they
did.
Service
worker
group
decide
to
start
off
with
a
new
working
group
focused
on.
How
can
you
address
that?
One
little
pain
point
is
how
to
get
an
event
from
point
A
to
point
B,
without
having
to
do
with
some
of
the
pain
involved.
A
Let's
talk
a
little
bit
of
what
that
pain
actually
is.
As
I
said,
you
have
an
event
flowing
around
between
clouds
between
services
and
everyone.
Every
event
is
going
to
be
different
in
some
way
right.
Everything.
Every
business
application
is
gonna,
send
that
an
event
or
receive
an
event,
and
it's
some
sort
of
proprietary
format
and
that's
fine.
We
don't
want
to
say
change
that
because
that's
get
their
job
done.
A
However,
when
you
start
talking
about
saying
that
event
for
one
point
to
another,
in
order
for
those
points
in
the
middle
or
even
the
final
destination,
to
know
what
to
do
with
it
just
to
route
it
to
the
business
processing
logic,
it
usually
has
to
understand
that
message
itself.
You
need
to
have
to
understand
the
event
and,
what's
going
on
inside
there,
to
make
that
determination,
I've
had
you
the
proper
routing,
filtering
or
whatever.
A
Well,
what
cloud
event
is
trying
to
do
is
trying
to
come
up
with
a
standard
way
to
represent
that
the
common
metadata
needed
to
do
that
routing.
For
you
now
keep
in
mind
we're
not
trying
to
reinvent
another
cloud
event,
common
format
that
everybody
you
know
supposed
to
use
all
events
opposed.
Look
this
way!
That's
not
our
point,
we're
just
trying
to
define
the
bare
minimum
metadata
needed
to
do
this
base
routing
infrastructure
that
we're
talking
about.
So,
let's
take
a
look
at
what
that
actually
means
in
practice,
because
it's
really
not
that
complicated.
A
So,
first,
let's
think
of
a
CP
message,
right,
very
simple
message:
couple
HTTP,
headers
and
in
the
body
you
have
some
Jason,
nothing
big,
but
in
order
for
me
to
understand
how
to
route
this,
to
the
appropriate
processor,
I
have
to
understand
that
Jason
right
I
have
to
understand
basically
the
business
logic.
And
that's
that's
a
lot
to
ask
of
me
as
a
piece
of
middleware
right.
Think
of
the
middleware
is,
let's
say
a
proxy
just
trying
to
get
it
from
point
A
to
point
B
right.
A
If
he
wants
to
route
all
new
item
type
of
actions,
he
has
to
understand
that
Jason.
If
there's
a
field
called
action
and
there's
a
thing
called
new
or
value
called
new
item
to
radically
that
actually
a
lot
of
work.
Somebody
to
understand
when
you're
trying
to
make
a
piece
of
middleware
be
as
generic
as
possible.
Well
hope.
Our
events
does,
it
said,
look
here's
the
four
required
attributes
of
cloud
events,
spec
version!
This
is
the
version
of
cloud
of
inspect
very.
A
What
is
the
type
of
the
event
that's
flowing
through
here?
So
if
you
look
at
what's
happening
here,
is
it
saying?
Okay,
this
is
a
big
calm,
dub,
big
code,
new
event,
our
new
item,
so
new
item
is,
is
technically
action
itself
or
the
type
of
event,
but
we
prefix
it
with
Tom
big
ko,
because
it's
from
that
that
source
right
just
so,
we
get
a
little
bit
of
uniqueness
to
it,
because
there
could
be
dot
less
event,
producers
producing
a
new
of
item
type
of
event.
So
this
distinguishes
it
from
those
guys.
A
Then
you
have
the
source
so
who
sent
this
event
this
video
case
decode,
complex
repo
right
and
finally,
just
some
unique
identifier.
Think
of
it
just
a
UUID.
That's
it
there's
not
a
whole
lot
here
and
that's
the
point.
It's
a
minimal
amount
of
data
so
that
anybody
who
received
this
can
look
at
this
and
say:
okay,
I
know
that
there's
a
string
called
type
and
it's
going
to
describe
the
type
of
event.
So
I
can
set
up
a
very
generic
framework
that
says
route
events
from
say:
big,
Co,
I'm.
A
Sorry
from
calmed
a
big
co
that
star
to
this
processor
over
there
or
all
events
that
end
in
maybe
new
item,
go
over
there
right,
some
sort
of
basic
logically
didn't
that's
a
Porsche.
You
understand.
What's
in
the
body
open
through
simple
string,
sort
of
searches
on
either
the
type
or
the
source
to
do
whatever
router
you
need
right.
If
that's
all,
you
need
it
that
basic
routing
right
without
understand
the
business
project
and
that's
all
it's
trying
to
do
right.
So
in
a
lot
of
ways,
the
same
way,
the
HTTP
headers.
A
Don't
really
tell
you
much
about
the
message
itself
in
terms
of
the
business
logic,
it's
just
there
to
help.
You
get
the
message,
point
A
to
point
to
be
your
go
through
some
middleware
that
doesn't
really
miss
any
what's
going
on,
but
it
can
understand
basic
HTTP
common
headers.
That's
all
we're
doing
here,
right,
very
simplistic
thing,
but
with
that
it's
it's
able
to
give
you
a
little
interoperability
between
the
various
platforms
right.
A
So,
as
I
said,
the
middleware
doesn't
have
to
understand
the
business
object
anymore,
just
to
do
its
job
and
that's
critical
to
what
we're
all
about
here
now.
This
is
the
binary
format,
meaning
there's
an
existing
message.
We're
just
sprinkling
some
metadata
in
there.
That's
it.
If,
for
some
reason,
though,
you
want
to
actually
stick
that
data
inside
the
body
as
say,
for
example,
Jason.
A
We
do
tell
you
how
that
looks
just
to
get
some
interoperability
right
so
notice,
for
example,
the
content
I
change
from
applications
Jason
to
application
cloud
events,
Jason
application,
Jason
that
appears
down
here
on
a
cloud
of
n
property,
we
defined
called
data
content
type,
so
the
HTTP
body
goes
into
a
data
attribute,
but
everything
else
is
basically
the
same.
Just
a
wrapper,
tin,
jason
right.
So
you
could
use
this
as
your
global
event.
A
Format,
if
you
really
wanted
to,
but
that's
not
the
point,
because
we
don't
have
someone
force
field
users-
they
don't
want
to
if
you're
another
format
that
works
for
you
great
use,
it
just
sprinkle
it
with
met
a
day
with
a
couple
metadata
and
that's
it
so
that
basically
cloud
events
in
a
nutshell:
we
defined
some
metadata.
We
define
how
it
appears
inside
serve
format
like
Jason
or
how
it
appears
in
certain
transports
like
HTTP
and
that's
all
there
is
to
it.
We
have
a
couple
bits.
A
We
have
some
SDKs
to
help
you
do
the
generation
of
the
messages
or
processing
messages
to
get
it
to
and
from
those
formats,
so
SDK
to
do
that,
for
you
and
that's
okay,
very
simple
idea:
what
we're
seeing
this
start
to
get
some
real
traction,
because
people
are
looking
for
this
type
of
standardization
for
their
middleware.
Okay.
So
in
terms
of
the
deliverables,
we
have
the
specification
itself
or
at
zero
zero
point.
Three
right
now,
just
release
it.
A
A
couple
weeks
ago
we
have
a
couple
of
thousand
formats
Jason
and
QP
protobuf,
and
we
have
some
transport
sort
of
more
popular
ones.
We're
adding
new
ones
all
the
time
Kafka
is
actually
the
next
one
that
should
be
delivered
very
soon.
We
also
have
a
primer
that
gives
you
some
insight
into
some
of
the
decisions
we
made
and
why
we
made
them
because
a
lot
of
people
look
at
this
and
say
well,
that's
interesting
that
you
have.
A
You
know
these
properties,
but
why
don't
you
have
a
property
that
tells
you
where
the
message
is
going
right.
That's
what
the
primer
talked
about.
The
primer
will
explain
to
you
why
we
don't
have
a
destination
field
in
there
if
you're,
interested,
I
kind
of
stuff
Oh
gives
you
some
insights.
We
have
some
SDKs
for
marshalling
and
marshalling
of
their
data,
different
server,
the
languages,
and
then
we
have
some
extension.
Okay,
but
that's
basically
it
in
a
nutshell.
A
Now
the
reason
I
mentioned
this,
because
this
is
the
first
concrete
deliverable
aside
from
the
white
paper
from
the
service
working
group
and
as
I
said
it's
about
trying
to
get
interoperability
or
address
pain
points
for
the
community.
Okay.
So
this
is
at
0.3.
Technically
it's
at
0.9
in
terms
of
maturity
level.
We
are
actually
hoping
to
go
to
1.0
within
a
couple
of
weeks,
and
so
then,
then
the
question
is
okay.
What
are
we
gonna
do
off
the
bat,
the
same
people
working
the
service
working
group
at
spot
events?
A
We
just
put
the
service
working
group
on
hold
while
we
finish
up
this,
so
what
is
next
for
the
service
working
group
backs
out
of
it,
which
should
hopefully
come
in
a
couple
weeks.
So
one
of
the
things
we
decided
to
work
on
a
long
time
ago
was
something
called
workflow.
So
when
you
have
these
service
functions
out
there
a
lot
of
times,
you
found
that
people
want
to
sort
of
string
them
together
right.
What
event
comes
in
goes
to
one
function
that
produce
another
event
goes
to
another
function.
Maybe
there's
some
conditional
logic.
A
You
need
to
branch
off,
do
something
there's
a
whole
workflow
or
pipeline
type
of
structure.
People
want
to
define
and
a
lot
of
people
way
to
do
it,
there's
probably
a
technology
out
there.
That
already
does
that.
Of
course,
it's
not
interoperable
right.
The
way
you
define
a
one
system
isn't
necessarily
going
to
work
in
other
systems,
so
we
thought
well,
the
notion
is
out
there.
A
Can
we
make
life
easier
on
people
to
talk
by
trying
to
standardize
or
come
up
with
a
common
way
to
define
that
workflow
and
that's
what
this
workflow
project
is
gonna
be
working
on?
So,
as
I
said,
the
goal
here
is
to
define
the
basic
primitives
for
how
to
string
together
various
functions
invocations
right.
So
it's
going
to
conclude
some
basic
primitives
in
there
like
states
and
steps
triggers
references
to
the
functions
are
gonna
get
invoke,
possibly
some
filtering
that
kind
of
stuff.
A
The
important
thing
to
know
here
that
it's
talking
about
how
to
actually
wire
these
things
together,
meaning
what
comes
next
and
how
to
decide
what
comes
next,
it's
not
gonna
necessary
how
to
invoke
the
function
itself
in
particular
function
signatures,
that's
not
something
that
workflow
gets
into.
It
ignores
that
that
is
one
of
the
things
that
were
looking
at,
possibly
looking
to
standardize
later
from
a
service
working
perspective,
but
workflow
doesn't
get
into
that.
It
doesn't
talk
about
how
to
invoke
the
function.
It
just
says
what
function
to
invoke
next
very
important
distinction.
A
It
also
doesn't
talk
about
the
instead
format
or
metadata.
That's
that
that's
for
someone
else
to
solve.
This
is
just
about
basically
putting
the
wires
between
the
various
boxes
and
again.
This
is
all
about
foster,
Portability
and
interoperability
across
platforms,
and
this
is
the
second
step,
so
the
service
working
group.
Of
course
it's
not
about
being
the
first
step.
So,
let's
take
a
little.
Let's
take
a
look
at
what
the
works
will
actually
mean
for
for
more
concrete
perspective,
so
workflow
meet
the
execution
flow
and
really
we're
talking
about
as
a
state
machine
at.
B
C
A
They've
been
trigger
itself,
but
as
you
go
from
state
to
state
those
are
actually
events
as
well
right,
so
the
result
of
a
function
getting
invoked
is
treated
as
another
event
that
then
moves
on
to
the
next
state.
So
obviously
the
states
here
talk
about
what
the
current
state
entire
system
right
was
there,
a
failure.
Do
you
keep
going
to
the
next
step?
Is
there
a
if
statement
like
right
the
switch
statement
in
there?
Basically
in
a
statement
right?
A
Does
this
after
there's
one
state
to
you,
stand
out
to
multiple
functions
or
multiple
other
states,
that
kind
of
stuff
and
then
finally
have
actions?
Basically
the
functions
themselves
right,
so
some
of
the
states
will
actually
invoke
other
functions.
Other
states
lead
on
to
other
states
themselves,
like
the
switch
state,
goes
on
to
the
tab
page
and
that's
basically
the
the
the
basic
idea
of
the
career
proposal
for
workflow
document.
A
The
current
state
of
this
is
that
it's
only
a
point
one
stage
we
started
working
on
this
we
used
to
have
weekly
calls,
but
then
we
realized
that,
because
the
same
people
are
in
both
groups,
meeting
cloud
events
and
server
lists,
they
wouldn't
had
time
to
do
both
the
same
time.
So
we
kind
of
put
this
one
on
hold.
As
I
said
after
the
side,
events
stuff
goes
to,
1.0
will
probably
circle
back
around
to
continue
working
on
here,
but
if
you
have
any
interest
in
the
workflow
stuff,
please
look
at
the
service
working
group.
A
B
A
Level
resistance
in
the
group
to
do
too
much
too
quickly.
There's
a
lot
of
people
been
worried
that
your
standard
I,
something
it's
going
to
limit
people's
creativity,
to
expand
it
or
to
to
explore
the
possibilities
with
that
particular
domain.
So
we
have
to
tread
very
very
lightly
here,
because
a
lot
of
people
are
very
scared
of
standards,
especially
in
the
open-source
community.
But
if
you're
interested
in
any
of
these
ideas
or
are
the
ones
you
think
might
be
worthy
drop
me
a
notes
or
just
come
to
one.
A
That
service
working
group
calls
we'd
love
to
hear
what
you
guys
think
are
the
pain
points
for
you
to
address.
Okay
now
that
was
actually
really
quick.
15
minutes.
Now
we
get
to
the
part
that
you're
dreading.
This
is
questions
for
you,
guys,
okay,
because
what
I
want
to
do
now
is
okay,
I
told
you
about
cloud
events.
Let's
we've
got
the
service
working
group
told
you
about
some
of
the
things
we
think
are
pain,
points
for
people
that
we
want
to
consider
working
on.
A
D
A
A
lot
of
people,
but
one
thing
that
I
actually
think
we're
missing.
We
do
have
some,
but
good
anymore,
is
the
end
community
input
right.
We
need
people
are
actually
using
this
stuff
on
a
daily
basis.
Not
the
people
producing
the
infrastructure
is
producing
this,
the
cloud
providers.
We
need
people
end-users,
basically
giving
us
feedback
in
terms
of
when
you
go
to
use,
lambda
IBM
cloud
functions,
Google,
clappings
or
whatever.
What
are
the
pain
points
you're
experiencing
right
and
that's
what
I?
Just
next
section
is
really
about
right.
This
is
the
bird
or
feather
thing.
A
So,
let's
start
off
with
some
simple
questions
even
before,
even
before
that
one.
How
many
people
here
are
using
containers
today
in
production
really
not
everybody's
hand,
wind-up
you
guys
every
yeah.
This
is
this.
Is
the
CN
CF
you
guys
should
all
be
saying?
Yes,
we
love
containers
or
we're
all
using
it.
No,
so
that's
interesting!
A
Okay
and
that's
actually
I'm,
not
surprised,
it's
disappointing
for
me,
because
this
is
what
my
job
right,
but
it
doesn't
surprise
me
because
I
found
that
there's
a
lot
of
not
resistance,
but
it's
a
it's
not
as
quickly
growing
as
we
would
have
hoped
right,
for
whatever
reason
people
aren't
picking
it
up
on
it,
maybe
because
it
takes
time
to
be
more
micro.
Your
infrastructure,
maybe
they're,
still
nervous
about
it,
for
whatever
reason,
I'm,
not
that
surprised
so
left
hands
are
going
to
go
up.
A
I'm
sure
how
many
people
are
using
server
lists
in
production
today,
one
two:
three:
okay,
okay,
so
I'm
gonna
pick
on
you
three,
then
a
lot
for
the
following
questions:
okay,
well,
actually,
first
of
all,
for
you
guys
you're,
actually
using
either
service
in
production
or
just
playing
around
the
server.
Would
you
be
comfortable
telling
me
what
kind
of
things
you
use
it
for?
E
E
E
A
C
C
Our
use
case
is
about
two
scenario.
First,
one
is
the
service.
We
call
light
service,
abouts
and
O'jays
service.
We
we
use
surveys
in
our
company
to
run.
Another
use
case
is
the
async
event,
such
as
kafka
event
and
object,
storage
event
such
as
that,
for
example,
if
you
have
some
event
into
Kafka,
you
can
watch
the
consume
the
Kafka
event
then
today,
I
use
the
car
event
to
describe
this
horrible
event.
A
C
C
It's
a
service
to
have
some
advantage
and
in
our
in
our
use
case,
and
thus,
if
we
maintain
standalone
service
in
our
production
that
we
need
to
scale
the
max
capacity
every
time.
So
it's
hard
to
decide
for
user
to
decide
what
a
capacity
is.
So
the
service
is
the
mental
Vantage
for
saving
our
resources.
A
Thank
you
alright.
So
the
next
question
on
here
I
believe,
is
for
everybody
else,
aside
from
those
three,
why
aren't
you
considering
service
and
last
time,
I
asked
this
question
in
Barcelona.
I
got
some
really
interesting
answers.
Anybody
willing
to
raise
their
hand
to
say
why
they're
a
little
resistant
to
play
with
service
at
this
point
in
time?
A
A
You
guys,
yeah
I
was
afraid
this
being
very
quiet,
onions,
you
guys
gonna
make
me
do
all
the
talking
okay,
so
just
maybe
this
will
help.
So
when
I
embark
on
to
some
of
the
reasons
I
got
was
or
were
related
to
with
containers
as
a
service
or
with
containers,
we're
told
hey,
you
know,
take
your
monolithic
application
and
split
it
up
into
micro
services,
and
that's
fine
conceptually,
it's
a
it's.
Rather,
it's
somebody's,
our
task,
oh
right.
A
Where
do
you
draw
those
lines
where
you
draw
the
boundaries
to
actually
have
little
micro-services
well
with
functions
or
surplice?
We're
now
saying:
hey
great
now:
do
it
again
right,
take
your
micro-services
and
split
them
up
into
tiny
little
little,
you
almost
like
utilities
right
and
again
it
back
gets
back
to.
Where
do
you
draw
those
lines
right?
How
do
you
then
split
it
up?
A
How
you
then
manage
not
just
five
micro-services
now
fifty
functions
right
and
people
are
a
little
nervous
about
that,
because
they're
not
sure
brother,
where
the
tooling
is
there
yet
right
how
to
do
the
split
the
education
around
it,
a
little
bit
nerve
wracking
for
people,
and
that
was
actually
a
one
of
the
things
we
learned
most
about
the
audience.
Barcelona
was
there's
just
some
fear
and
they're
not
ready
for
that
progression.
A
Yet,
and
they're
also
we're
afraid
that
the
tooling
wasn't
there
yet
to
help
them
because
they
feel
like
there's
a
challenge
with
just,
for
example,
gathering
logs
from
you
know
your
five
microservices,
oh
my
gosh.
Now
these
things
are,
you
know,
exploded
out
to
have
so
much,
and
then
they
get
a
scale
90
minutes
on
logs
across
that,
and
there
are
tools
to
help
you,
but
they
weren't
sure
whether
they
were
mature
enough,
and
that
was
part
the
reason
they
were
doing
it.
Anybody
want
to
say
anything
yet.
D
We
are
using
still
they're
seeing
our
production
parts.
The
service
we
are
use
is
not
true
service.
He
cannot
scale
to
zero,
yes,
so
we
so
so
they
provide
us
some
reserve
mode.
We
we
give
them
some
volume
and
a
scale
to
let
valen
to
serve
us
and
what
holds
us
from
using
it.
The
first
one
is
this
capability,
like
the
scale
to
the
load,
the
ability
to
scale
to
zero,
and
the
other
problem
I
want
to
mention
is
that.
A
A
D
I
thought
that
was
not
a
true
service:
okay,
the
second
one.
The
second
one
is
that
the
we
rely
a
lot
of
micro
service
behind
us,
but
they
are
not
past
service.
They
are
traditional
micro
services
and
there
they
are
not
service.
They
are
not
a
service
and,
what's
worse,
is
that
we
need
to
use
some
rich
client
to
call
them
and
they
provide
some
JA
file,
a
Java,
rich
client
to
call
them,
and
we
are
no
GS
application.
It
is
hard
for
us
to
to
interoperate
with
them.
D
A
I'm,
not
a
purist,
so
the
fact
that
you
don't
scale
down
to
zero,
that's
still
service
to
me.
I
know
a
lot
of
people
think
service
has
to
go
to
zero.
For
me,
service
is
a
little
more
abstract
and
to
me
it's
like
the
auto
scaling
and
and
the
function
level
type
stuff,
but
even
then,
but
ok,
but
thank
you
for
providing
that
that's
useful.
Thank
you.
Ok,.
A
There's
most
you're
either
shy
or
not
using
service.
It's
quite
this
next
question
may
not
apply
to
you
so
when
you
guys
are
actually
using
servlets,
though
what
are
the
pain
points
for
you,
I
mean
you
guys
are
using
cloud
events,
so
hopefully
that's
helping
you
a
little,
but
why
are
you
finding,
for
example,
that
you're
tied
down
to
one
particular
sector
right?
You
said
you're
using
AWS
ugly
right.
A
Do
you
feel
like
you're
locked
in
or
do
you
feel
like
you
could
take
your
at
your
8,
your
lambda
to
another
platform
and
easily
run
it
there
right
is
portability
of
functions
so
in
this
worries
you
right
is
the
because
the
function-
signature,
for
example,
will
probably
change
when
you
go
to
someplace
else,
because
lambda
has
their
own
little
function.
Signature
with
context
being
passed
in
other
ones
can
have
their
own
way
of
doing
it
is
that
kind
of
stuff?
Were
you
at
all
in
terms
of
portability
or
do
you
feel
like
it?
A
E
For
us
currently
we're
we're
not
worrying
about
portability,
because
we
just
migrated
from
on-premise
data
center
to
at
the
bless.
So
right
now
we're
it's
it's
a
face
where
we
like
locked
in
at
the
bus.
We
don't
worry
about
that,
but
we
for
me
my
from
my
personal
experience.
We
I'm
a
little
worried
about
how
to
life
I
feel
as
isolated
of
to
code
like
in
different
lambdas.
A
E
A
E
Think
it's
a
mental
model
because
I
sometimes
I
couldn't
tell
the
the
upstream
of
this
lambda
function
and
I
certainly
could
tell
the
downstream.
But
it
makes
about
kind
of
make
me
worried
about
well
what
if
we
have,
thousands
of
numb
does
and
I
don't
know
or
really
don't
know
how
it
flows
the
data,
how
it
flows.
A
E
B
A
Okay,
we
are
running
a
little
low
on
time
here,
but
it's
the
one
last
question
for
you
guys
take
us
all
the
way
now
you've
mentioned.
Actually
it's
interesting.
You
were
just
talking
about.
You
have
current
workloads
and
it's
a
challenge
to
just
split
them
up
and
actually
make
them
into
function
and
stuff.
Are
there
workloads
that
you'd
like
to
see
supported?
A
So,
for
example,
one
of
the
things
that
I
hear
differing
opinions
on
is
whether,
for
example,
a
server
list
should
or
its
streaming
right
are
those
the
tight
you
know
is
that
something
you
want
good,
let
people
think
of
service
as
small
little
function
short
live.
In
fact,
you
know
like
Lando,
for
example,
won't
let
you
run
function
for
certain
two
minutes
and
stuff
like
that.
But
what,
if
you
want
to
have
a
function
that
actually
runs
for
a
couple
hours,
because
it's
doing
some
stream
processing
right?
A
A
Why
don't
you
get
auto
scaling
at
platforms,
we're
containers
of
service
right
and
if
you
look
at
a
project
bike,
a
native
they're,
almost
trying
to
bring
those
three
worlds
together,
because
you
have
played
around
teenager
I'm
talking
about
so
I'm
wondering
whether
you
guys
feel
like
you're
being
forced
to
choose
artificially
between
the
three
platforms
or
whether
you
would
prefer
a
world
where
it's
just.
Here's
a
container
here's
how
I
wanted
to
behave
and
you
don't
care
about
what
it's
called
in
terms
of
platform
versus
function
versus
container
of
the
service.
A
Anybody
have
that
sense,
or
is
this
all
in
my
head
just
curious?
Thank
you.
Okay,
anybody
else
have
an
opinion
or
maybe
because
to
some
people
as
I
said:
I'm,
not
a
purist
right,
but
to
some
people
they
care
about
this
stuff
and
there's
a
very
strict
definition.
You
don't
want
to
mix
the
world
I'm
just
curious.
Does
anybody
want
to
voice
an
opinion
one
way
or
the
other?
A
Okay
yeah
four
minutes
left
you're
autistic
the
lucky
at
home
and
of
course
you
guys
speak
anymore.
So
just
in
summary,
but
thank
you
for
the
feedback.
I
know
it
wasn't
as
80
minutes
long,
but
still
the
baby
Becky
gave
you
was
useful.
So
thank
you
very
much.
So
just
some
links
for
you
service
working
group
link
to
the
workflow
spec
for
the
cloud
event
stuff.
A
Some
links
there
to
the
orchid
soaps,
pykrete
boat,
SDKs
and,
like
I,
said,
if
you're
interested
in
the
service
working
group
in
terms
of
what
we're
going
to
work
on
next,
whether
it's
workflow
or
you
have
an
idea
for
something
else
that
to
that,
please
let
us
know
either
drop
me
a
note
or
join
the
service
working
group.
We
have
mailing
lists
and
stuff.
Let
us
know
what
you
where
your
pain
points
are
where
you'd
like
to
kids
go
next,
and
so
with
that
I
think.
There's
three
minutes
left.
F
A
Depending
where
you're
inside
of
yeah
yeah,
we
could,
the
problem
is:
we've
only
had
I
think
one
person
from
China
joined
on
a
regular
basis
and
so
for
one
person
to
be
very
difficult
to
convince
everybody
else
to
switch.
If
we
got
indication
that
there's
more
than
one,
we
would
definitely
consider
so
voice.
Your
opinion
askance
a
limitless.
You
want
to
join,
but
it's
bad
time
and
we
can
do
a
trial
run
okay.
But
if
we
don't
hear
from
you
we're
not
going
to
think
about
it,
be.
F
A
G
G
A
A
G
A
The
fact
that
the
entire
community
came
together
understand
CF,
to
do
it,
mean
something,
and
so
it's
going
to
increase
the
chances
that
people
adopting
it
with
something
like
workflow
or
anything
else.
We
do
I
think
it's
gonna
be
the
same
thing.
You
run
the
risk
of
it
being
yet
another
whatever,
but
because,
if
we
do
it
right,
we're
gonna
have
the
big
players.
In
there
you
know
the
IBM
Red
Hat,
Google,
Microsoft,
hopefully
and
Amazon,
hopefully
we'll
get
them
to
participate
and
if
they
participate,
the
ended
in
the
definition
of
that
thing.
A
I
think
it
increases
the
likelihood
of
it
being
adopted
because
I
had
the
exact
same
fear
without
events
first
started
right,
it's
gonna
be
yet
another
sort
of
a
vending
type
of
thing
right,
but
we
heard
I
can't
mention
their
name,
but
we've
heard
that
a
lot
of
the
big
players
are
adopting
it
and
I.
Think
it's
simply
because
they've
been
participating
in
it
and
they've
had
a
chance
to
voice
their
opinion
and
shape
it
to
something
that
meets
their
needs,
and
we
didn't
try
to
go
too
far.
A
Right,
as
I
said,
we
weren't
trying
to
find
yet
another
common
event
format.
We
looked
at
one
particular
pain.
Point
says:
how
do
we
get
that
common
metadata
into
an
event
right?
So
if
we
can
do
something
similar
with
workflow
right,
the
workflows
a
lot
bigger
than
for
little
metadata
attributes,
but
if
we
use
something
similar
there,
it
says
if
we
can
cover
a
certain
percentage
of
the
workflows
that
people
are
defining
today
in
a
relatively
common
format
and
get
the
big
boys
to
agree
to
support
it,
then
it
can
take
off
but
you're
right.