►
From YouTube: OCB: Serverless Functions - Overview and Demo with Naina Singh and Lance Ball (Red Hat)
Description
Developers need access to services faster, deploying backend services, platforms or applications can be time-consuming and tedious. This also means developers should not be restricted to any certain language or framework but also to create business value quickly and enhance services by way of FaaS i.e. Function as a Service that can scale a small unit of custom code while depending on other third-party/backend services.
Red Hat Openshift Cloud Functions (OCF) is a FaaS - Function as a Service that can be deployed on Openshift and is based out of Knative - a FaaS project in the Kubernetes community. It will enable developers to run code without needing to know anything about the underlying platform specifics.
Learn more: https://developers.redhat.com/products/cloudfunctions/overview
Speakers: Naina Singh (Red Hat) and Lance Ball (Red Hat)
Host: Karena Angell
A
Hello
and
welcome
everybody
to
serverless
tuesday
this.
Actually,
if
you
didn't
catch
the
session
right
before
this
one,
the
developer
experience
office
hours
on
openshift
tv
was
a
getting
started
with
serverless
on
openshift.
So
if
you
didn't
catch
it,
please
go
back
and
watch
the
recording.
It
was
great,
and
today
we
have
for
this
session.
We
have
serverless
functions
on
openshift
and
nina
sings
here:
she's
product
manager
for
serverless
functions
and
lance
ball.
A
B
B
A
C
B
C
Today's
talk,
so
many
of
you
may
already
be
familiar
with
the
concept
of
functions
from
products
such
as
aws,
lambda
or
microsoft.
Azure,
and
many
of
you
may
also
be
wondering
wait.
What's
the
difference
between
serverless
and
functions,
I
thought
they
were
kind
of
the
same
thing.
That
is
a
common
misconception,
and
would
you
like
to
add
your
thoughts.
B
B
So
I
don't
know
what
do
I
mean
when
I
say
that
you're
going
to
find
out
stay
tuned?
The
talk
in
the
demo
will
hopefully
help
clarify
all
the
difference
between
the
two
of
those
things
and
help
you
get
started
with
your
first
function
on
openshift
serverless.
So
let's
just
dive
right
in
you
want
to
take
it.
Nana.
C
Yeah,
so
let's
set
up
our
agenda
for
today
so
as
we
were
saying,
functions
and
several
last
are
not
exactly
the
same
thing.
So,
even
though
those
two
things
are
often
conflated
so
in
this
presentation
we'll
talk
about
what
exactly
serverless
is
and
why
you
should
care.
So
with
that
foundation
in
place,
we
will
then
spend
some
time
looking
at
what
functions
bring
to
the
table
with
our
serverless
product.
C
What
is
all
this
serverless
stuff?
So
in
a
nutshell,
as
lance
mentioned,
we
see
serverless
as
a
deployment
model
and
what
does
it
mean
for
you?
Then
it
takes
away
the
hassle
and
routine
work
of
provisioning,
maintaining
and
scaling
the
server
infrastructure,
and
on
top
of
that,
it
also
gives
you
the
automatic
scale
up
and
down
as
needed
so
we'll
go.
We
will
go
into
the
details,
so
openshift
is
a
red
hat's
distribution
of
kubernetes,
like
I
mentioned,
as
with
most
of
the
work
that
we
do
at
red
hat.
C
Our
projects
are
typically
based
on
standardized
open
source
projects
and
openshift
is
no
different.
In
fact,
serverless
is
no
different
in
serverless
case.
The
oss
projects
that
we
are
talking
about
are
k,
native
and
cloud
events
and
finally
for
functions.
We
have
added
some
additional
capabilities
on
top
of
knativ
to
offer
functions,
focused
programming
model,
and
if
it
sounds
too
much
like
mumbo
jumbo,
don't
cover
we'll
cover
them
soon
enough,
and
hopefully
there
will
be
more
clarity
around
that.
D
C
C
It
also
provides
a
flexible
declarative
api
that
allows
technology
like
k-native
to
abstract
away
kubernetes
further
to
offer
the
serverless
model
that
we
are
going
to
talk
about
today.
We
all
know
that
kubernetes
is
in
widespread
use
today
across
the
enterprise
technology
ecosystem
and
as
new
things
develop
across
kubernetes
landscape.
We
at
red
hat,
stay
engaged
and
involved,
and
this
brings
us
to
object.
C
C
The
second
important
thing
is
the
stateless,
because,
for
the
most
part,
state
is
handled
by
other
services,
which
makes
the
auto
scaling
easier
and
faster,
as
I
have
mentioned
couple
of
times
so
far,
the
scale
on
demand-
and
that
is
what
I
consider
the
pinnacle
of
serverless-
is
the
on-demand
auto
scaling
which
is
based
on
not
on
your
pre-calculated
resource,
but
on
your
demand.
So
it
lets
you
utilize
your
resources,
efficiently,
the
distributed
and
elastic.
C
So
we
all
know
that
in
this
era,
modern
applications
suffer
from
the
new
challenges,
such
as
being
always
on
the
high
availability
and
and
all
these
things
need
to
happen
on
the
global
scale,
and
for
that
software
solutions
need
to
be
distributed
on
multiple
infrastructures
and
also
need
to
be
elastic
enough
to
do
so,
and
serverless
applications
could
possess
these
qualities
event.
Driven
now,
I
believe
the
heart
of
serverless
is
its
event-driven
nature,
which
also
makes
the
apps
elastic.
C
So
if
we
think
about
it
at
its
most
simple
form,
a
task
needs
to
be
performed
when
a
request
comes
in.
So
if
we
design
our
solutions
using
this
pattern,
our
solutions
becomes
loosely
coupled
using
events.
It
makes
our
solutions
reactive
and
be
able
to
respond
in
real
time,
and
then
serverless
makes
them
scale,
depending
on
the
demand
and
in
the
middle,
is
the
cloud
native
that
makes
it
all
possible
and
ties
it
together
for
for
serverless.
C
C
It's
not
only
just
one
object
with
lassie
ammo,
but
with
the
added
benefit
of
auto
scaling
based
on
demand
as
your
resources
permanently,
and
you
don't
even
have
to
deal
with
the
amole
if
you
don't
want
to,
because
the
k
native
comes
with
a
cli
which
can
be
used
to
build
your
serverless
applications
for
for
kubernetes,
since
we
have
mentioned
k
native
so
many
times
so
far.
So,
let's
see
what
is
k
native
again,
k
native
is
what
brings
serverless
to
kubernetes
and
the
modules
that
lets
abstracts
away.
C
C
The
second
construct
is
eventing.
This
is
the
infrastructure
that
sends
and
receives,
events
that
triggers
the
applications
available
as
k
native
services,
and
the
third
construct
is
our
cli.
This
is
a
command
line
that
allows
you
to
interact
and
make
it
easy
to
create
resources
and
connect,
served
applications
with
events
or
requests.
C
So
another
oss
project
that
we
mentioned
makes
service
possible
is
the
cloud
events.
So
events
are
the
key
for
event,
driven
architecture
and
this
architecture,
as
we
already
mentioned,
could
solve
lots
of
modern
day
challenges
which
raises
the
need
for
consistent,
accessible
and
portable
events
across
different
components
of
your
solutions
and
cloud
event.
Is
that
a
specification
that
tackles
this
problem
by
defining
a
common
way
for
cloud
native
applications
for
seamless
integrations?
C
So
I
would
look
at
them
as
like
nothing,
but
a
wrapper
around
your
message.
That
makes
the
event
understandable
by
all
the
components
of
your
cloud
native
solutions
across
different
infrastructure,
and
this
leads
us
directly
into
the
serverless
functions,
work
that
we
are
doing,
and
I
would
let
lens
take
over
from
here
so
lens
all
yours.
B
Okay,
so
that
was
great
nana
and
I,
like
the
last
slide
that
you
ended
on
with
the
cloud
events
and
talking
about
the
event-driven
architecture.
I
mean
that
it
really
is,
I
think,
a
huge
part
of
what
k-native
is
all
about
and
serverless
is
all
about
and
when
you
think
about
event-driven
architecture
functions
are
the
sort
of
unit
of
compute.
That
really
seems
to
make
the
most
sense
in
a
lot
of
ways,
and
so
what
we've
done
is
we've
taken
k
native
and
we've
augmented.
B
It
extended
it
to
provide
some
sort
of
function-like
services.
So
you
as
a
developer,
can
write
just
a
function.
You
don't
have
to
worry
about.
You
know,
opening
up
network
connections
that
sort
of
thing:
it's
not
a
full-on
application,
just
a
function
so
the
pieces
of
that
are.
I
guess
next
slide
the
function,
the
funk
cli.
So
you
know
we
do
everything
upstream
in
open
source.
So
we
have
this
project
called
funk
and
it
allows
you
to
create
function.
B
Projects
build
function,
function,
projects,
deploy
them,
delete
them
that
sort
of
thing,
and
it
can
also
be
used
as
a
compiled
in
plug-in
in
the
k-native
kn
cli,
and
so
that's
what
we
do
in
the
openshift
serverless
distribution,
you,
you
use
the
kn
cli
and
that's
what
I'll
be
showing
you
today
upstream.
As
I
said,
it's
it's
called
funk
and
it
behaves
exactly
the
same
way
except
it's
just
not
prefixed
with
am
okay,
so
we've
got
this
cli,
the
other
piece
of
the
pack.
B
The
the
thing
is
build
packs
and
if
you're
not
familiar
with
build
packs,
you
should
get
familiar
with
them.
The
build
packs
are
a
cncf
project
designed
to
make
the
creation
of
oci
container
images
easy,
simple,
reusable
cacheable
scalable.
So
we
embrace
this
technology
for
our
functions.
Project
and
we've
created
a
number
of
build
packs
for
the
various
runtime
platforms
that
we
support.
Node.Js
python
well
python's
in
the
works
golang
and
java,
both
quarkus
and
springboot,.
B
B
Remember
serverless
is
a
deployment
model
and
functions
is
a
programming
model,
so
we're
going
to
see
a
little
bit
of
both
of
that,
let's
start
with
the
creation
of
a
function
project
so
next
slide.
Please
I'll
show
you
all
of
this
during
the
demo,
but
just
some
little
diagrams
here,
because
I
always
enjoy
creating
diagrams.
B
When
you
create
a
project,
it's
really
easy
using
the
cli,
kn
font
create
and
built
into
the
function.
Cli
are
some
templates
for
easily
getting
started
with
your
application
or
your
function,
and
it
just
creates
a
function
project
for
you
in
a
direct
once
you've
got
your
function.
Project
built,
I
mean
created
you're,
going
to
want
to
build
it,
and
that's
our
next
slide.
B
The
k
native
cli,
the
next
slide.
There
we
go
yeah
the
k-native
funk
cli
takes
the
function,
project
and
cncf,
build
packs
matches
those
all
together
and
you
end
up
with
an
oci
image.
Now
you
probably
recall
or
already
know
that
kubernetes
is
all
about
running
container
images.
So
this
is
what
we
end
up,
deploying
to
our
cluster
again
using
the
k-native
cli,
with
the
funk
plug-in
and.
B
B
So
what
does
it
look
like
when
it's
on
the
cluster?
As
I
said,
we
built
and
augmented
k-native
for
this
project,
and
so
once
you,
your
function
is
deployed
as
an
image
into
the
cluster.
It's
really
nothing
much
other
than
a
k
native
service,
a
few
minor
differences,
but
basically
it
behaves
just
like
a
k-native
service
would
in
any
k-native
deployment.
B
So
what
that
means
is
that
your
function,
just
like
any
other
service,
can
send
and
receive
cloud
events.
It
can
have
a
trigger
connected
to
a
canadian
event
broker
or
directly
to
an
event
source
or
you
can
send
events
to
you
know
a
specific
sync,
whether
that
be
a
service
or
the
broker
okay,
so
I
kind
of
described
all
of
that
talked
about
all
of
it.
Maybe
it's
time
that
we
have
a
demo
before
I
jump
into
the
demo,
can
can
you
bring
up
the
next
slide
nina?
B
I
just
want
to
show
a
little
picture
here.
So
if
you're
familiar
with
the
openshift
developers
console,
this
might
look
familiar
to
you.
What
you've
got
here
is
a
few
k
native
services,
3k
native
services,
connected
to
a
broker
the
little
lines
connecting
them
to
the
broker
represent
triggers,
and
then
we
have
an
event
source
on
the
left
hand,
side
that
we're
we're
using
camel
k
for
this
is
what
we
want
to
get
to.
Hopefully
we
will,
by
the
end
of
the
demo,
but
we're
going
to
start
really
small.
C
B
B
B
B
Let's
look
at
that
and
see
what
it
looks
like
index.js
has
a
few
different
functions
in
it,
the
main
one
that
we
care
about
here
is
this
invoke
function,
and
this
is
the
function
if
we
go
down
to
the
bottom
module.exports
equals
invoke.
So
this
is
the
function
that's
exported
from
our
index.js
file
and
the
function
that
ultimately
is
invoked
when
it's
deployed
into
the
cluster.
B
As
you
can
see,
it's
not
really
doing
much
here.
It's
just
looking
to
see
whether
or
not
it's
an
http
post
or
an
http
get
request
and
then
calling
one
of
these
functions
handle
poster
yeah
and
we
can
actually
do
an
npm
install
and
run
this
thing
locally.
So
npm
run
local
and
I
can
then
go
over
here
to
my
browser.
B
B
And
it
asks
me
for
a
registry:
it
needs
to
store
the
image
that
it
creates
somewhere.
So
I'll,
say:
docker,
dot,
io,
slash
lance
ball,
and
this
is
the
image
registry
that
I'm
already
logged
into
that's
important.
So
it's
building
this
image
and
then
I
can
run
that
image
locally
as
well.
If
I
just
use
the
kn
func
run
command,
that
image
will
run
locally
as
a
docker
container
because
sometimes
or
an
oci
container
image,
because,
let's
just
do
it.
B
Sometimes
it's
important
to
see
it
running
in
the
context
that
it
will
be
within
the
cluster,
so
kn
funk
run
will
do
that
for
you,
and
we
can
see
again
that
it's
now
running
here
and
I
can
go
back
over
to
firefox
and
do
the
same
thing,
but
that
this
time
it's
running
in
a
container
all
right,
but
that's
kind
of
a
trivial
example.
I
guess
I
was
going
to
show
you
that
when
you
create
the.
B
B
There
are
a
number
of
different
flags
that
you
can
provide,
so
you
can
specify
a
run
time
and
that
runtime
can
be
go,
node,
quarkus
or
spring
boot.
At
this
point,
python,
as
I
said,
is
in
the
works
you
can
specify
a
trigger,
and
this
is
where
you
would
say
I
would
like
to
you
know,
use
an
http
event,
a
http
function
or
an
event
driven
function.
B
B
It's
using
camel
k,
it's
logged
in
to
telegram-
and
this
is
my
telegram
client
over
here
on
the
right
hand,
side
and
I've
got
three
different
functions
that
I
want
to
use
to
process
images
on
this
telegram
event
receiver.
So
the
telegram
bot
will
receive
an
image
from
telegram
and
construct
a
cloud
event
out
of
that
and
send
it
on
to
the
k-native
broker.
B
The
broker
will
has
three
different
functions.
The
first
one
here
is
receiver
and
receiver
will
take
the
message
from
telegram
determine
if
there's
an
image
attached
to
it
process,
it
download
the
image
and
send
it
along
to
the
second
function
called
processor,
which
will
send
that
image
to
the
microsoft
faces.
Api
have
the
faces:
api
analyze,
whether
you
analyze
a
little
bit
about
about
the
faces
in
the
image
that
it
finds
and
then
responds.
B
B
Camel
k
or
the
camelet
telegram
bot
thing
running:
let's
go
ahead
and
start
with
our
functions,
so
the
first
function
that
we
have
is
the
receiver
right.
The
receiver
is
a
function
written
in
go
so
I
can
do.
I
can
look
at
handle.go,
that's
where
the
function
is
defined
and
we
can
see
here.
This
is
the
handle.
It
handles
a
cloud
event.
So
what
it
receives
from
the
function
invocation
is
a
context
and
the
cloud
event,
and
then
it
speaks
to
the
telegram
api
and
receives
the
image
messages.
B
Bigger
receiver
events-
and
these
are
message
so
that's
the
cloud
event
type.
The
type
is
a
required
attribute
for
a
cloud
event:
okay,
so
that
that
has
deployed,
and
we
can
actually
click
on
this
link
and
see
it
deployed,
but
because
it's
receiving
cloud
events,
it's
not
going
to
mean
much,
but
we
can
see
it
here
floating
around.
It's
not
connected
to
our
broker.
I
can
do
that
here
with
this
little
ui
and
drag
this
arrow
over
here
to
create
a
trigger.
B
So
this
is
my
receiver
trigger
and
if
we
go
back
over
here
to
the
terminal,
we
I'm
sorry
to
the
console.
We
can
now
see
that
my
function
is
connected
to
the
broker
and
the
telegram
event
source
is
connected
to
the
broker,
sending
events
that
way
all
right.
So
let's
go
back
over
here
and
we're
gonna
deploy
the
other
two
functions,
just
one
right
after
the
other.
Let's
look
at
the
processor.
B
B
B
Now
we
can
see
that
the
the
second
function
the
processor
has
been
deployed.
It
has
no
revisions
up
and
running
yet
that
should
happen
pretty
soon,
but
the
trigger
is
already
connected
to
it
and
if
we
click
on
that
trigger
there,
we
can
see
that
it's,
it's
filtering
for
cloud
events
coming
from
the
broker
of
telegram
dot
image.
So
the
way
this
works
is
telegram
event
source.
I
send
a
message
through
telegram
this
event:
source
processes
that
message
and
turns
it
into
a
cloud
event,
sending
it
to
the
broker.
B
The
event
type
is
telegram.message,
which
our
receiver
is
has
instructed
the
broker
that
it's
listening
for
and
the
receiver
responds
with
a
an
event
of
type
telegram
dot
image
which
goes
right
back
to
the
broker
and
the
broker
knows
that
the
processor
is
interested
in
telegram
images.
Okay.
So
the
last
thing
that
we
have
is
the
responder.
B
B
One
thing
I
did
want
to
point
out,
though,
is
what's
interesting
about
this
particular
function,
is
that
it
does
some
asynchronous
processing
in
the
background
that
is
talking
to
telegram
and
it
doesn't
need
to
respond
with
an
event
or
anything
like
that.
So
when
the
broker
invokes
this
function,
it
can
return
immediately
with
http
204,
no
content
and
then
go
on
and
about
its
work
and
responding
to
telegram.
So,
let's
deploy
this
thing,
while
that's
happening,
I
can
go
over
here
and
deploy
the
responder
trigger.
B
B
B
D
B
B
Oh,
this
is
a
friendly.
Looking
old
guy,
let's
see,
what's
going
to
happen,
okay,
we
can
see
that
the
telegram
event
sources
sent
the
it
received
that
image.
It
sent
a
cloud
event
to
the
receiver,
which
is
spinning
up
that
responded
with
an
event
of
type
image.process
which
caused
the
processor
to
start
to
spin
up
and
then
finally,
the
responder
will
spin
up
after
the
processor
has
finished,
making
its
calls
to
the
microsoft
api.
B
Now
this
is
one
of
the
issues
that
you
do
need
to
think
about
when
you're
dealing
with
functions
and
serverless
applications
as
a
whole
because
of
the
whole
scale
to
zero
model-
that's
built
into
it.
Philosophically
you
do
have
a
potential
startup
time
when
those
functions
have
all
stay
scaled
down
and
that
startup
time
can
sometimes
take
a
couple
of
minutes
here.
So
we
can
see
now
that
quarkus
has
started
up.
B
B
B
I
found
one
face
in
the
image:
clearly
a
surprised
face
so
now
all
of
these
things
are
have
already
been
spun
up.
So,
let's
see
if
we
can
send
a
few
more
pictures
and
get
a
quicker
response
back
yeah.
So
that
was
much
much
quicker
and
you
can
see
that
it
found
15
ac
faces
in
the
image
and
is
guessing
at
some
of
their
attributes.
D
B
B
B
D
C
B
Okay,
okay,
so,
as
nana
mentioned
earlier,
you
know
pretty
much.
Everything
that
we
do
at
red
hat
is
built
on
upstream,
open
source
technologies,
and
that's
how
we've
approached
this
project
as
well.
There
was
not
a
community
around
this.
Initially
we've
started
to
build
out
this
project,
and
hopefully,
if
you're
interested,
you
are
more
than
welcome
to
get
involved.
B
B
Build
packs
are
the
next
thing
that
we
have
up
on
our
github
organization
boson
project,
and
these
are
build
packs
for
each
of
the
runtimes
that
we
currently
support.
So
that's
another
area
that
you
could
get
involved
if
you're
interested
and
then
finally-
and
this
is
this-
is
actually
a
much
bigger
project.
This
is
the
cncf
cloud
events
project
and
we're
intimately
involved
in
a
lot
of
the
language
frameworks
for
cloud
events
in
the
upstream.
B
I
personally
maintain
the
sd
javascript
sdk
javascript
framework
here,
and
we
are
always
looking
for
contributors
in
this
area.
We'd
love
to
see
cloud
events
grow
and
become
widely
adopted.
We
think
it's
a
great
way
to
interconnect
all
kinds
of
managers
managed
services
across
a
kubernetes
cluster,
and
so
I
guess
with
that-
that's
that's
it.
A
D
B
I'm
I'm
looking
forward
to
some
pretty
exciting
projects.
I've
really
been
into
this
thing
called
open,
adsb
lately,
which
is
basically
transponder
for
radar,
detecting
planes
in
your
local
area
and
receiving
events.
Based
on
that-
and
I
don't
know
doing
something
interesting-
I
think
you
can
also
do
some
really
cool
stuff
with
home
automation
as
well.
B
C
A
E
Yeah
yeah
sure
sure.
So
so
we
have.
I'm
sorry
excuse
me.
So
we
have
a
lot
of
the
suburban
demo
around
absolutely
quarkx
and
how
to
bring
your
java
application
to
serverless
world
using
km
func.
Just
like
the
lens
showdown,
and
then
we
got
some
more
use.
Case-Based
servers
demo,
for
example,
how
to
build
your
upfront,
an
application
based
on
quarters
and
a
back-end
application
like
a
distributed
data
grid
based
on
infinite
span,
and
then
you
can
showcase
how
to
scale
out
the
front-end
and
back-end
from
auto-scaling
capability,
but
also
serverless
application
capability.
E
So
this
use
case
maybe
showcase
for
more
enterprise
reality
and
then
the
goal
of
the
serverless.
You
can
adopt
to
serverless
behavior
any
application
anybody's
domain,
because
any
application
should
be
running
all
the
time
because
the
it's
a
cost
saving
and
then
also
the
end
user
on
demand
behavior
as
well.
So
you
can
adopt
the
serverless
architecture
and
capability
and
behavior
into
any
application
on
your
products,
environment,
and
we
have
a
lot
of
doubles
demo
and
then
we
are
more
than
happy
to
help
you
out
to
reach
out.
I
mean
the
serverless
world.
A
A
A
B
B
B
C
It's
a
cncf
incubating
prod
incubation
project.
At
the
moment
it
was
started
with
pivotal
and
heroku
so
yeah,
but
it's
it's
now.
It's
now
community
and
I
believe
all
the
other,
gke
etc
are
also
using
buildpack.
So
it's
a
really
well
known
technology
to
create
oci,
container
images,
and
that's
one
of
the
reasons
we
we
chose
to
go
with
buildpacks
for
our
functions,
offering.
C
D
A
B
That
is
a
good
question.
Somebody
I
think
nana
you
mentioned,
you
could
have
a
a
single
pod
running.
You
could
set
your
scale
to
one
minimum
scale.
To
one
I
mean
I
think
that
does
defeat
the
serverless
sort
of
proposition
in
some
ways.
You
ideally
would
like
zero
computer
resources
being
used
when
there's
no
activity
on
that
function,
and
so
that's
something
that
we're
giving
a
lot
of
thought
and
consideration
to.
We
don't
have
you
know
the
the
perfect
answer
at
this
point.
B
D
C
But
if
there
is
something
mission,
critical
and
it
doesn't
apply
to
just
functions
like
any
container
that
you're
running
at
a
serverless
or
k-native
surface,
if
you,
if
it's
a
mission,
critical
and
you
really
really
need
it-
then
there
is
a
configuration
option.
But
yes,
there
is
no
permanent
option
that
we
have
found
so
far.
That
lets
us
go
through
skill
to
zero
and
then
still
does
not
take
that
much
initial
time.
But
we,
we
are
definitely
looking
into
different
kind
of
stuff,
but
we
haven't.
B
B
A
All
right,
let's
see,
oh
thanks
for
putting
the
demo
sources
there
too
lance.
I
just
saw
that
in
chat.
That's
awesome,
I
know
so
great
greg's
asking
about
the
annual
subscription
model.
This
is
probably
something
that
you
know
as
a
whole.
People
ask
about
for
openshift,
but
you
know
super
bowl
type
event
where
you're
scaling
up
right
so
nina.
Do
you
think
about
this?
And
you
know
as
your
dev
previewing
functions
and.
C
F
C
Yes,
at
least
it
makes
the
question
yeah
okay,
so
I
don't
have
answer
for
you
right
now
like
how
the
annual
subscription
model
can
can
do
this,
but
the
way
I
see
it
like,
for
example,
if
you,
the
openshift
serverless,
comes
with
the
openshift
right,
so
it
could
use
all
the
all
the
resources
that
you
have
purchased
in
openshift
to
do
the
scaling
or-
and
my
understanding
might
be
off.
So
I
need
to
come
back
to
you,
but
that's
how
I
was
thinking
about
it.
Lance
do
you
have
more
info
on
this.
D
A
C
A
E
Yeah
yeah
absolutely
sure
yeah
thanks
for
that,
yeah
devconf
will
be
online,
absolutely
and
then
the
middle
of
february,
the
february
17,
18
and
19,
and
there
are
a
ton
of
great
topic
and
also
there
are
around
the
suburbs
topic
the
lenses,
and
I
we
have
a
separate
topic
around
the
suburbs
like,
for
example,
the
lens
will
be
speaking
as
serverless
functions,
cli
to
cluster
in
three
minutes.
I
love
that
topic
so,
which
means
you
can
deploy
and
create
this.
E
The
serverless
function
project
in
three
minutes
from
local
to
the
remote
kubernetes
cluster
like
openshift,
and
I'm
gonna
talk
a
little
bit
about
the
caucus
like
a
caucus
funky
how
to
make
you
dance
in
a
summerless
flower,
because
the
developer
always
thinking
about
a
make
my
function
or
my
microservice
application,
make
it
more
flexible
and
affordable
in
the
multiple
platform.
I
don't
want
to
change
every
single
time
whenever
I
deploy
my
application
to
multiple
platform,
along
with
the
hybrid
cloud
strategy
or
multi-cloud
strategy.