►
From YouTube: No Docker, No YAML and a Polyglot Developer Experience on Top o... Thomas Vitale & Mauricio Salatino
Description
Don’t miss out! Join us at our upcoming hybrid event: KubeCon + CloudNativeCon North America 2022 from October 24-28 in Detroit (and online!). Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
No Docker, No YAML and a Polyglot Developer Experience on Top of Kubernetes - Thomas Vitale, Systematic & Mauricio Salatino, VMware
Let's build a CaaS (Containers-as-a-Service) platform that delivers a similar experience to well-loved solutions like Google Cloud Run and Azure Container Apps. Those platforms allow you to run your applications without the need to know about containers or Kubernetes. They take your source code and remotely build and deploy your software while hiding away the complexity of Docker and Kubernetes. This presentation gives practical advice on how to build such a platform in a cloud provider-agnostic way on top of Kubernetes using only open-source projects.
Thomas and Mauricio will show how the platform can scale and provide developers with a polyglot environment to code, build and deploy their event-driven applications. The presentation will cover how tools like Knative, CloudEvents, Buildpacks, func CLI, and popular languages like Java, Go, and Python can be glued together to provide an optimized polyglot developer experience that can be tested and demoed in front of a live audience.
B
A
Okay,
so
we're
going
to
be
talking
a
little
bit
about
a
polyglot
developer
experience
on
top
of
kubernetes
the
idea
of
having
kind
of
like
a
docker-less
dockerfile,
less
also
like
jammless
experience
when
you're
building
applications
on
top
of
kubernetes
we'll
be
talking
a
little
bit
about
kennedy.
We
will
be
talking
a
little
bit
about
functions
as
well,
so
we
are
just
going
to
go
over
a
bunch
of
topics
and
just
you
know,
play
a
little
game.
My
name
is
maurice
latino.
A
I
do
work
for
vmware,
but
my
main
responsibility
nowadays
is
to
work
100
of
my
time
in
k
native.
I'm
also
writing
a
book.
That's
called
continuous
delivery
for
kubernetes.
You
know
there
are
like
a
couple
of
discounts
there
if
you're
interested
in
that
just
check
the
slides
later
on.
I
will
be
sharing
that,
and
here
I
have
thomas
with
me.
Yes,
I.
B
Work
as
a
software
architect
at
systematic,
a
danish
software
company,
I'm
really
passionate
about
anything
cloud
native.
I'm
also
writing
a
book.
It's
called
cloud
native
spring
in
action
with
springboot
and
kubernetes
I
like
contributing
to
open
source.
So
it's
really
great
to
be
here
and
sharing
our
passion
and
knowledge
around
all
these
open
source
projects.
It's
really
great
yeah.
A
Of
course
it's
been
built
using
k
native
and
using
functions,
and
it
looked
like
this.
We
will
be
sharing
kind
of
like
the
link
to
access
the
real
application.
This
is
just
the
demo
where
you
can
just
generate
a
username
and
then
just
click
play,
and
then
it's
just
a
quiz
game
right.
So
you
will
be
answering
a
couple
of
questions
about
valencia
and
then
interacting
with
some
other
questions
that
are,
you
know,
picking,
stuff
and
doing
stuff,
but
something
important
there
is
that
you
have
a
timer
there
that
it
takes
like
10
seconds.
A
A
One
of
the
things
that
I
wanted
to
show
you
is
that
when
you
reach
kind
of
like
this
final
screen,
there
should
be
here
like
a
tweet
button
at
the
bottom
that
it's
not
showing
up,
but
it
should.
It
will
show
up
in
your
phones
and
if
you
tweet,
and
if
you
score
high
in
the
game,
we
are
going
to
be
sharing
some
swag
and
some
stuff
as
well.
So,
at
the
end
we
all
play
together
with
that.
B
B
I
want
to
have
developers,
focus
on
the
business
logic
and
push
any
kind
of
infrastructure
or
concerns
down
to
the
platform,
so
the
platform
is
going
to
take
care
of
provisioning,
the
infrastructure
necessary
for
our
purpose,
our
business
purpose,
it's
going
to
manage
the
workloads
that
we
deploy
on
kubernetes
and
also
it
will
handle
dynamic
scaling.
So
if
I
have
more
users
or
more
people
playing
the
game,
for
example,
I
don't
want
to
do
anything
manually
or
explicitly.
B
I
want
the
platform
to
take
care
of
that
and
scaling
out
so
to
accommodate
the
increase
in
the
number
of
requests
in
coming
into
our
system
and
one
way
of
building
such
a
serverless
platform
on
top
of
kubernetes.
What
we're
going
to
use
today
is
based
on
k
native
a
component
within
the
canadian
serving
project
it's
yeah
k
native
serving
so
it's
used
to
build
a
serverless
experience
on
top
of
kubernetes,
so
we
are
still
dealing
with
kubernetes
resources.
It's
completely
kubernetes
native
and
we're
going
to
get
for
starters,
developer,
friendly
abstractions.
B
So
instead
of
dealing
with
ingresses
services
deployments,
replica
sets
pods
we're
going
to
get
one
type
of
abstraction
that
the
developer
is
concerned
with,
and
that's
it
so
we're
going
to
see
it's
a
much
much
easier
for
a
developer
to
interact
with
such
a
platform.
We
get
from
code
to
url
experience,
so
I
have
my
application
and
then
I
want
to
get
the
url
where
I
can
access
my
application
running
in
kubernetes.
I
don't
want
to
deal
with
all
the
steps
that
are
in
between
this
process.
B
I
also
want
auto
scaling
in
particular
also
scaling
to
zero.
If
there's
no
request
incoming,
if
there's
no
event,
if
there's
no
reason
for
my
containers
to
be
up
and
running,
I
don't
want
them
to
run
so.
Scaling
to
zero
is
really
great,
also
for
cost
optimization,
of
course,
and
being
more
resource
efficient.
I
I
also
have
the
possibility
to
handle
progressive
rollouts
so
via
k-native.
I
can
implement
deployment
patterns.
For
example,
I
can
have
the
blue
green
deployments.
I
can
do
canary
releases
all
through
the
simple
single
abstraction
that
kinetic
serving
exposes.
B
It's
all
request,
driven
and
event
driven.
That's
also
what
triggers
the
auto
scaling
it's
based
on
the
request
or
the
events
in
coming
into
the
system,
and
finally,
it's
cloud
agnostic.
You
can
run
it
on
any
kubernetes
distribution,
but
at
this
point
we
can
get
this
container
as
a
service
experience.
So
we
have
a
platform
where
we
can
provide
just
a
container
image
and
then
the
platform
takes
care
of
the
rest,
but
still
as
a
developer.
B
That's
why
we
like
to
use
buildbox
another
cncf
project
with
buildbacks.
We
get
a
specification
that
converts
application
source
code
into
container
images
which
are
ready
to
go
in
production.
So
it's
all
based
on
a
builder
image.
That's
what
is
called
that
knows
so
has
knowledge
about
how
to
containerize
in
the
best
possible
way,
different
kinds
of
applications
implemented
with
different
languages
and
different
frameworks.
B
B
So,
let's
see
it
running,
I
have
built
a
very
simple
and
small
go
application
here.
It
exposes
an
http
endpoint
returning
a
list
of
books,
so
the
first
thing
I
can
do.
I
have
already
built
a
container
image
out
of
the
the
application,
so
I
can
use
the
k
native
cli
km,
I
can
say
kn
service
create
and
then
I
give
it
a
name.
B
B
B
B
B
And
then
the
builder
I
have
to
specify
a
builder.
I
mentioned
that
for
this
presentation
we
are
using
the
pacquiao
buildbox
implementation,
the
builder
image,
and
then
I
give
the
container
a
name,
for
example,
book
service,
and
that's
it
once
I
get
the
image,
then
I
can
go
ahead
and
have
k
native
taking
care
of
the
rest.
B
Once
we
have
a
container
image,
then
knativ
does
the
rest.
I
can
use,
for
example,
the
kn
cli
to
do
that
and
deploy
the
application
in
a
kubernetes
cluster
final
part.
I
get
back
a
url,
a
public
url
where
I
can
consume
the
application,
but
still
this
approach
is
really
great.
I
can
use
it
for
any
kind
of
workload,
but
there
are
two
things
that
we
can
improve.
First,
we
can
automate
even
more
of
this
process
so
to
improve
the
developer
experience
when
using
such
a
platform.
B
A
Let's
do
that,
so
what
thomas
has
showed
is
basically
the
process
of
a
development.
You
know
like
a
development
team,
just
creating
software
and
then
just
packaging
that
containerizing
it
and
then
running
it
into
kubernetes.
Cluster
kennedy
is
doing
a
lot
there
to
you
know
to
simplify
that
experience,
providing
some
cli
tools.
If
you
need
to
do
the
same,
using
jumbo
files,
you
will
have
like
shorter
and
smaller
jammer
files
that
you
can
use
as
well.
A
When
you
start
thinking
about
improving
the
developer
experience,
you
need
to
ask
why
and
kind
of
like
what
kind
of
use
cases
do
you
want
to
implement
functions
and
building
functions
of
the
service
platforms,
provide
that
kind
of
like
simplification
for
certain
kind
of
workloads
and
certain
kind
of
applications.
So
we
will
be
looking
at
this
more
specific
use
case
of
building
a
platform
that
is
just
targeting
these
function
developers.
A
A
Usually
you
tend
to
build.
You
know
integration
testing
across
multiple
functions,
but
not
for
a
single
function,
which
is
kind
of
like
a
nice
simplified
way
of
building
applications.
When
you
talk
about
functions,
you
are
also
being
startled
like
hearing
about
cold
starts.
That
basically
means
that,
because
now
the
platform
is
dealing
with
the
scaling
up
and
scaling
down
the
application,
our
functions,
the
the
programs
that
we're
building
needs
to
quickly
start
so
the
platform
you
know,
don't
leave
the
ones
that
are
creating
requests.
A
Like
hanging
there
and
waiting
for
the
container
to
start
so
functions,
frameworks
are
optimized
just
to
make
sure
that
you
know
these
functions.
These
containers
can
be
started
fast
and
because
we
can
scale
down
to
zero
when
we
are
building
with
fun.
When
we
are
working
with
functions,
you
know
we
can
just
start
saving
some
money
because
functions
that
are
not
being
used
are
completely
downscaled.
They
are
not
running
in
the
cluster
and
the
platform
will
take
care
of
just
starting
them
when
we
are
getting
requests.
A
So
when
we
again,
when
we
talk
when
we
start
working
with
functions,
you
definitely
need
to
change
the
way
that
you
design
and
you
know,
implement
the
applications,
and
you
tend
to
have
like
two
different.
Like
you
know,
interaction
patterns
with
functions.
You
have
like
the
synchronous
side
of
things
where
you
can
interact
with
the
function,
sending
an
http
request,
and
then
you
know
the
function
will
do
something,
but
you
are
not
interested
in
the
response,
so
we
just
let
it
work
there.
A
You
know
that
it
will
put
data
somewhere
and
then
the
application
can
continue
from
there.
You
have
a
more
like
request
response
approach
where
you
just
call
the
function,
and
then
you
need
to
wait
to
get
the
results
back
to
continue
processing,
remember
the
game.
We
are
evaluating
the
inputs
from
an
answer
and
then
we
are
creating
a
score
and
then
we
are
sending
the
score
back
to
the
user
interface.
A
In
that
case,
we
are
using
that
pattern
and
then,
when
you
are
using
request
response
or
fire
and
forget
you
also
most
of
the
time
I
would
say
90
of
the
time
you
need
to
go
and
interact
with
some
kind
of
external
storage
right,
because
functions
are
stateless.
They
are
not
storing
a
state,
so
you
might
need
to
go
out
and
say
and
write
something
to
a
database
or
read
stuff
from
the
database
and
that
you
know,
and
that
will
influence
the
way
that
you
design
your
functions.
A
You
don't
need
to
call
them
and
they
will
do
something
and
at
the
end
they
will
probably
produce
another
event
that
another
function
can
use,
building,
event-based
functions
and
using
canadian,
something
that
we
will
be
showing
here
like
with
thomas.
It's
pretty
easy,
it's
pretty
natural
and
straightforward,
and
it's
also
integrated
into
the
platform.
So,
when
you're
building
these
kind
of
functions,
you
also
need
to
rely
on
the
platform
providing
some
constructs.
So
you
can
wire
functions
together
and
then
you
end
up
in
building
these
event-driven
applications.
A
Where
you
know
you
have
functions,
creating
consuming
events
emitting
events
and
other
functions.
You
know
reacting
to
them
and
by
that
you
just
create
like
more
complex
logic
and
more
complex
behaviors.
So
what
I
wanted
to
show
now,
it's
basically
expanding
on
the
demo.
That
thomas
showed
I
want
to
use
something
that
we
call
in
canada
with
the
funk
cli.
So
this
is
another
cli
provided
by
the
kn80
project
that
basically
allows
you
to
start
building
functions
from
from
scratch
right.
So
I
will
just
do
here.
A
So
if
I
go
to
that
directory,
what
I
can
do
is
I
can
use
the
func
cli
just
to
run
this
command
and
in
this
case
again
I'm
choosing
go
as
language
because
we're
in
kubecon
we,
I
guess
that
everybody
is
familiar
with
go
but
again
here
is
where
you
can
just
choose
java.
You
can
use.
You
know
the
net.
You
can
use
node,
rust
and
all
the
things,
and
here,
like
the
template
here,
the
last
http
that
I'm
I'm
calling
here.
It's
basically
the
interaction
way
right.
A
I
want
to
send
an
http
request
to
my
function,
so
it
can
do
something.
I
can
also
choose
like
the
cloud
event
based
approach
for
listening
to
events.
If
I
want
to
what
I
have
here,
if
I
open
this
into
my
ide,
is
just
the
template,
like
the
initial
template
for
a
function
where
I
can
just
go
there
basically
and
code,
my
business
logic
right.
A
So
let
me
show
you
quickly:
how
does
that
look
like
this
is
pretty
simple
code.
It
also
has
like
a
test
already
like
a
unit
test
there.
So
you
don't
forget
about
writing
tests
and
it
basically
tells
you,
like.
You
know
every
time
that
you
you
get
a
request,
then
this
is
kind
of
where
you
need
to
write
the
logic
for
that
request,
and
I
will
say
hello:
kubecon
from
a
function
today
is
my
birthday.
So
this
is
my
birthday
gift.
A
So
we
can
see
what
happens.
Let's
see
if
this
works.
The
first
thing
that
it
asks,
of
course,
because
we
are
going
to
containerize
this.
We
need
to
push
this
to
a
docker
registry,
and
I
will
be
using
thomas
here,
thomas
registry,
in
github,
container,
registry.io
and
then
yeah,
that's
his
registry.
We
have
already
the
credentials
configured
for
that
registry
and
what
funk
is
going
to
do?
A
Basically,
here
is
it's
going
to
use
pacquiao
buildbacks,
as
he
showed
before,
just
to
understand
in
which
language
this
function
is
created,
create
a
container
for
it,
and
then
we
are
going
to
push
that
container
to
you
know
to
to
github
container
registry.
In
this
case,
you
can
see
that
it's
installing
go
there
in
the
container.
It's
going
to
download
all
dependencies
that
my
function
needs
create
a
container
with
different
layers
and
then
push
that
to
a
registry.
A
We
are
building
kind
of
like
different
layers
for
different
use
cases,
so
the
developer
experience
is,
it
gets
easier
and
easier,
and
in
this
case
we
are
using
the
function
programming
model
in
order
to
make
it
like
way
easier
again,
just
using
a
function,
cli
just
get
stuff
up
and
running.
While
this
is
running
I'm
just
pushing
now,
I
think
they're
pushing
to
the
repository
yeah
that's
pushing
to
the
repository.
A
It
should
take
a
couple
of
more
seconds,
but
it's
important
to
understand
that
what
we
are
building
there
in
funk
in
the
in
the
functions
project
inside
canada
is
also
an
experience
where
you
will.
You
might
have
developers
that
doesn't
have
docker
installed
in
their
laptop.
So
all
this
building
process
can
also
happen
remotely
in
the
cluster
right,
so
I
can
trigger
this
build
process
remotely.
It
will
use
tekton
in
the
cluster.
If
you
have
tecton
installed
in
the
cluster,
it
will
use
tecton
and
it
will
build
and
deploy
everything
remotely.
A
So
you
as
a
developer,
just
work
with
go
and
start
the
function
locally
play
around
with
it
and
when
you're
ready,
you
trigger
the
build
lock
remotely
and
it
will
deploy
to
the
deployment
there
in
the
cluster.
So
now
it's
just
deploying
the
function
into
the
cluster
and
then,
as
you
can
see
here,
we
have
the
url,
which
is
of
course,
the
thing
that
we
just
created.
So
if
I
do
an
http
request
here
for
that
function,
I
should
be
able
to
get
the
function
that
I
just
built.
Yep
yeah.
B
That
was
really
great,
so,
if
you're
wondering
what's
happening
in
the
cluster,
so
how
we
are,
how
are
we
deploying
this
I'll
quickly
show
you
that
developer
friendly
abstraction
I
mentioned
earlier,
so
what
func
and
also
the
kn
cli
does,
is
creating
these
11
lines
of
yaml
so
where
you
just
define
the
container
port,
the
image
name
and
then
canadian
takes
care
of
the
rest.
So
what
we
achieved
so
far.
Let's
recap.
B
A
Well,
yeah,
so
quick,
quick
mentions
about
like
the
canadian
functions
products
right
like,
as
I
show
you,
I
just
created
a
function
from
scratch.
You
usually
will
not
do
that
like
I
was
creating
a
game
creating
different
levels,
and
I
can
quickly
create,
like
a
template
like
a
more
advanced
template
that
connects
to
radius
and
do
more
things
pretty
easily
like
from
a
remote
repository.
We
support
multiple
languages
and
frameworks,
as
I
we
said
before,
you
can
also
run
the
function
locally.
A
That
will
basically
start
the
docker
container
locally
if
you
want
to
play
around
with
it
for
a
bit
I
mentioned
the
on
cluster
builds
and
we
are
working
on
defining
what
1.0
for
this
project
means
and
that
will
probably
go
out
this
year.
So
if
you're
interested
in
contributing
to
this
project,
please
reach
out,
because
there
are
tons
of
things
that
we
need
to
do
there,
and
I
think
that
it's
a
pretty
easy
project
to
get
started
with,
because
you
know
no
matter
the
language
that
you
know
you
will
be
able
to
help
there.
B
B
We
can
use
func
deploy
so
now
the
two
operations
that
earlier
I
did
manually
with
the
pax
cli
and
the
k
and
cli.
Now
they
are
combined
and
taken
care
of
by
func,
deploy
and
once
again
the
image
will
be
run
as
containers
inside
the
cluster.
I
get
the
url
back
and
that's
really
great.
I
get
auto
scaling.
I
didn't
have
to
write
any
docker
file,
any
yaml
file,
but
still
we
have
something
missing
because
we're
talking
about
serverless
and
functions,
we
mentioned
event-based
applications,
so
we
should
talk
a
bit
about
events.
B
So
the
first
thing
we
talk
about
events
we
are
in
this
cloud
native
world.
We
are
in
a
kubernetes
cluster.
Events
really
can
come
from
many
different
sources,
so
the
first
problem
we
need
to
solve
is
how
we
exchange
those
events
across
different,
possibly
very
different
systems,
and
one
of
the
cncf
projects
solves
this
problem.
B
Cloud
events
is
a
specification
to
define
how
we
exchange
data
in
the
cloud,
and
this
is
for
interoperability
reasons,
so
it
doesn't
matter
the
technology
or
the
stack
that
we
use,
but
we
can
always
understand
and
exchange
cloud
events
and
we
have
a
standard.
We
have
a
standard
in
the
cloud
to
do
event-based
architectures.
B
This
is
how
a
cloud
event
look
like.
We
have
some
metadata
that
we
use,
for
example,
to
route
those
events
in
different
systems
and
the
data,
so
the
payload
could
be
anything.
It
could
be
a
json
object,
but
you
could
even
wrap,
for
example,
amqp
messages
that
you
use
in
your
rabbitmq
cluster
or
kafka
mqtt.
B
So
it's
really
a
powerful
concept.
So
it's
not
a
protocol.
It's
a
a
format
for
exchanging
this
data
in
the
cloud
as
events,
but
then
you
can
use
whatever
protocol.
You
want
cloud.
Events
is
the
base
for
k-native
eventing.
This
is
another
component
within
the
k
native
project
that
allows
to
build
event-driven
architectures.
B
We
have
a
few
different
features
here.
Once
again,
we
have
very
developer
friendly
abstractions
that
show
we'll
show
in
a
second,
we
can
build
these
event-driven
architectures
and
the
project
itself
takes
care
of
routing,
so
we
have
a
broker
obstruction
and
then
we
could
plug
any
kind
of
event
source
that
we
might
have
it's
polyglots
support
with
different
technologies
and
languages,
because
it's
based
on
cloud
events.
B
So
as
long
as
we
understand
cloud
events,
then
we
can
interact
with
the
system.
It's
plugable,
as
I
said.
So,
if
you
have
your
rabbitmq
cluster,
your
kafka,
you
can
have
events
coming
from
a
twitter
stream,
for
example,
or
from
slack.
You
can
do
that
as
well,
because
through
this
abstraction,
then
we
talk
cloud
events
across
the
entire
system
independently
from
what
is
the
specific
technology
we
are
using
at
the
lower
level.
Once
again,
this
is
cloud
agnostic,
so
it
runs
on
any
kubernetes
cluster.
You
don't
need
to
have
canadian
serving
to
use
k-nativ
banting.
B
B
B
The
k
native
broker
then
can
collect
and
route
events
across
different
sources
and
destinations
and
within
the
cluster
we
identify
the
destinations
or
the
listeners
via
triggers.
So
if
we
want
to
create
a
function
listening
to
some
events,
we
use
the
google
funcreate
again,
but
this
time
we
also
specify
a
trigger
so
that
this
function
should
listen
to
specific
events
and
then
again
we
can
use
the
language
that
we
want
cloud.
A
Let's
do
a
quick,
like
review
of
the
architecture
that
it's
pretty
simple,
but
at
the
same
time
we
have
learned
some
very
good
lessons
by
just
building
it,
and
I
think
that
the
main
lesson
for
us
is
like.
If
you
are
not
used
to
build
function
based
applications,
then
you
again
need
to
start
changing
the
mindset.
We
have
a
very
simple
architecture
and
we
build
kind
of
like
the
idea
of
a
game
where
you
can
just
add
as
many
levels
as
you
want.
So
it's
pretty
dynamic
on
the
front
end.
A
The
front
end
can
support
as
many
levels
as
we
want
as
soon
as
you
have
a
user
interface
and
then
each
level
is
a
function,
as
we
mentioned
before
the
interactions.
The
interactions
between
you
know
the
front
end,
and
the
functions
are
very
basically
driven
by
this.
You
know
orchestrator
component
in
there.
A
In
order
to
be
able
to
have
you
know
the
response
back
in
the
user,
there
are
techniques
to
avoid
doing
that,
of
course,
but
we
wanted
to
keep
it
really
really
simple
to
see
how
that
kind
of
works
out
can
when
we
all
play
here
together
and
what
we
did
next
is
because
again
we
have
event
like
and
we
have
canadian
eventing
installed.
We
can
expand
the
the
you
know:
the
application
to
start
basically
emitting
events
and
consuming
events
for
a
more
reactive
experience.
A
So
we
what
we
did
is
we
built
a
leaderboard
that
we
will
be
putting
in
the
screen
here.
That
is
consuming
events
that
are
being
created
by
all
the
you
know,
every
level.
Every
time
that
you
finish
a
level
you
are
going
to
be
sending
a
cloud
event
to
a
broker,
which
is
again
one
of
these
routers,
and
it's
going
to
be.
You
know
we
have
a
trigger
defined,
so
we
can
send
you
know
the
event
back
to
the
user
interface
and
inside
the
user
interface.
We
are
using
a
socket
to
propagate
that
event.
A
Back
to
my
browser
right
in
this
case,
you
need
to
connect
and
route
things
across
different
components,
so
I
can
get
you
know
kind
of
like
push
notifications
on
my
side
and
we
will
get
those
in
the
screen
in
a
bit.
So
by
building
this
we
can
wire
these
cloud
events
and
we
can
route
these
cloud
events,
for
example,
to
other
functions
or
if
we
for,
for
example,
we
want
to
get
rid
of,
like
writing,
synchronously
to
redis.
We
can
have
another
function
that
picks
these.
A
You
know
score
events
and
then
do
like
the
writes
in
an
asynchronous
fashion
as
well,
so
it
gets
kind
of
like
quite
complex
and
we
are
aiming
to
have
this
example
for
you
to
run
in
your
own
laptops
or
in
your
own
clusters.
If
you
want
to
because
at
the
end
of
the
day,
we
are
kind
of
like
using
the
same
concepts
again
and
again.
A
And
then
we'll
have
some
fun
and
then
we
will
just
be
playing
all
together.
The
idea
here
is
that
again
every
time
that
you
play
with
the
with
the
game
that
basically
will
mean
that
there
is
a
function
instance
being
created
on
the
back
end,
and
we
can
just
see
that
kind
of
like
in
real
life,
but
we
also
be
able.
We
will
be
also
getting
like
all
the
cloud
events
here
in
the
leaderboard
that
we
will
be
showing
in
the
screen.
But
first
we
will
just
share
this.
A
B
A
A
A
Yeah
there
you
go
so
if
you
open
that,
if
the
qr
code
doesn't
work,
you
can
enter
that.
You
know
url.
It
should
take
you
to
the
same
place,
apologize
for
not
being
able
to
show
the
leaderboard,
but
the
wi-fi
it's
not
working
as
we
expected
it
was
working
before
you
all
entered
the
room.
Yes,
you
can
imagine.
A
A
You
see
all
those
cloud
events.
Are
you
folks
just
playing
there?
So
I
think
that
again,
like
just
to
recap
a
little
bit.
We
just
try
to
build
a
platform
where
the
main
construct
is
a
function.
We
show
that
in
the
architecture
when
you're
building
this
kind
of
applications,
if
you
are
doing
sync
functions,
you
need
an
orchestrator
to
define
which
function
to
call
next,
but
you
can
also
build
event-driven
applications.
Look
at
those.