►
From YouTube: Node.js in a Kubernetes World - Michael Dawson, IBM
Description
Speakers: Michael Dawson
From public to private Cloud and even on the Edge, Kubernetes is becoming the dominant deployment environment. As an application developer the good news is that it provides the framework needed for you to more easily support microservices deployments provided you do a few things in your application. However, In this new environment tooling is important so that you don't have to add kubernetes/docker expert and maintainer to your list of daily activities.
Come learn how to make your Node.js application code ready for Kubernetes deployments and how to leverage tooling to help you share management of the infrastructure components within your organization so that your life is easier when operations comes calling asking for help.
A
Okay,
so
I
think
it's
11
o'clock
and
it
looks
like
the
people
coming
in
is
slowed
down,
so
I
think
I'll
get
started.
So
welcome
to
my
talk.
I'm
Michael,
Dawson
and
today,
I'm
gonna,
be
talking
to
you
about
nodejs
in
a
kubernetes
world
a
little
bit
about
myself
before
I
get
started.
I'm
Michael
Dawson
on
my
BMS
community
lead
for
nodejs
and
what
that
means
is
I
get
to
spend
a
lot
of
time
working
in
the
community
I'm
on
the
technical
steering
committee
and
active
on
a
lot
of
the
different
working
groups
and
teams.
A
It
also
means,
though,
that
I
get
to
work
with
some
really
good
teams
within
IBM
working
to
do
some
cool
things
like
make
sure
I
be
a
make.
Sure
no
js'
runs
on
our
platforms,
s/390
PowerPC,
as
well
as
our
cloud
teams,
making
sure
that
you
know
they're
a
great
place
to
deploy
nodejs
as
well
as
some
other
things
which
I'll
get
into
so
just
before.
I
get
started
a
little
bit
to
let
you
know
what
I'm
gonna
talk
about.
I'll
start
out
with
ibm's
java
javascript
involvement
and
kind
of
little
bit
on
our
strategy.
A
Taking
a
look
at
and
learning
more
about.
So
to
start
with,
IBM's
involved
in
nodejs
in
a
number
of
different
ways
were,
of
course,
very
active
in
the
community.
We
have
11
core
collaborators
for
people
in
the
technical
steering
committee
and
we
really
try
to
invest
in
the
community
to
make
sure
node
is
a
great
platform
to
develop
on,
as
I
mentioned
before,
we
work
hard
to
make
sure
that
you
get
good
node
support
on
our
platforms.
A
We
also
want
to
make
sure
that
when
you
deploy
to
the
cloud
either
public
or
private
cloud,
it's
a
great
environment
to
deploy
those
node
applications.
We
also
work
on
developer
enablement,
so
making
sure
that
when
you're
developing
your
applications
you're
efficient
and
when
you
deploy
to
production,
you're
successful
and
then
finally,
we
offer
commercial
support.
So
when
you're
a
production,
we
can
help
you.
A
So
when
you
think
about
cloud
native
development,
one
of
the
things
you'll
often
hear
about
is
twelve
factor
applications
and
you
can
go
read
more
about
the
the
different
aspects
of
that,
but
it's
basically
a
set
of
tenants
that
you
want
to
follow
in
developing
a
modern
application.
Some
of
them
that
are
specifically
relevant
to
what
I
want
to
talk
to
you
today
about.
Are
you
know,
keeping
development
staging
and
production
as
close
as
possible?
A
You
want
to
test
where
you're
going
to
be
deploying
treating
logs,
basically
just
the
streams
and
exporting
services
via
port,
so
you'll
see
that
some
of
that
comes
back
through
the
talk
in
terms
of
the
key
tasks.
I'm
gonna
talk
about
these
things
in
terms
of
a
what
as
a
new
node,
gist
developer,
you
need
to
think
about.
So
one
is
like
well
I'm
gonna
have
to
be
building
darker
docker
images.
So
what
do
I
need
to
know
about
that?
A
I'm
then
gonna
have
to
deploy
those
docker
images,
both
from
my
own
testing
and
in
production.
I'm
gonna
need
to
figure
out
how
I'm
gonna
test
them
in
those
environments
and
kubernetes
brings
with
it.
Some
key
qualities
of
service
that
you
want
to
do.
They
do
some
work
on
your
application
to
support
so
things
like
health
checking,
logs
metrics
and
then
finally,
I
wanna
before
I
get
into
toolings
I
also
want
us
to
think
a
little
bit
about
upgrades.
A
What
happens
when
I
need
to
upgrade
my
application,
because
that
ends
up
being,
as
you
become
more
and
more
successful,
a
big,
a
bigger
part
of
the
work
that
you
actually
have
to
do.
I
just
have
some
references
to
cloud
native,
GS
/.
Here,
that's
a
site
where
there's
some
best
practices,
tools
and
techniques
for
writing.
Applications
in
JavaScript
that
are
going
to
be
deployed
in
a
cloud
native
environment
and
I'm
gonna
be
touching
on
some
of
those
tools,
so
I
just
have
the
the
reference
there.
A
So
the
very
basic
step
is,
you
know
the
first
difference
is
I'm
gonna
likely
have
to
get
my
node
application
into
a
docker
image,
and
so
what
does
that
mean?
Well,
luckily,
the
community
actually
builds
some
base,
docker
images
that
already
include
node
for
you.
These
are
done
by
by
one
of
the
teams
and
fairly
quickly
after
a
node
release.
A
You'll
see
that
there's
new
docker
images
published
to
docker
hub
they're,
official
images,
they're
cross-platform,
they
support
you,
know
x86
s/390
power,
so
you
can
use
them
on
any
of
those
platforms
and
they're
named
based
on
the
name.
So,
for
example,
you
know
there's
one
for
twelve
thirteen
one
and
they
bundle
a
nodejs
binary
into
a
base
operating
system.
A
There's
a
few
variants
there's
the
base,
one
which
is
just
note
colon-
that
takes
a
Debian
image
and
bundles
node
into
it,
with
most
of
the
things
that
you're
going
to
need
to
build
and
run
your
your
node.js
application,
so
the
compilers
and
so
forth.
The
node
slim
version
is
the
minimal
package
that
you're
going
to
need
to
run.
So
it's
a
smaller
image
but
may
not
have
everything
that
you
need
to
say
build
your
application.
A
If
you
have
native
modules
in
it
and
then
finally,
there's
an
alpine
version,
which
is
if
you're,
really
focused
on
container
size.
Alpine
is
a
distribution
that
has
a
smaller
footprint
and
it's
you
know,
so
we
bundle
node
into
there
a
little
bit
of
a
caveat
that
that's
uses
a
different
uses,
a
different
G
Lib
C
or
like
the
the
C
base
library,
and
so
it's
maybe
not
tested
quite
as
well
in
the
overall
node
interest
as
the
others.
A
There
are,
of
course,
others
in
addition
to
the
official
repository
so,
for
example,
Red
Hat
ships,
a
couple
of
ubi
images
and
those
are
images
that
you
can
use
because
they're
open
source.
But
if
you
want
to
get
support,
you
can
actually,
you
know,
run
them
in
a
way
where
you
can
actually
be
supported
as
well.
A
So
once
you
have
your
doctor
image
or
wouldn't
you
have
your
base
image
that
you're
gonna
build
on
top
of?
How
do
you
actually
get
your
application
into
the
image?
What
you're
going
to
need
to
use
is
something
called
a
docker
file
and
in
the
picture,
how
here
I
have
the
very
simplest
docker
file
which
just
says
from
this
base
image.
So
that's
the
image
I'm
gonna
use
from
github
the
the
one
that
the
community
puts
out.
A
It's
telling
you
what
port
it's
going
to
use,
that's
informational
and,
in
this
case,
I
just
copy
a
server
dot
js2
into
the
container
at
the
root
directory,
and
then
you
give
it
the
command
which
says:
okay,
start
up
the
server
node.
Yes,
sir,
very
simple,
it
does
get
a
lot
more
complicated
than
that.
Of
course,
in
that,
if
you
just
you
know,
follow
the
the
sort
of
naive
approach
to
building
your
doctor
containers,
you
can
end
up
with
containers
which
which
are
much
larger
and
contain
a
lot
more
than
you
want
in
them.
A
A
You
know
need
to
think
about
and
understand
that
multistage
build
I,
don't
really
have
time
to
get
into
that,
but
I
just
wanted
to
make
you
aware
that
that
is
something
you're
going
to
need
to
think
about
and
understand
if
you
want
to
have
good
images.
Finally,
you're
gonna
push
that
to
the
registry,
and
then
you
can
run
and
test
under
darker
or
kubernetes
from
the
image
in
the
registry
in
terms
of
deploying.
A
So
how
do
I
now
get
that
docker
image
I
built
that
bundled
my
application
into
it
with
the
docker
file
now
I
want
to
deploy
it
so
that
I
can
actually
run
and
test
my
application
so
deploying
it
into
kubernetes
ends
up
being
at
least
to
start
with
writing
some
yamo
files.
So
you
have
to
write
some
files
and
say
here's
the
image
I
want
to
use
here's,
how
many
copies
that
I
want
to
run
and
here's
how
I
want
to
deployment
so
at
the
very
top.
A
On
the
right
hand,
side
there
I
have
a
deployment
yamo,
which
has
you
know,
basically
a
simple
deployment
that
says:
use
test
test,
1
colon
news,
my
image
name,
I'm
gonna,
pull
it
locally,
so
I'm
not
pulling
it
from
a
registry
and
I
think
I
said:
I
want
two
copies
of
that
to
run
so
you
have
to
start
to
learn
to
write
this
yeah
mol.
What
the
sort
of
language
is
to
be
able
to
say
I
want
a
deployment
unfortunate,
not
quite
that
simple
in
that.
Okay,
now
you
have
some
containers
running
now.
A
You
have
to
have
a
way
to
tell
people
how
to
get
to
them,
so
they
have
something
called
the
service.
So
you'll
write
a
service
llamo
which
says:
okay,
here's
how
you
connect
and
get
to
those
pods
and
it
will
load
balanced
across
the
number
of
instances.
You
have
that
still
doesn't
let
you
get
act
for
at
at
your
at
your
application
from
the
outside
world.
A
Yet
you
also
need
something
called
an
ingress
which
says:
okay,
I'm
gonna
come
from
the
internet
and
I'm
gonna
get
you
to
your
services,
which
will
then
get
me
to
my
pods.
So
you
can
end
up
writing
quite
a
bit
of
yeah
Mille
to
get
there,
and
so
that's
something
you
know
again.
You're
gonna
have
to
probably
learn
and
understand.
A
Luckily,
there's
something
called
helm:
charts,
helm,
charts
actually
just
bundle
those
files
together
into
something
which
is
more
more
easily
deployable.
So
having
written
a
deployment,
a
service
and
an
ingress
helm
charts
give
you
a
very
specific
structure.
You
can
run
something
called
Hellman.
It
it'll
give
you
the
structure
that
you
see
on
the
on
the
right
in
the
templates.
They
actually
have
template
template
at
implementation,
so
you
can
use
the
values
to
configure
it.
To
start
your
application.
A
You
can
also
do
what
I
did
for
my
example
was
to
just
copy
my
existing
deployment
service
and
ingress
files
into
the
structure,
and
then
you
can
easily
deploy
as
opposed
to
having
to
like
best
individually
start
the
deployment
start.
The
service
start
the
ingress
and
helm
kind
of
bills
itself.
As
the
package
registry
for
kubernetes,
you
can
go
there
and
say
helm
in
it.
A
particular
service
say
you
want
to
start.
A
Profanity
can
helmet
it
graph,
Anna
or
held
helm,
install
graph,
Anna
it'll
pull
down
what
you
need
start
it
all
up
and
you've
got
cameras
running
all
these
things.
More
recently,
you've
probably
heard
about
if
you've
been
looking
at
kubernetes
operators.
Operators
give
you
a
more
programmatic
control
than
then
then
simply
having
some
yeah
mole.
That
tells
you
how
you
want
to
put
together
your
application.
So
many
many
applications
are.
You
know
now
come
with
operators
which
are
things
you
can
write
your
own
code
to
use
the
kubernetes
api.
A
A
So
you
know,
we've
said
based
on
the
12
factors
that
we
want
to
keep
our
development
staging
and
production
as
close
as
possible,
and
in
particular,
if
we're
like
developing
on
you
know
Mac,
OS
or
Windows,
which
a
lot
of
our
end
workstations
are
well
we're
gonna,
deploy
on
on
docker,
which
is
basically
Linux,
it's
important
not
to
test
in
Windows
or
OS
X
and
then
deploy
a
great
directly
to
Linux.
So
we
actually
want
to
test
in
docker
or
in
kubernetes,
ideally
but
yeah.
It
just
strikes
me.
A
A
So
I'll
just
leave
you
thinking
about
that,
as
we
will
come
back
to
that
later
on
now,
I'll
get
into
a
few
of
the
services
as
sort
of
qualities
of
service
that
you
you
don't
quite
get
for
free
and
kubernetes,
but
as
a
node
application
developer,
you
can
do
a
little
bit
of
work
and
it
will
make
your
application
better,
a
better
fit
for
that
cloud.
Native
development.
The
first
two
are
aliveness
and
readiness
probes,
so
by
anding
and
by
adding
an
endpoint
into
your
application.
A
Kubernetes
can
automatically
figure
out
from
that
from
the
information
you're
giving
it.
When
should
I
restart
your
your
container,
you
know
something's
gone
wrong
in
the
container
you're
no
longer
responding.
It
will
help
you
figure
out
when
to
restart
that,
and
similarly
readiness
lets
it
figure
out
when
it
can
actually
start
sending
you
traffic.
A
If
you
think
of
the
case
where
I'm
gonna
migrate
from
one
version
to
another,
you
don't
necessarily
want
to
spin
up
your
new
versions
and
automatically
instantly
like
instantly
redirect
your
traffic,
because
they
may
still
be
maybe
connecting
to
the
database
doing
whatever
work
and
initialization.
They
need
to
do
the
first
time
and
if
you
start
directing
traffic
to
them
right
away,
those
transactions
are
going
to
wait
and
be
slower.
So
you
might
as
well
continue
to
serve
existing
transactions
until
they're,
ready
and
the
readiness
endpoint
lets.
A
You
tell
kubernetes
when
your
application
is
ready
to
actually
accept
traffic
for
liveness.
There's
three
probe
types
you
can
do.
Basically,
you
know
a
L
into
the
container
and
run
some
command.
You
can
do
an
HTTP
probe
or
a
TCP
probe
for
nodejs,
typically
HTT
probe
is,
is
the
most
common
you
are.
You
know
quite
often
already
have
an
HTTP
server
running
for
your
API
or
your
your
web
application.
A
It's
probably
it's
probably
more
than
just
a
simple
check
you
want
to,
but
think
about
what
in
your
application,
you
should
check
to
say
whether
I'm,
really
up
or
not,
and
on
the
the
side
here,
I
just
show
again
in
the
amyl
that
we
talked
about
you
know.
I
can
easily
add
this
live
in
this
probe.
That
says
it's
an
HTTP
probe.
A
The
path
is
the
live
endpoint
on
port
3000
and
you
can
say
well,
don't
start
checking
until
like
five
seconds
after
I
spin
up
and
check
every
10
seconds
likely
gonna
have
a
you
know
a
longer
period
than
not
I,
don't
know
a
minute
or
whatever
and,
as
I
said,
you
should
really
check
more
than
just
that.
Your
web
server
is
up
in
terms
of
readiness.
A
A
If
you
used
the
cube
cuddle
to
get
the
status-
and
you
can
see
here-
it
says
you
know
zero
out
of
one
or
ready
and
basically,
if
you
have
the
readiness
endpoint
until
you
respond
positively
it'll
stay
like
that
in
terms
of
it's
not
ready,
I'm
not
going
to
route
traffic
to
it
and
again,
on
the
right
hand,
side
I,
just
show
you
know,
I
can
add,
I
can
have
a
liveness
probe.
I
can
ever
read
in
this
probe
same
kind
of
configuration.
A
You
can
make
them
the
same
endpoint.
If
you
want
and
that's
you
know
how
you
would
add
them
in
as
I
mentioned,
you
probably
want
to
do
something,
that's
more
than
just
one
check,
so
we
do
have
a
module
on
cloud
native
Jas.
It's
called
cloud
health
which
lets
you.
You
know
it
provides
an
infrastructure
for
registering
things
that
you
want
to
check.
A
The
next
thing
to
think
about
is
logging.
That
may
be
a
little
bit
different
in
the
kubernetes
environment.
So
can
containers
are
ephemeral
in
that
you
know
the
the
twelve
factor
approaches
like
you're,
not
gonna,
have
state
in
your
container
make
sure
you
could
kill
them.
They
can
go
away
at
any
time.
So,
unlike
other
environments,
you're
not
going
to
be
writing
your
logs
directly
to
the
filesystem.
In
most
cases,
you
might
be
able
to
do
that.
A
If
you
actually
remote,
you
know
you
can
mount
volumes
in
to
pause,
they're
shared,
but
if
you
think
about
a
large
deployment
across
a
whole
bunch
of
nodes
and
a
whole
bunch
of
pods,
you
can
think
that's
gonna
get
pretty
hard
to
manage
in
terms
of
keeping
those
shares
across
machines
and
knows
everything.
So
generally,
that's
not.
What's
done,
you
just
end
up
logging
to
standard
eight
and
you
let
the
infrastructure
handle
that
which,
actually,
as
a
developer,
is
a
little
bit
nicer.
You
just
need
a
simple
logger
which
will
log
to
standard
eight.
A
A
You
know,
you're,
you
know
log
in
at
different
levels
and
from
kubernetes
you
can
actually
say:
okay
queue,
control
logs,
get
me
the
logs
coming
out
of
a
particular
pod
and
then
there's
things
like
log
DNA
and
other
tools
that
will
like
in
cloud
environments,
pull
all
this
logging
together
and
give
you
a
view
across
all
of
the
pods
for
your
application.
So
the
nice
news
on
logging
is
maybe
it's
a
little
simpler
than
than
what
you
would
have
to
worry
about
in
other
environments.
A
The
next
thing
is
metrics
again,
you
have
a
container,
it's
not
as
easy
necessarily
to
get
into
the
container
to
find
you
know.
Maybe
you've
got
a
60
100
containers
running
so
actually
going
into
each
container
to
get
data,
but
what's
going
on
can
be
a
challenge,
so
the
next
thing
you
want
to
think
about
is
providing
a
metrics
endpoint.
A
Luckily,
there's
there
there's
kind
of
a
standard,
that's
people
are
moving
towards,
which
is
Prometheus
and
it
defines
the
a
set
of
base
metrics
that
you
should
provide
and
there's
some
good
clients
and
no
clients
that
you
can
go
and
get
prom
client
that
metrics
metrics
Prometheus
that
will
actually
instrument
and
give
you
a
metrics
endpoint
pretty
easily.
You
should
think
about
not
just
you
know
you
get
the
default
metrics
almost
for
free,
because
those
those
modules
will
extract
them
and
give
them
for
you.
A
But
the
other
thing
is
to
think
about
what
does
your
application
do
that?
For
you
know
business
reasons
or
sre
reasons
you
should
be
exposing
so
think
about
what
other
metrics
you
can
add
and
again
the
you
know,
prompt
client
provides
a
nice
API
for
saying
here
are
my
additional
metrics
and
then
they'll
end
up
in
the
data
in
the
kubernetes
environment.
There's
already
tools
that
will
help
scrape
those
endpoints
collect
all
the
data,
and
you
know
it
took
me
an
hour
or
two
to
get
up.
A
You
know
through
helm,
installing
Griffin
and
some
stuff
to
get
nice
dashboards
where
I
could
create.
You
know
graphs
and
garlic
gauges
of
all
this
kind
of
data,
so
as
a
node
developer.
If
we
do
this
little
bit
of
work,
it
helps
on
the
other
side
when
people
want
to
actually
see
what's
going
on
then
I
at
this
point,
I
think
I
just
want
to
step
back
and
think
about.
Okay,
we've
talked
about
a
bunch
of
things.
A
What
about
upgrades,
because
I
find
at
least
in
real
life,
the
more
successful
you
are,
the
longer
you've
had
to
support
your
product.
The
more
and
more
upgrading
becomes
a
big
piece
of
your
work.
So
what
does
that
mean
if
I'm
developing
my
node.js
application
for
a
cloud
native
environment
so
kubernetes
actually
does
a
great
job
of
handling
the
updating
like
migrating
from
one
version
to
another
in
terms
of
like
I've,
already
got
my
doctor
images
and
I'm
gonna
move
from
version
one
to
version
two,
and
so
don't
really
have
to
worry
about
that.
A
A
Y
containers
can
end
up
being
I,
got
a
lot
of
containers
to
upgrade
and
that's
a
lot
of
work,
which
ones
need
to
be
upgraded.
What
versions
do
I
have
in
each
one
that
becomes
a
lot
to
to
manage
and
then
I
also
imagine
moving
to
another
team,
so
you
know,
we've
talked
about
these
endpoints
we've
talked
about
you
know,
building
docker
files,
running
yamo
files
and
there's
not
necessarily
a
standard
or
one
way
to
do
any
of
those
things.
A
A
How
are
we,
organizing
your
deployment,
artifacts
and
I,
do
think
like
consistency
through
documentation
can
help,
but
I
still
see
that
as
a
challenge
in
terms
of
you
know,
how
do
we
make
that
work
so
at
this
point
after
learning,
all
this
stuff,
I'm
kind
of
like
it?
What
like
do
I
really
need
to
learn
and
understand.
All
of
this
stuff,
because
really
I
want
to
focus
on
the
application
code.
That's
the
value
I'm
delivering
to
my
company,
not
you
know:
learning
Gamal,
not
learning
how
to
deploy
committees.
A
Now
you
know
in
a
small
company,
maybe
you're
the
one
person
doing
everything,
but
in
a
lot
of
cases
you
want
to
focus
on
your
application
and
having
to
figure
out
all
this
other
stuff.
It's
just
like
what
I
you
know.
Is
this?
What
really?
What's?
What's,
where
we're
going?
So
from
my
perspective,
we
want
to
figure
out
how
to
separate
the
concerns.
A
So
you
know
I
think
we
we
need
to
get
to
the
point
where
I've
got
the
stalker
image
and
somehow
I
can
build
that
efficiently
and
easily
and
embed
in
it
a
common
stock.
So
something
that
has
the
pieces
that
we've
all
you
know
the
developers,
the
architects,
the
operators
because
for
your
production
application,
probably
everybody
is
involved
in
trying
to
make
that
a
success.
So
we've
all
come
together.
We've
agreed
that
that
set
makes
sense
to
us
and
then,
when
I
build
my
specific
applications,
I
can
just
you
know,
focus
on
my
application
code.
A
On
top
of
that
now,
I
do
want
to
say,
like
we
want
to
have
consistency
where
it
makes
sense,
but
not
uniformity.
So
I'm
not
saying
we're.
Gonna
have
one
stock
and
we
always
use
that
one
stock.
We
want
to
be
consistent
where
it
doesn't
really
matter
to
the
you
know
to
the
particular
implementation,
but
not
be
uniform.
A
So
at
this
point,
I'm
like
okay.
Well,
let's
hope,
there's
some
tools,
and
the
good
news
is:
is
that
there's
a
few
open
source
projects
and
iBM
is
contributing
to
some
of
these
projects
that
are
aiming
to
try
and
address
this
particular
challenge.
The
first
one
is
called
op
City
it.
What
it
does
is
it
helps
you
build
those
docker
images
in
an
efficient
way
and
what
it
does
in
the
first
step.
The
first
part
is
to
say
well
for
my
local
development.
A
I
need
to
iterate
very
quickly
and
I
want
to
test
and
doctor,
but
I
don't
want
to
have
to
rebuild
my
doctor
image
every
time,
startup
docker
to
be
able
to
test
it.
So
what
it
does
is
it
takes
your
application
code
and
it
Maps
it
into
a
docker
image
and
then
there's
code
to
watch
for
changes
and
so
that
when
you're,
you
know
you're
developing
your
application
in
you
know
locally
on
your
machine.
A
It's
mapped
into
a
docker
container,
so
you're
testing
in
docker,
but
it
can
automatically
pick
up
your
changes
and
you
don't
actually
have
to
restart
docker
itself.
The
other
thing
it
does
is
it
uses
the
stock
model
to
say
we're.
Gonna
have
a
number
of
stocks
and
I'm
gonna
take
your
application,
so,
for
example,
Express
I'm
gonna
take
just
your
Express
components
and
layer
that
into
a
stock
or
a
doctor
image
that
we
can
use
to
do
that
testing.
A
Once
you've
gone
through
the
the
rapid
development
cycle,
you
can
then
say
build
which
will
then
build
you
a
docker
image
again,
the
advantage
being
you
don't
have
to
understand.
Multistage
doctor
builds
and
all
the
best
practices,
because
it's
going
to
be
bundled
into
the
stock
for
your
organization
and
then
you
can
even
test
it
in
kubernetes,
just
by
saying
absolutely
deploy
so
again
without
having
to
know
all
that
yeah
mole
and
stuff,
you
can
get
it
up
and
running
and
be
accessible.
A
Of
course,
we've
thought
about
nodejs
and
so
there's
a
number
of
stocks
that
are
available.
Pre-Made
stocks,
there's
no
GS,
no
just
Express,
no
just
loop
back
and
the
functions
one
I'm
not
going
to
talk
about,
but
we
do
have
a
talk
in
the
same
room
following
this,
where
Chris
Bailey
is
going
to
get
into
a
lot
more
detail
of.
If
you
want
to
do
serverless
type
programming,
how
can
you
do
that
using
App
City
and
some
of
the
benefits
and
so
forth?
A
A
This
is
just
my
very
simplest
Express
application
that
says
hello
world
now,
since
I
don't
have
a
lot
of
time,
I'm
not
going
to
go
into
the
particular
steps,
but
I'm
now
going
to
say
op
city
deploy
and
if
you
see
everything,
that's
going
by
you'll
see
a
lot
of
the
components
that
I
talked
about
in
that
it's
using
docker
to
do
a
two-stage
multistage
build
to
efficiently
build
you
a
docker
image.
It's
going
to.
A
3
0,
8,
8,
2,
yeah,
okay,
so
I
get
my
hello
from
op
City.
So
that
was
my
application,
but
because
the
stock
includes
support
for
liveness,
I
can
get
I
automatically
get
a
liveness
endpoint,
which
is
responding
for
me.
I
get
a
readiness,
a
readiness,
endpoint
and
I
get
a
metrics
endpoint,
so
basically,
by
using
that
stock.
A
lot
of
those
things
that
I
you
know.
I
talked
about
us
needing
to
worry
about.
A
Nodejs
developers,
we've
actually
built
that
into
the
base
stack
and
you
don't
have
to
worry
about
it
when
you're
doing
your
individual
application
itself.
So
let
me
just
switch
back
here,
so
that's
absentee.
The
next
thing
I
just
want
to
mention
another
open
source
project
is
code
wind.
This
brings
a
nice
UI
on
top
of
op
City,
as
well
as
some
other
things
like
integration
with
Tecton
pipelines,
some
performance
monitoring.
It's
a
bring
your
own
UI,
so
you
can
use
visual
code
studio
or
bring
your
own
editor.
A
You
can
use
visual
code
studio
kind
of
provides
that
next
layer,
if
you
like
to
work
with
user
interfaces
as
opposed
to
the
command
line,
cabin
arrow,
is
another
open
source
project
and
again
what
it
does.
Is
it
bundles
together
the
different
pieces,
along
with
some
curated
stocks,
so
we
talked
about
stocks
that
you
would
want
to
potentially
put
in
for
your
organization.
A
This
gives
you
some
curated
stocks,
which
we
expect
you
would
start
with
and
then
sort
of
customize
for
your
use
and
I'll
just
end
up
with
like
if
I,
if
you're
interested
I
don't
have
time
to
go
in
the
details.
But
of
course
there
is
the
talk
which
is
immediately
following
this
one.
You
can
also
come
and
see
us
at
the
IBM
booth.
We
have
some
quick
labs,
one
of
which
includes
getting
involved
in
hands-on
with
with
app
city.
You
can
of
course
come
talk
to
us.
We
have
a
nice
online
lab
75
minutes.