►
From YouTube: The Level Up Hour (E49): Getting started with Serverless
Description
Want to deploy a serverless application? Curious about how serverless can help get code into production faster? How do you pronounce ‘Knative’ anyway? This week Simon Seagrave and Naina Singh join us to talk about serverless functions. If you haven't started with Knative services then you don’t want to miss this episode. We’ll focus on Knative and how it will support serverless microservices in the future. Join us to dive into the topic of serverless applications and learn all about Knative.
Learn more:
https://www.redhat.com/en/topics/microservices/why-choose-openshift-serverless
https://developers.redhat.com/blog/2021/01/04/create-your-first-serverless-function-with-red-hat-openshift-serverless-functions
Follow us:
Scott McBrien https://twitter.com/stabby_mc
Randy Russell https://www.linkedin.com/in/randy-russell-0312243
Jaafar Chraibi https://twitter.com/ChraibiJc
What is the Level Up Hour?
Every Wednesday at 9am ET we stream live demos on how Red Hat Enterprise Linux (RHEL) users and admins can benefit their organizations and improve their careers by learning how to use containers, Kubernetes, and Red Hat OpenShift.
Learn more at:
https://red.ht/leveluphour
http://red.ht/3ayHlHI
How to participate in the The Level Up Hour:
Watch on YouTube every Wednesday at 9amET
Chat with us on Discord https://discord.gg/5VMVGJt
Check out our GitHub repo https://github.com/level-up-hour/
About OpenShift:
Red Hat OpenShift is an open source container application platform based on the Kubernetes container orchestrator for enterprise application development and deployment.
https://www.openshift.com/
https://github.com/openshift/
#RedHat #OpenShift #tluh
A
A
A
A
D
B
Good
morning,
good
afternoon,
good
evening,
wherever
you
might
be
welcome
to
the
level
up
hour
where
we
contemplate
containers,
consider
kubernetes
opine
on
openshift
and
we've
got
a
really
good
show
this
week.
We're
doing
a
few
new
things
here
in
terms
of
our
platforming.
So
apologies
for
our
late
start,
but
hopefully
things
will
get
off
to
a
smooth
start
and
we'll
learn
a
lot
today.
B
We're
talking
to
simon
seagrave,
principal
product,
marketing
manager,
naina
singh
principal
product
manager
and
roland
huss,
senior
principal
software
engineer,
and
we're
going
to
be
talking
about
a
topic
that
is
very,
very
much
a
hot
topic
these
days
and
that's
serverless
and
k-native,
and
so
first
of
all
greetings.
Thank
you
for
coming
on
our
guests,
and
I
also
want
to
welcome
back
the
man
himself,
jafar
chariby,
who
has
been
absent
for
a
while,
but
is
now
making
his
triumphant
return
to
the
level
up
hour.
D
B
A
Yes,
hi
everyone.
This
is
naina
glad
to
be
here
and
thank
you
for
the
warm
welcome
and
I'm
glad
that
you
picked
this
topic.
So,
as
you
said,
serverless
the
name
suggests
that
there
are
no
servers,
but
that's
not
possible
right.
So
what
it
actually
means.
I
think
in
that
context,
is
that
you
don't
have
to
worry
about
servers.
A
So
we
see
lots
of
definitions
of
serverless
today
right
and
the
snippets
of
code
known
as
functions
running
is
one
of
them.
So
let's
focus
on
how
red
hat
sees
serverless.
So
it
is
a
deployment
model
where
you
can
run
almost
any
container
or
functions
without
worrying
about
the
underlying
infrastructure
and
complexities.
A
The
additional
benefit
that
serverless
provides.
You
is
scaling
up
as
your
demand
increases
and
scaling
back
down
when
your
resources
has
been
ideal
enough
right.
So
these
serverless
apps,
if
you
will,
are
stateless
event,
driven
and
has
distributed
and
elastics.
So
in
a
sense,
what
red
hat
sees
is
that
the
serverless
is
a
feature
of
your
platform.
A
That
is
bringing
that
serverless
capabilities
to
the
kubernetes
right
and
then
phase
two
is
where
integration
and
state
comes
into
the
picture
where
you
can
use
all
kinds
of
integration
patterns
making.
You
write
all
your
applications
in
a
serverless
fashion,
as
well
as
integrate
with
your
other
codes
that
you
have,
because
we
understand
that
most
organizations
would
be
running
their
legacy
code,
monoliths,
modular,
monoliths
functions,
microservices,
so
on
and
so
forth.
So
you
choose
what
best
suits
you,
that's
how
I
would
define
it
roland
if
you
have
something
to
add.
A
E
Yeah,
so
actually
you're
you're
totally
on
the
on
the
right
tracks.
Actually,
serverless
is
really
something.
Okay,
serverless
is
a
nonsense
term
right,
it's
something.
It
talks
about
serverless,
serverless
but
of
course,
they're
behind
everything,
their
servers,
it's
shot
that
you
don't
see
it
and
server
is
really
coming
from
a
developer's
perspective.
So
it's
really
something
that
you
throw
over
your
code
that
you
have
developed
and
somewhat
somebody
is
operating
it
somehow
and
of
course,
there
are
many
ways
how
you
can
achieve
that
so
aws
london
does
differently
like
openshift.
E
Does
it
and
kubernetes
is
kind
of
a
little
bit
of
a
step
in
the
right
direction
so
that
you
really
can
really
throw
over
a
container
image
which
contains
your
code
and
then
it's
operated
in
some
some
way,
and
hopefully
you
don't
have
to
worry,
but
still
you
have.
You
have
access
to
the
cluster
somehow
and
in
some
sense
serverless
goes
one
step
further
to
say:
okay,
you
still
or
the
you
do
not
even
see
that
server
part
there
and
it's
completely.
E
You
have
a
you,
have
an
api
like
in
kubernetes,
but
it
still
makes
it
much
easier
to
deploy
your
applications.
You
don't
have
to
to
speak
around
with
low-level
infrastructure.
Things
like
like
volumes
or
other
stuff,
like
that,
it's
really
some
really
a
high-level
abstraction.
You
have
you
have
an
application,
and
you
want
to
to
to
run
that.
So
this
is
serverless
in
broad
terms,
and
there
are
even
more
specific
definitions
of
our
own
serverless.
E
The
cncf,
the
cloud
native
cloud
native
computing
foundation
has
also
created
a
serverless
definition,
which
also
goes
in
that
direction,
and
I
think
one
of
the
main
characteristics
for
the
serverless
that
we
are
talking
about
is
that
you
have
a
very
flexible
scaling.
You
can
scale
up
arbitrarily
based
on
traffic,
so
really
based
on
the
demand
of
your
application.
E
You
can
scale
up,
but
also
you
could
start
down
to
zero,
which
means
that
if
you,
your
application
is
not
used
at
all,
you
do
not
consume
any
resources,
and
you
don't
have
to
pay
any
money
for
that.
I
think
this
is
one
of
the
biggest
biggest
biggest
benefits
of
service
and
many
defined
servers
actually
with
this
characteristic
right.
B
C
C
Please
yeah,
so
what
would
be
interesting?
I
I
guess,
is
to
sort
of
understand
what
are
the
main
use
cases
or
patterns
that
brought
that
type
of
of
usage
and
and
patterns
as
serverless.
So
you,
you
explain
one
of
the
things
around
the
application
scalability
and
going
back
to
zero
to
save
resources.
C
A
So
I
would
say
that
at
very
simplest
and
at
its
core,
the
serverless
pattern
is
an
event
happened,
and
then
it
starts
your
app.
So
in
case
of
k
native
technology,
let's
say
it
would
be.
It
would
start
your
container.
That
container
will
process
your
request
and
the
result
will
be
produced
right
so
at
very
basic
of
serverless.
It
is
event
driven
the
event
happens,
your
app
comes
up
and
then
results
are
produced.
A
You
also
mentioned
about
the
real
world
use
cases,
but
let
me
let
me
come
back
to
that
one
so
because
of
its
that
basic
pattern,
all
serverless
apps
are
event
driven
in
nature
right
and
that's
where,
when
you
mentioned
that
does
it
does
serverless
works
towards
that
absolutely,
and
we
will
talk
more
about
that
one.
Let
me
get
back
to
the
real
world
use
cases.
We
even
have
a
questionnaire
that
we
have
prepared
for
our
customers
when
they
wanna
know.
Okay,
what
are
my
use
cases?
A
Where
can
I
use
serverless
right?
So
in
a
nutshell,
I
would
say
if
you
have
unpredictable
or
bursty
number
of
requests
right,
you
want
maximum
resource
utilization.
You
also
want
to
reduce
your
carbon
footprint.
Let's
face
it.
If
you
use
your
resource
to
the
maximum,
then
you
are
reducing
your
carbon
footprint.
A
You
want
to
work
towards
creating
event-driven
applications
and
k-native
would
provide
the
event,
sources,
channel
brokers
and
all
that
infrastructure
around
it.
For
you
to
be
able
to
comfortably
create
the
event
driven
architecture,
but
more
than
that
because
of
the
scaling
it
and
its
ability
to
provide
the
abstraction
layer
on
top
of
kubernetes,
you
can
also
try
different
deployment
strategies
such
as
like
a
and
b
testing
or
community
deployments
right,
and
your
seasonal
or
periodically
running
workloads
and
the
one
that's
my
favorite
is
let's
face
it.
A
C
A
C
This
is,
this
is
awesome
naina
and
if
I
can
speak
from
my
personal
experience,
I've
been
working
with
with
openshift
customers
since
we
embraced
kubernetes
so
almost
five
years
ago,
and
at
some
point
we
came
up
with
what
we
could.
I
don't
exactly
remember
what
was
the
the
feature
name,
but
you
had
the
ability
to
to
wake
up
an
application
when
the
route
was
accessed,
for
instance,
but
once
it
was
awakened,
there
was
no
way
to
scale
it
down
back
to
zero.
C
So
so
it
was
a
good
feature
and
it
was
already
you
know
you
had
to
manually.
I
I
don't
remember
the
name
but
make
the
application
sleep
and
at
some
point
when
it's
accessed
it
goes
back
online.
So
customers
liked
it
and
they
started
asking
okay
now
guys.
How
can
we
scale
back
to
zero
because
I
don't
want
the
application
to
remain
up,
and
then
we
started
thinking
about
like
looking
at
the
metrics
and
saying
okay.
C
E
It's
not
only
skating
down
to
zero,
but
also
it
can
detect
that
there's
a
burst
of
traffic
and
then
scale
up
immediately,
not
only
one
part
after
each
other,
but
all
will
be
many
parts
immediately
at
once.
So
this
is
also
something
where
their
kinetic
is
very
strong
and
exactly
this
kind
of
non-uniform
workload
state
like
this.
So
this
is
something
where
service
really
shines
and
helps
you
to
reduce
your
bills.
C
C
C
You
know
back
end
languages
in
in
most
enterprises,
and
it
couldn't
really
fit
well
with
this
notion
of
burstable
resources,
because
if
the
applications
takes
10
seconds
to
boot
or
20
seconds
to
boot,
even
if
it's
a
simple
rest
endpoint
that
needs
to
say
hello,
then
it's
not
going
to
be
compatible.
So
I
believe
red
hat
has
worked
towards
making
java
more
burst
friendly.
E
Exactly
so,
you
really
hit
the
point
here.
So
actually
this
is
we're
talking,
so
cold
star
is
really
an
issue
with
canada,
as
you
mentioned.
So
if
you
scale
down
this
here,
we
have
to
scale
up
at
some
point
in
time
and
of
course,
then
it
depends
how
long
the
application
takes
for
coming
up
and,
as
you
said,
java
is
notoriously
slow
in
this
respect,
and
luckily
there's
now
a
solution.
These
days
also
developed
by
reddit,
which
is
called
qualcos,
which
is
a
java
runtime
or
a
java
platform.
E
E
Application
rest
application
comes
up
in
10
to
20
milliseconds,
and
this
is,
of
course,
a
super
perfect
fit
for
canadian
serverless,
because
there
you
need
this
kind
of
quick,
upscale
and
also
quick,
downscale,
of
course,
and
there
this
elasticity
of
this
application
is
super
important
here.
But
but
you
have
also
to
be
aware:
it's
not
only
the
application
that
adds
to
the
code
start
time.
There
are
a
lot
of
other
aspects
as
well
like
scheduling
for
from
kubernetes,
like
the
the
cube
that
needs
to
start
up
the
container.
E
This
also
takes
some
time,
so
it's
a
kind
of
a
sum
of
different
portions
that
up
in
application
startup
time,
of
course,
is
very
important,
but
we
are
also
trying
now
at
the
moment,
we
have
a
focus
on
decreasing
the
other
components
which
adds
to
the
code
start
time
so
that
we,
so
one
of
our
goal
is
really
to
come
up
in
to
a
constant
time
which
is
below
one
second.
So
this
is
really
one
of
one
of
the
goals.
E
Of
course,
it
depends
on
the
application
itself,
but
actually,
if
you
consider
all
the
rest-
and
you
have
a
very
simple
application,
then
we
really
want
to
kind
of
not
guarantee,
but
actually
the
target
is
ready
to
get
below
one
second,
because
this
is
the
time
a
user
has
to
wait
when
it
scales
up
from
zero
to
one,
because
one
user
is
the
unlucky
guy
who
really
fires
up
the
application.
Again,
he
has
the
first
request
and
he
has
or
she
has
to
wait
until
this
application
is
up
and
yeah.
C
A
C
A
I'll
just
add
that,
like
you
mentioned,
because
the
the
serverless,
the
openshift
serverless,
which
is
based
on
k
native
so
ultimately
k
native,
that
brings
those
serverless
qualities
to
containers,
and
we
know
that
most
enterprises
are
still
using
java
right
and
java
is
coming
back
and
and
quarkus
has
a
huge
role
in
it.
One
of
the
disadvantages
of
those
functions
code
and
the
phases
that
we
were
talking
about
before
is
the
limited
choices
that
you
could
do
with
them
right
the
scale
up
and
scale
down
thing,
because
that
you
create
the
container.
A
So
the
flexibility
is
yours,
you
choose
what
you
want
to
work
with
and
we
will
bring
the
serverless
to
to
those
language
choices
that
you're
bringing
right.
So
another
teaser,
I
would
say,
is
we
are
working
towards
something
else,
and
we
are
going
to
talk
about
that
a
little
bit
in
a
later,
but
where
even
the
container
creation
would
be
the
construct
responsibility.
A
C
All
right
and
so
yeah.
Thank
you
very
much
guys
for
these.
These
comments,
because
yeah
it
brings
a
lot
of
useful
information
to
the
audience
and
just
to
touch
upon
this
notion
of
you
know,
being
able
to
to
burst
and
minimize
the
boot
time.
So
we
spoke
about
the
the
application
itself,
but,
as
you
you,
you
mentioned
the
when
you
deploy
the
application.
If
it's
spread
out
on
hundreds
of
nodes
and
pulling
the
images,
basically
is
the
first.
C
B
Well,
so
no,
we
are
not
nearly
done
hearing
from
you
jafar
and
we've
had
we've
had
a
few
teasers
put
out
here
now,
so
we
want
to
talk
a
little
bit
more
about
you
know
more
specifically
and
narrowly
about
red
hat
openshift
serverless
and
very
specifically,
you
know
things
like
serving
eventing
and
functions
and
what
what
that
actually
looks
like
within
red
hat
openshift
serverless,
because
we've
already
kind
of
gone
down
that
road
a
little
bit
with
some
of
the
discussion.
But
let's
explore
it
a
little
bit
more.
A
All
right
so
I'll
start
and
enroll
and
feel
free
to
chime
in
when,
when
you
feel
like,
I
misspoke
for
something
alright,
so
openshift,
serverless,
being
part
of
openshift
runs
everywhere.
Openshift
runs
right
and
is
included
in
the
openshift
subscription
k
native
is
the
upstream
project
that
it
is
based
off
in
the
red
hat
tradition.
All
of
our
products
are
based
on
upstream
right.
This
gives
you
the
portability
advantage
and
makes
the
hybrid
cloud
front
and
center
of
your
solutions
right.
A
So
if
we
are
gonna
talk
specifically
about
serving
and
eventing,
let
me
see
so
in
k
native.
It
hides
the
complexities
and
democratize
this
technology
by
using
some
some
modules
that
comes
with
it.
The
constructs
that
are
serving
that
you
just
mentioned,
so
it
allows
your
containerized
applications
to
deploy
sk
native
service.
That
is,
gives
you
the
serverless
qualities
and
auto
scale
or
scale
back
to
zero.
As
we
were
mentioning
and
these
all
these
services
that
you
deploy
are
request
driven
or
event
driven.
A
You
can
create
different
revisions
of
these
deployed
services,
which
lets
you
do
those
deployment
strategies
that
I
was
talking
about.
The
another
eventing
is
the
infrastructure
that
sends
and
receives
these
events
that
would
trigger
these
applications
that
we
just
deployed
using
the
k
native
service
and
the
cli
command
line.
That
allows
you
to
interface
and
interact
with
these
constructs,
to
make
it
easy
to
create
the
resources
doing
the
topology
of
your
architecture,
and
you
don't
have
to
deal
with
yaml.
A
E
E
I
think
three
years
old,
it
was
initiated
by
google,
but
now
there
are
many
companies
which
collaborate
on
on
kinetic
in
the
upstream
and-
and
it's
really
about
these
two
parts
so
serving
is
really
about
the
auto
scanning
part
and
about
the
the
revisioning
part
and
the
so
that
you
have
able
to
create
customized
rollout
strategies
and
in
the
inventing
part
of
the
the
part
for
the
event-driven
applications,
how
you
can
connect
those
there
are
brokers.
There
are
sources
that
import
events.
E
A
So
I
will
just
add
that
we
have
made
openshift
serverless
extra
special
because
we
added
the
serverless
functions
based
on
keynative.
This
is
in
technology
preview.
Right
now,
when
I
say
serverless
functions,
this
is
where
all
you
bring
is
your
code
and
all
the
other
worries
are
taken
care
by
the
construct.
We
will
give
you
the
scaffolding
of
the
project,
runtime
of
your
choice
and
then
that
would
give
you
the
jumpstart
to
write
your
code
and
the
construct
would
create
container
for
you
and
you
can
deploy
it
on
your
cluster
in
in
one
step
right.
A
We
also
provide
a
dev
console
experience
on
the
openshift
container
platform,
so
so
openshift
adds
a
lot
more
on
what
k
native
provides
and
this
functions
construct
that
we
are
talking
about.
We
have
recently
donated
it
to
the
upstream
k
native,
so
it
is
in
sandbox
and
incubation.
So
we
are.
We
are
extremely
excited
about
that.
A
C
A
It
just
struck
me
that
we
are
talking
to
the
ita
admin,
ops
audience
and
I
just
didn't
cover
the
most
important
thing
right.
So
it
provides
you
installation
experience
through
an
operator,
you
just
click
on
and
button,
and
everything
else
is
taken
care
of.
It
provides
you
automatic
updates
for
your
data.
A
E
Effort,
I
might
add,
of
course
you
can
automate
this
as
well,
so
everything
is
based
on
the
operator
lifecycle
manager,
which
means
the
standard
mechanism
that
you
create
a
subscription.
This
is
also
a
cid,
a
custom
resource,
so
you
can
everything
put
to
and
get
and
automatically
apply
that
so
you
don't
have
to
go
via
the
ui,
where
you
will
press
some
buttons,
but
you
can
just
custom
put
it
into
your
automation.
Scripts
in
terraformer
answers.
B
B
B
Is
it
something
that
maybe
you
first
need
to
plug
your
head
into
a
event-driven
applications
and
understand
that
sort
of
paradigm
before
you
get
into
serverless?
Or
is
it
something
that
you
do
as
part
of
getting
into
serverless?
Or
do
you
need
to
adopt
serverless
and
then
that's
going
to
allow
you
to
be
more
event
driven
just
sort
of?
Naturally
I
mean
how?
E
Yeah
yeah
yeah
too,
so
actually,
this
is
also.
Maybe
we
forgot
to
mention
so
kinetic
and
serverless
is
really
focused
on
a
special
kind
of
workload.
So
actually
everything
is
assumed
that
you
are
talking
about
stateless
workloads.
The
reason
why
it
needs
to
be
stateless
is
because
of
this
scaled-down
scale-up
facility,
because
you
have
to
you
lose
your
state
if
it
down
to
zero
and
therefore
you
have
to
externalize
your
state
to
some
extent
database.
E
The
status
servers
are
very
good
candidates
for
being
operated
with
serverless,
and-
and
so
you
have
to
think
about
on
that
angle
as
well,
and
also
it's
important
to
know
that
the
scaling
the
typical
the
auto
scaler
from
canadian
and
operation
service
is
based
on
traffic,
so
on
consumption.
So
it's
based
on
incoming
traffic,
so
it's
always
only
really
good
for
for
request,
driven
or
event
driven
applications
that
really
have
to
process
some
incoming
traffic.
E
A
E
A
Are
also
forgetting
to
mention:
is
it
it
requests?
It
serves
the
http
request
as
well,
so
you
don't
have
to
have
a
canadian
eventing
paradigm
like
you
have
to
have
kafka
or
some
kind
of
event
driven
thing
right.
You
can
have
your
application
that
is
just
going
to
be
exposed
to
as
an
http
endpoint,
the
rest
endpoint
and
the
canadian
serving
would
work
for
those
as
well.
A
B
B
C
C
You
know
refreshing
the
data
with
things
like
data
grid
or
regis,
so
so
the
time
to
access
the
data
is
much
less
than
if
you
were
directly
talking
to
a
database,
for
instance,
to
pull
the
data
whenever
the
rest
endpoint
needs
to
serve
back
the
the
the
responses
so
yeah
you
can
have
different
levels
of.
I
would
say
evolutions
in
in
your
architecture.
C
You
can
bring
those,
I
would
say,
different
building
blocks
where
you
can
have
your
simple
rest
endpoint,
then
you
can
have
the
caching
stuff
and
yes,
caching,
services
to
to
sort
of
provide
the
stateful
and
externalized
stateful
pattern.
And
of
course,
once
you
you
go
into
more
sophisticated
things,
then
you
can
embrace
even
driven
applications
by
putting
things
like
kafka
into
in
in
play
into
the
the
global
architecture.
So
yeah,
it
depends
really
on.
B
B
E
Okay
cool,
so
actually
let
me
sit
a
little
bit
at
the
context.
What
I
have
here
now
so
actually
what
I'm
running
in
the
background
there
is
an
openshift
cluster,
so
the
server
is
not
visible,
but
it's
running,
of
course,
and
it
has
openshift
serverless
installed
and
what
we
are
trying
now
we
are
trying
to
create
from
scratch
an
application
and
we
are
leveraging
the
whole
all
components
except
of
eventing
from
openshift
servers.
So
you
start
with
a
function.
E
So
actually,
if
you,
what
you
see
here
now
is
an
empty
empty
directory,
and
there
you
see
kn.
This
is
the
kinetic
cli,
which
is
also
delivered
with
operation
serverless.
You
can
directly
download
it
from
the
administration
console
and
we
have
here
a
command
which
is
called
func
and
this
is
for
scaffolding,
an
empty
project
and
we
can
select
different
runtimes
or
languages.
So
in
this
case
we
are
using
node,
you
can
use
qualcos,
you
can
use
python
or
rust,
or
so
I
think
there
are
a
handful
are
supported
and
more
to
come.
E
So
actually
you
have
here
a
handful
function,
and
this
is
a
kind
of
really.
This
is
not
a
full
server.
This
is
really
only
a
snippet
of
code
and
this
is
evaluated
by
the
function
runtime.
So
this
is
a
little
bit.
You
can
imagine
this
like
lambda,
where
lambda
is
you
you
throw
over
your
function
code,
which
confirms
to
a
certain
api
or
a
signature
for
a
function,
and
then
it
gets
executed
by
the
lam
diarram
time,
and
here
it's
a
little
bit
the
same,
except
that
we
will
create
a
container
image
out
of
this.
E
So
what
if
here
now?
Here's
several
things?
Of
course
you
can?
You
can
manifest.
So
I
get
the
important
point
of
this
invoke
here,
which
is
called
by
the
by
the
runtime.
So
what
I'm
doing
now
is
I
just
modified
a
little
bit
you
see
here.
You
have
already
some
default
handler
for
get
in
the
post,
http
get
an
hd
post,
so
what
I'm
I'm
doing
now,
I'm
just
deleting
the
get
one
and
I'm
adding
my
own
one.
So
I
have
prepared
something
here,
which
is
looks
like
that.
E
I
can
go
into
this
little
code
snippet
as
well.
So
what
I'm
doing
here
is
I'm
just
importing
some
some
headphone
methods
for
sleeping
some
stuff,
creating
a
uuid
which
I
return
at
the
rest
service
and
what
I'm
creating
is
a
simple
rest
server
which
just
creates
a
random
number
and
returns
that
in
a
json
structure.
E
So
without
evaluating
any
any
queries,
of
course
you
can
examine
all
the
query
parameters
here
as
well.
If
you
like,
and
then
I
see
whether
the
environment
variable
sets
a
delay,
so
this
environment
variable
is
set
in
my
container
and
if
so
I
sleep
that
many
milliseconds
and
afterwards,
I'm
just
just
returning
this
json
structure
with
a
with
a
random
number
between
zero
and
one
thousand
and
then
the
id
and
then
some
some
other
fixed
labels
like
that,
so
this
is
kind
of
what's.
E
I
think
this
is
a
nice,
hello,
world
kind
of
application
that,
let
me
let
me
get
out
of
vi,
which
is
always
the
most
difficult
part
of
the
demo
okay,
so
we
now
have
the
kind
of
code
and
we
can
now
create-
and
we
can
now
build
this
one
so
with
cane
funk
build.
You
create
a
container
image
out
of
this
code
here,
and
this
leverages
build
packs
in
the
background.
So
but
you
don't
really
see
that
so.
E
First
of
all,
it
asks
for
for
them
extra
parameters,
which
is
where
it
should
store
the
file
image.
If
it's
pushed
and
now
it's
creating
this
image,
this
might
take
a
little
bit.
So
the
first
run
is
always
a
little
bit
slower
than
the
the
other
ones,
and
so
what
it
does
really
it
starts
the
buildback
it
has.
We
have
dedicated
build
picks
for
every
language
for
for
node,
for
qualcos
and
others,
and
there
is
in
this
build
packets
also
contain
the
the
boilerplate
to
call
your
your
functions
over
here.
E
In
this
case,
I
think,
there's
an
express
node
express
function
which
is
wrapped
around
this
code.
So
now
now
it
has
been
built
and
the
good
thing
is
now
you
can
all
try
this
now
locally,
like
with
this
run
command.
So
this
is
something
you
don't
need
any
cluster
for
that
it's
just
running
locally
here
and
then
it
will
tell
you
that
it
it's
running
here
on
localhost,
and
let
me
call
this
one,
and
you
see
here
some
some
debug
code.
E
E
You
have
quick
turnaround
times
for
your
for
development,
but
if
you
are
done-
and
then
you
want
to
try
out
your
code,
of
course
on
the
on
a
real
cluster
with
real
canadian
running
behind
that
so
for
this
to
do
you
just
need
to
run
the
same
thing
with
okay
and
run,
deploy
arcane
funk,
deploy.
Sorry-
and
here
in
this
case
it
really
again
built
the
function
image.
You
can
avoid
this
by
adding
an
option
like
minus
minus
minus.
E
No
build,
I
guess
or
skip
build
and
and
then
it
pushes
the
image
to
a
registry.
This
is
the
registry
that
you
have
specified
at
the
beginning
and
then
creates
the
connective
service
deployment,
and
I
I'd
like
to
ask
you
to
look
at
the
top
half
of
the
screen
where
you
see
the
pots
that
are
running
on
this
cluster.
So
at
the
moment
we
don't
have
any
pot
running.
E
So
this
is
one
so
every
time
you
you
install
a
connective
service,
it
just
creates
a
pot
at
the
beginning
just
to
check
out
whether
it
really
can
be
deployed
and
too
early
to
fail
early.
If
it
doesn't
isn't,
isn't
the
case,
so
it
always
scales
up
to
one.
If
you
deploy
you
can
you
can
tune
this
behavior,
of
course,
as
well.
So
now
now
we
have
this
deployment
now
I
can
just
use
this
url
and
again
curl
this
and
look
at
the
result,
and
you
see
now
it's
really.
D
E
Okay,
okay,
so
you
you
see
now
the
the
same
thing
but
now
reserved
by
the
cluster
itself,
and
if
I'm
continuing
to
talk
like
this,
then
you
will
see
that
after
60
seconds,
the
service
will
scale
down
to
zero
in
the
top.
So
then
the
pot
will
go
here
from
one
to
two
to
zero
in
the
case,
but
actually
for
the
sake
of
the
demo.
E
I
can
make
this
a
little
bit
faster,
and
for
that
I
can
use
a
k
n
again,
so
let
me
jump
to
the
top
of
the
screen,
so
I
can
see
better
here.
So
I
can
use
an
upside
first
of
all.
Let's
make
a
clean
service
list
and
you
see
that
we
have
a
service
which
is
called
demo,
which
is
the
same
name
as
the
directory
that
I've
created
and
and
we
can.
E
The
server
so
every
time
I
change
the
servers,
a
new
revision
is
created
and
I
can
see
all
their
revisions
like
with
this
list
here
like
that.
So
I
have
only
one
and
this
revision
gets
hundred
percent
of
the
track.
If
we
go
there,
I
can
now
make
an
update,
so
service
update
demo.
I
give
this
name,
and
then
I
say
I
want
to
make
here
and
we
change
some
parameters
which
influence
the
scaling
behavior.
E
So
in
this
case
I
want
to
say,
concurrency
limit
concurrency
limit,
actually
is
the
number
how
many
requests
in
parallel
a
pot
can
process
by
default.
This
is
100,
so
this
means
that
a
pot
like
the
one
that
we
have
seen
can
run
100
requests
in
parallel,
and
if
your
traffic
exceeds
this
number,
then
a
new
port
is
scaled
up
to
make
it
easier.
E
So
that's
a
quite
sophisticated
algorithm,
but
I
don't
want
to
go
into
more
details
here.
Okay,
now
we
can
see
the
revisions
like
that,
and
you
see
you
have
a
new
revision.
So
so
you
see
that
it's
like
really
that
every
time
you
make
a
change,
you
get
a
an
immutable
revision
and
you
always
can
switch
back
to
an
audio
vision.
This
is
very
nice
to
for
rolling
out
stuff
or
rolling
back
stuff,
even
in
this
category
100-
and
you
see
immediately
that
it
scales
down
to
zero
after
it's
been
started.
E
We
can
we
concur
that
and
then
actually
I
just
want
to
make
a
little
benchmark
test.
So,
in
this
case,
I'm
running
2000
requests
with
50
clients
in
parallel,
and
if
you
look
up
here,
you
see
also
immediately
that
not
only
one
product
has
started,
but
also
many
parts
at
once
that
we
are
really
about
to
serve
this
request,
and
actually
it's
already
done.
So
it
was
quite
quick,
even
if
it's
the
other
has
already
processed
that,
but
then
I'll
call,
of
course,
after
10
seconds
it
scales
down
again.
E
Of
course,
this
is
only
for
the
demo.
Typically,
you
have
a
much
much
longer
time
scale
for
that
for
sure
to
keep
it
more
more
stable
like
this,
and
you
also
see
that
it's
only
not
five
but
six,
and
this
depends
because
the
the
scaling
up
doesn't
happen
if
a
one
pot
is
really
full.
It
all
already
happens
by
default
after
seventy
percent,
and
then
it
scales
up.
So
this
also
happens
to
for
that.
You
really
have
a
smooth
transitions
upwards.
E
E
For
the
last
part
of
the
demo,
where
we
are
going
to
show
you
how
you
can
make
a
traffic
split,
and
I
will
explain
in
a
second
what
a
traffic
split
is,
but
let's
see
again
our
revision
list,
you
see
again,
you
have
a
new
revision
again,
which
is
originally.
You
can
always
also
see
the
details
and
what
the
solution
actually
really
contains.
But
now
I
give
this
revision
here
in
service
update
demo
minus
minus.
I
want
to
give
the
revision
one
a
name
attack
in
this
case.
E
E
Now,
let's
try
to
make
an
update
of
our
version
1
to
version
two,
but
we
we
want
to
make
kind
of
a
canary
release,
so
say:
okay,
we
do
not
want
to
roll
out
everything
to
version
two,
but
only
a
fraction
of
the
traffic
should
be
directed
to
this
version
too
and
typically
this
is
five
percent
or
three
percent
and
the
the
remaining
part
are
still
going
to
the
old
revision.
So
you
can
really
carefully
examine
the
your
new
revision
and
then
roll
out
200
for
the
new
revision
afterwards.
E
But
for
the
sake
of
the
demo,
we
make
a
50
50
split.
So
in
this
case
I'm
going
here
again,
I'm
making
service
update
demo.
So
I'm
I'm,
I'm
specifying
here
a
new
image
name,
so
this
happens
to
be
the
same
demo
implemented
with
qualcos
and
not
with
with
node.js
so,
but
I
already
have
prepared
that
so
this
has
already
been
pushed
to
docker
hub
and
it's
fetched
from
there.
E
But
of
course
you
can
use
any
image
and
by
the
way
you
don't
have
to
use
functions.
You
can
always
start
with
this
on
this
level.
So
there's
a
cane
service
create
as
well
and
just
specify
the
image
name.
So
this
is
the
easiest
way
how
you
can
deploy
an
application
and
then
the
interesting
part
comes
here
where
I
say:
okay,
I
want
50
of
the
traffic
to
the
v1
version
that
I
have
tagged.
E
E
So
you
see
again,
the
newer
vision
start
up
just
to
check
that
it
really
is
ready
to
serve,
and
if
I'm
now
running
my
curl
again
here
with
this,
you
will
see
that,
on
the
on
the
long
run,
you
get
a
50
50
distribution
of
your
thing.
So
in
this
case
I
get
again
version
one
from
the
node
one
time.
Now,
let's
try
the
the
other
again
the
same
command.
You
see
now
you
have
the
same
again.
Okay.
This
says
here
version
two
one:
oh,
but
okay.
This
is
something
yeah.
E
We
can
quickly.
Okay,
this
is
a
1.0.
Actually,
this
should
be
too
old,
but
never
mind.
You
see
that
there's
different
runtime
here
it's
caucus
and
also
a
different
format
of
your
id,
because
I
use
a
different
text
to
to
use
that
and
if
I
continue
like
this,
you
see
that
you
get
not
always
a
ground
robin,
but
actually
close
around
150
percent
like
that.
E
How
the
the
traffic
split
works
with
this
serving
and
to
be
honest,
actually
this
is
mostly
it.
So
actually
you
create
a
service,
and
if
you,
if
you
know
kubernetes,
you
know
to
to
get
your
application
deployed,
it's
not
only
that
you
create
a
deployment
for
kubernetes,
but
you
have
also
to
create
an
increased
object.
You
have
to
create
a
kubernetes
service
like
that.
This
happens
all
behind
the
scenes
by
deploying
this
kind
of
service.
So
there's
the
the
canadian
controller
take
this
connective
server
that
you
deployed.
E
E
It's
unfortunately
named
the
same
like
for
kubernetes,
but
you
have
a
different
api
group
and-
and
this
is
how
how
how
it
looks
like
so
actually
the
only
thing
that
is
really
needed-
that
you
have
to
specify
the
image
name,
everything
other
every
other
thing
is
optional
here
and
if
you
deploy
that,
then
the
controller
picks
it
up,
and
then
you
see
we
can
quickly
check.
If
you
look,
for
example,
get
the
group
control
service
or
the
humanities
service,
you
see
that
there
has
been
created
a
acute
control
service.
E
On
behalf
of
the
kinetic
service.
You
you
get
an
ingress
up
in
an
object.
It's
a
route,
you
get
in
route
objects.
Actually
I
have
well.
This
happens
in
a
different
name
space.
Unfortunately,
let
me
see
what
I
see
it
here:
no,
not
really,
okay,
but
actually
you
you
get
the
idea,
so
you
you
get
a
core
q
as
objects
created
on
behalf
of
a
creative
service,
and
you
only
have
to
care
about
this
creative
service.
So
this
is
more
or
less
my
demo
and
I
think
we
are
can
be
open
for
questions.
C
What
do
you
think
yeah
sure?
So
I
was
doing
a
show
this
morning
and
with
one
of
my
colleagues
natalie,
and
he
asked
me
so
jafar.
What's
your
best
advice
for
someone
who
wants
to
learn
kubernetes
or
openshift,
for
instance-
and
I
said
the
way
I've
been
always
doing
stuff-
is
I've
been
a
hands-on
guy,
so
I'm
always
looking
for
an
environment
and
tangible
practice
and
that's
the
only
way
I
can
learn
things
and
not
necessarily
by
reading
stuff,
because
it
doesn't
teach
you
how
how
things
work
actually
in
real
life.
C
C
C
A
C
30
days
open
shift
environment
there,
where
you
can
experiment
and
you
can
learn
and
practice,
so
I
would
say
yeah
whatever
works
for
you
is
best
and
we
are
doing
things
to
to
make
it
even
easier
for
people
to
embrace
that,
because
if
you
wanted
to
use
mini
cube
or
crc
or
whatever
you
you,
you
need
to
have
a
laptop.
You
need
to
have
a
container
runtime
available.
You
need
to
do
a
lot
of
you
know
pre-flight
stuff
to
make
it
work.
C
Now,
with
this
type
of
solutions,
all
you
have
all
the
prereq
is
a
web
browser
hit
your
web
browser
subscribe,
and
then
you
have
your
kubernetes
openshift
environment
and
you
have
much
more
than
what
mini
cube
can
can
offer,
which
is
all
the
the
openshift
ui,
all
the
components,
all
the
marketplace
that
we
offer
and
stuff
like
that.
So
yeah
long
answer
short
whatever
works
for
you
and
we
are
providing
environments
where
you
can
easily.
C
You
know
provision
your
own
openshift,
there's
also
learn.openshift.com,
where
you
have
a
lot
of
resources
that
gives
you
a
real
environment,
also
where
you
can
experiment
and
it
touches
upon
many
topics.
Devops
security
java
with
quarkx
serverless
service
mesh,
so
yeah,
I
would
advise
you
to
to
go
there
also
learn.openshift.com
and
then
check
out
the
the
the
different
tutorials
that
we
have
there.
So
I
think
it's
it's.
It's
pretty
useful.
Also.
B
Pitchmanship
here,
but
you
know,
as
the
director
of
certification,
I
do
have
to
weigh
in
and
say
that,
if,
if
you
have
the
the
ability
to
participate
in
sort
of
our
training
and
certification
offerings
that
we
offer
worldwide,
that's
a
great
way
to
actually
learn
about
about
containers
and
kubernetes.
Last
year
we
introduced
containers
as
a
must-know
topic
and
actually
our
core
linux
curriculum,
because
it's
become
something
that
you
need
to
know.
B
If
you're
going
to
be
that
that
linux
administrator,
but
then
we
have
a
whole
series
of
courses
and
yes,
certifications
that
are
focused
on
on
kubernetes
and
openshift,
and
so,
if
you're
looking
to
learn,
certainly
use
some
of
those
free
resources
that
jafar
mentioned
we're
doing
everything
we
can
at
red
hat
to
make
those
kinds
of
things
available.
But
if
you
really
want
to
condense
that
down
condense
down
the
trial
and
error
be
on
a
directed
path
to
learning
and
a
very
hands-on
path
to
jafar's
point.
B
Please
do
please
do
look
into
red
hat
training
and
certification
and
what
we
offer
there
for
for
for
learning
it.
It's
very
comprehensive.
It's
growing
we're
covering
things
not
only
like
open
shift
and
kubernetes,
but
we
are
also
covering
things
like
server,
mesh
and
corkus
and
all
of
these
sort
of
adjacent
technologies
that
are
all
part
of
that
big,
beautiful
hole.
So
with.
A
B
D
A
C
B
Really
did
illustrate
it
very
well
and
we
got
to
the
end
of
it
successfully
too.
So
yeah,
oh
great,
all
right,
so
I
am
going
to
have
to
kind
of
wrap
us
up
here
with
what
we
usually
close
our
shows
with,
and
that
is
the
sweet
sweet
internet
points.
So
I
just
wanted
to
announce
that
we
are
going
to
be
putting
the
sweet
sweet
internet
points
program
on
hiatus.
B
It
will
be
back
next
year,
bigger
and
better
than
ever,
but
we
are
putting
a
pause
on
it
for
now,
but
I
did
want
to
share
who
our
top
points
earners
are
and
those
are
knee.
Nih
acm,
which
I've
never
known,
how
that's
supposed
to
be
pronounced,
but
there
is
a
very
neck
and
neck
battle
between
that
watcher
and
narendev,
who,
I
think
led
the
way
for
well
for
for
a
very
long
time.
B
Noah
friction
bacon,
fork,
det,
conan
kudo,
joe
fuzz,
I'm
saying
all
this
with
a
very
straight
face
here.
You
know:
how
do
you
say
joe
fuzz,
with
the
straight
face
jp
dade,
mik,
31o
m
roach,
jp
dade?
Those
are
our
top
finishers
in
terms
of
the
points.
Thank
you
for
registering
for
that.
We
are
going
to
be
reaching
out
to
our
top
points,
our
earners
with
a
little
bit
of
free
swag.
B
Let
us
know
if
you
haven't
heard
from
us.
Thank
you
so
much
for
having
washed
and
participated
in
collecting
those
points
and
again
we're
going
to
revive
the
sweet,
sweet
internet
points
in
2022
more
comprehensively
better
than
ever.
I'm
told
we'll
see
so
with
that.
I
just
want
to
remind
everybody
also
to
share
like
and
subscribe.
Let
people
know,
though,
about
the
level
up
hour.
I
think
your
family
needs
to
know
your
friends.
You
know
it
has
been
shown
by
science
to
make
you
more
popular.
So
with
that.
Thank
you
all
our
guests.