►
From YouTube: Intro + Deep Dive: Specialized Network Protocols for IoT+Edge with K... Steven Wong & Dejan Bosanac
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Intro + Deep Dive: Specialized Network Protocols for IoT+Edge with Kubernetes - Steven Wong, VMware & Dejan Bosanac, Red Hat
This session will survey communication protocols and technologies used in the edge and IoT space. These use cases can call for specialized protocols and transports: -publish subscribe, multicast -protocols tolerant of intermittent connectivity -Protocols popular in industry verticals (vehicle bus, industrial automation, building automation) In some cases, support exists now for use with Kubernetes. If not, device gateways and protocol converters might be an option. Agenda: -survey of protocols and transport standards for IoT and edge -Intro to how a device gateway or protocol converter works -Intro to extending Kubernetes with CRDs to manage new device types -Deep Dive / Futures: Could the service mesh concept be extended beyond TCP, HTTP(s)? -Demonstration: Kubernetes management of an edge application using a specialized protocol -Demonstration: Use a device gateway with Kubernetes
https://sched.co/UakM
A
A
So
the
agenda
today
is
in
two
parts,
so
in
the
intro
we're
going
to
go
into
this
broad
survey
of
protocols
and
transports
that
are
used
or
IOT
and
edge
applications,
we
don't
have
time
to
go
into
a
deep
dive
of
any
of
them,
so
I.
If
you
have
thought
that
we're
experts
in
any
of
these
and
you're
gonna,
walk
away
with
miracle
solutions.
That's
not
going
to
happen,
but
these
slides
have
links.
A
You
can
peruse
later
to
get
you
to
the
projects,
the
standards
and
they
might
be
useful
if
you're,
in
the
situation
of
not
even
yet
decided
on
protocols
to
use
when
you're,
putting
together
an
application
out
at
an
edge
location,
then
we're
going
to
touch
on
device
gateways.
Protocol
can
burgers.
And
finally,
the
first
half
will
close
with
a
discussion
of
extending
kubernetes
using
custom
resource
definitions,
and
this
is
kind
of
you
know
a
leading
edge
kind
of
thing,
but
I
think
it
has
potential.
A
A
A
A
A
If
you
really
did
the
deep
dive
drill
down,
you're
reliant
on
two
or
three
of
these
at
the
same
time,
and
maybe
multiple
levels
of
hardware,
switches
and
routers
that
are
required
to
make
this
work
over
on
the
right
side
in
many
situations,
the
data
plane
and
control
plane
are
physically
segregated
and
in
some
cases
the
data
comes
up
at
a
low
level.
Have
it's
transformed
by
adding
metadata
context,
maybe
even
a
little
security
and
governance,
and
that
same
data
might
exist
at
two
levels
in
this
hierarchy.
A
So
when
it
comes
to
analyzing
protocols,
if
you're
in
the
situation
of
choosing
one
or
doing
an
a/b,
compare
of
whether
you
ought
to
use
one
or
another
or
how
two
things
you're
already
using
might
compare
and
behaviors
the
things
that
you
need
to
look
look
at
our
kind
of
the
type
of
the
protocol.
There
are
some
that
are
used
there,
they're
specifically
intended
for
only
point-to-point
connections.
Others
are
buses,
some
are
redundant
buses
in
the
industrial
sector,
where
they're
made
to
be
fault,
tolerant
and
you
can
lose
half
your
network
and
still
remain
operational.
A
These
protocols
differ
in
their
resource
demands.
Some
of
them
might
demand
something
comparable
to
an
x86
like
you'd,
find
in
a
you
know,
a
desktop
or
a
server,
whereas
others
could
run
on
really
low
powered
inexpensive
devices.
Devices
that
really
don't
have
the
capacity
to
do
decent
encryption
protocols
differ
with
regard
to
their
behavior
when
you've
got
lossy
or
unreliable
networks,
and
that's
often
the
case
out
at
edge.
A
Some
of
them
attempt
to
recover
from
those
some
of
them
throw
away
the
data
and
expect
that
a
fresher
report
will
come
and
that
you
won't
care
about
all
these
levels
of
retries.
They
vary
in
security
topology,
whether
they
even
have
support
for
discovery
of
nodes
and
data
content,
or
whether
you
have
to
have
pre-existing
knowledge
of
what
setup
coming
out
of
a
particular
location.
A
A
lot
of
these
have
open
source
implementations,
and
one
thing:
that's
a
key
element
is
that
some
of
them
have
multiple
open
source
implementations,
so
you
might
be
able
to
shop
and
choose,
but
when
they
are
open
source,
one
of
the
key
aspects
is
the
health
of
that
community.
How
many
contributors
you
have
do
you
have
some
kind
of
an
independent
multi
vendor
situation
going
on
maybe
with
a
Standards
Committee
and
some
more
castrated
effort
that
does
testing
and
QA
for
release
cycles?
A
A
We'll
start
with
this
survey
of
some
general
purpose.
Ones,
I.
Think
everybody
here
better
know
about
HTTP
and
HEV,
so
I'm
not
going
to
go
into
those
in
detail,
but
some
devices
support
that.
But
often
you
find
more
specialized
protocols
in
use,
so
mqp
I
think
rabbitmq
might
be.
The
best-known
implementation
has
reliable,
queuing,
topic-based,
publish/subscribe
messaging
format
with
flexible
routings.
It
supports
transactions
curity
and
it
can
be
built
with
exchanges
that
route
messages
in
a
fan-out
form
by
topic
or
headers
to
get
to
locations
that
are
interested
in
that
data.
A
A
It
does
use
a
publish/subscribe
model,
so
it
isn't
it's
beyond
the
point-to-point
network.
Kafka
at
the
bottom,
arguably,
is
in
an
entirely
different
class,
but
I
put
it
in
here
because
I
think
a
lot
of
people
I
mean
if
you
saw
in
the
keynote
Walmart's
presentation
this
morning,
for
what
they
described
as
edge,
is
using
Kafka
as
a
to
transport.
But
it's
kind
of
more
than
just
a
transport
in
that
Kafka.
A
Unlike
the
other
protocols
here
kind
of
supports
the
equivalent
of
a
broker
infrastructure
as
multi-node,
and
it
can
implement
storage,
so
it
actually
can
take
the
data
and
store
it
for
some
time
period.
The
other
protocols
don't
really
have
a
provision
for
keeping
storage
of
these
for
I
guess
Kafka
might
nap
store
it
long-term.
There's
one
of
two
modes
where
old
one
is
old:
data
replaces
the
new,
but
it
always
has
something
in
there
and
with
the
alternate
mode.
A
A
Finally,
we've
got
some
specialized
protocols.
This
is
by
no
means
a
list
of
them
all
that
would
take
two
hours,
but
I
just
highlighted
some
very
popular
ones.
Modbus
goes
back,
I
think
at
least
to
the
80s,
if
not
the
70s,
but
it
was
kind
of
the
original
de
facto
standard
for
industrial
automation
and
there
there
is
a
publication
of
a
standard
and
it's
kind
of
like
it
came
out
and
a
lot
of
people
just
cloned
it,
and
it's
pretty
ubiquitous
in
manufacturing,
automation
back.
A
A
The
original
OPC
was
windows-based
and
it
was
actually
came
about
his
consortium
that
supported
the
Wonderware
product
that
I
worked
on
long
ago,
but
being
Windows
specific.
They
came
out
with
a
second
generation
that
was
kind
of
agnostic
and
a
little
more
versatile
and
it's
a
scenario
that
we're
going
to
get
to
gateways
in
a
minute
that
I
would
argue,
is
in
maybe
the
gateway
class,
where
you
put
on
the
air,
a
server
that
is
talking
perhaps
Modbus
and
10
other
things,
but
out
the
other
end.
A
Opc
UA
actually
is
a
protocol
so
that
clients
would
link
into
this
and
a
client
could
be
written.
Multiple
clients
have
been
written
and
you
can
write
this
functionality
in
your
own
application
to
link
up
with
a
server
that
talks,
OPC
UA,
and
get
access
to
many
different
devices
connected
by
many
different
protocols.
A
We've
got
a
set
of
protocols
that
are
unique
to
transportation.
A
lot
of
these
are
found
in
your
your
automobile,
we're
getting
to
a
scenario
where
luxury
automobiles
can
have
as
many
as
37
computers
onboard
anything
from
anti-lock
brakes.
Traction
control
to
entertainment
systems,
I've
also
thrown
in
a
couple
there
that
are
used
in
the
rail
industry
and
aviation
in
the
industry,
and
you
can
find
links
to
learn
more.
A
A
They
even
require
a
specialized
hardware
port
to
be
able
to
get
on
to
that
bus
and,
if
you'd
like
to
deliver
them
to
nodes
running
things
in
side,
kubernetes
containers,
that's
a
tough
nut
to
crack.
You
probably
don't
want
to
put
that
specialized
communications
device
on
every
one
of
your
kubernetes
worker
notes,
so
the
solution
there
might
be
to
have
those
go
into
a
gateway
that
translates
them
into
something
that
would
be
accessible
by
a
conventional
IP.
So
these
gateways
potentially
allow
efficient
sharing.
A
You
know
the
things
you'd
get
out
of
it
are
potentially
safety.
Many
of
these
protocols
are
even
bandwidth
constrained.
So
I've
seen
things
on
the
market
that
purport
to
be
an
easy
button
for
some
of
these
unique
protocols
that
will
sell
you
something
IP
routable
and
get
you
on
an
industrial
bus
by
directionally
allowing
you
to
pull
sensors.
A
You
know
something
like
that
with
no
governance
is
probably
a
recipe
to
having
a
denial
of
service
attack
into
your
infrastructure
and
might
have
serious
security
issues,
but
I've
seen
them
sold
out
there
and
a
gateway.
I
would
contend,
is
something
the
complete
in
place,
a
tier
of
governance
where
you'd
have
to
have
act.
You
have
access
controls,
limits
on
bandwidth,
consumption,
to
prevent
these
kinds
of
security
risks
so
bottom
line.
Is
they
allow
you
to
route
data
to
devices
that
otherwise
wouldn't
have
realistic
opportunities
to
connect?
A
These
can
also
translate
from
stateless
to
stateful
protocols,
and
they
can
allow
caching
of
data.
It's
often
offered
on
these
industrial
networks.
You
don't
want
to
have
ten
different
clients
hitting
the
device
asking
for
the
same
thing.
You'd
rather
have
the
Gateway,
do
it
and
cache
it
and
the
consumers
read
it
out
of
the
cache
a
few
other
things.
These
gateways
enable
our
load,
balancing
and
monitoring.
So
it's
common
with
those
OPC
UA
servers
to
actually
put
in
place
a
farm
of
those
behind
a
load
ballots
or
it
gives
you
resiliency.
A
So
if
one
crashes,
you
don't
necessarily
take
an
outage
and
you
can
support
larger
numbers
of
clients
by
just
well.
Anybody
using
kubernetes
is
familiar
with
the
concept
of
horizontal
deployment
behind
a
load
balancer,
and
sometimes
these
gateway
said
protocol
translators
would
allow
you
to
do
that.
A
They're
also,
potentially
a
place
to
inject
metadata
that
isn't
in
the
baseline
protocol.
So
you
can
put
timestamps
on
these
to
could
convert
protocols
that
really
are
don't
have
time
stamps
into
protocols
that
actually
are
intended
for
time.
Series
data
and
you
can
indicate
add
metadata
indicating
where
it
came
from.
Maybe
even
attaching
policies
like
who's
allowed
to
get
this
is
it?
Is
it
allowed
to
be
routable
or
not?
Some
of
this
there
are
some
opportunities
for
being
open-ended
on
metadata
so
that
you
can
use
it
for
whatever
you
might
want
to
use
it.
A
You
can
also
put
in
place
the
protocol
converter
gateway
to
put
a
firewall
against
access,
but
from
higher
levels,
so
lift
it
into
your
organization
as
high
as
it
really
should
be,
but
then
prevent
it
from
getting
any
higher.
So
at
this
point,
I'm
gonna
turn
over
the
stage
to
my
co-presenter
Dion
yep
thanks
Dave.
B
So,
basically,
if
you
look
at
the,
if,
if
you
look
at
the
IOT
systems,
yet
the
story
doesn't
end
up
on
gateways
right.
We
have
like
a
tree,
usually
three-tier
architecture
today
and-
and
we
want
to
go
from
the
devices
potential
into
the
gateways.
If
we
need
to
and
then
then
go
to
the
clouds
right
and
the
story
about
gateways
is
that
you
know
we
had
them
for
a
long
time.
B
It's
it's
again,
nothing
new,
but
but
some
things
are
changing,
and
maybe
we
you
know
we
it's
a
time
to
reconsider
or
how
we
do
do.
Gateways
first
thing
is
that
you
know
contr
ization
is
everywhere
right.
Everybody
wants
to
to
do
things
twelve
native
way.
We
want
to
use
back.
You
know
currently
adopted
best
part
practices
to
develop
these
new
things,
but
also
historically,
gateways
were
over
resource
constraints
and
that
also
changes
rapidly
going
forward.
B
So
we
have
more
resources
so,
instead
of
just
having
a
simple
protocol,
conversions
and
things
like
that
on
the
edge
on
the
gate
wastes,
we
are
able
today
to
enable
new
new
use
cases
so
so
to
mark
much
more
data.
Caching,
much
more
storing
forward
capabilities
and
also
do
machine
learning
on
the
on
the
edge.
I
mean
you
talk
about
protocols.
B
We
want
to
provide
a
lot
of
tools
to
developers
to
do
these
things,
as
we
said
with
the
tools
that
that
we
want
to
use
the
day.
So
usually,
our
platforms
that
are
dealing
with
IOT
and
edge
computing
are
providing
harder
abstraction
layers
that
basically
trying
to
rest.
If
I
all
these
lower
level
protocols
and
provide
tools
for
developers
to
use
them
as
easy
as
possible,
Chilton
will
later
on
talk
more
about
it
and
demo
some
of
these
some
of
these
tools.
B
They
are
too
wide
to
most
use
cases
right.
So
you
know
most
people
and
and
99%
of
the
IOT
use
cases
are,
you
know,
select
sending
telemetry
from
the
devices
and
in
front
of
sensors
into
some
kind
of
data
ingestion
and
in
processing
systems
and
sending
commands
back
back
to
the
back
to
the
actuators
back
back
to
the
devices.
So
what
happens
usually
in
practice
is
that
you
know
folks
choose
one
of
those
protocols.
They
are
most
familiar
with
and
trying
to
build
their
own
silo
around
it.
B
So
using
MQTT
you
you
need
it's
not
enough
right.
You
need
to
come
out,
come
up
for
your
schema
for
topic
names.
How
you're
going
to
address
devices,
how
you
you're
gonna,
send
telemetry
you
want
to
deal
with
the
security
in
in
a
you
know,
iot
or
in
a
device
orientated
way
not
based
on
on
the
on
the
topics,
and
you
know
everybody
is-
is
trying
to
solve
that
problem
from
from
the
ground
up.
So
that's
why
we
come
up
with
the
eclipse
hana
project
trying
to
solve
exactly
this
connectivity
for
the
cloud
topic
right.
B
So,
as
you
can
see
see
on
the
diagram,
what
they
try
to
solve
is
exactly
this
having
a
large
number
of
different
kind
of
devices,
talking
different
kind
of
protocols
connecting
to
the
same
infrastructure
and
trying
to
do
the
same
things.
So
we
see
the
two
arrows
showing
the
general
communication
patterns.
We
can
see
so
you
can
see
the
fed
telemetry
arrow,
meaning
that
you
know
we
will
have
a
lot
of
these
meta
data
going
from
the
from
the
things
to
the
solutions
and
then
much
much
smaller
command
and
control
traffic.
B
That's
going
to
go
both
ways,
so
what
you
want
to
do
do
it
is
is
provide
a
pure
cloud
infrastructure
to
be
able
to
connect
millions
of
devices.
So
now
we're
talking
direct
device
to
cloud
connectivity
and-
and
in
this
set
in
this
sense,
our
gateway
is
basically
just
another
device
which
represents
represent
multiple
devices
connecting
to
to
it
to
it
directly
right.
So
the
general
infrastructure
and
architecture
of
such
a
solution
is
something
like
this,
and
all
these
things
are
designed
like
like
a
micro
services
and
kubernetes
pods.
B
So
this
is
all
all
twelve
native
from
from
the
ground
up,
so
we
have
layer
of
protocol
adapters.
We
provide
some
of
them.
We
usually
show
MQTT
and
HTTP,
because
even
in
the
survey
that
Eclipse
Foundation
done
a
couple
of
years
in
a
row,
I'm
most
people
in
this
in
this
cloud
connectivity
area
use
these
two
protocols.
B
We
provide
mqp
adapter
because
mqp
is
a
is
a
base
for
all
the
communication
behind
this
layer
and
we
provide
current
I
think
Zig,
Fox
and
Laura
one
also
out
out
of
the
box,
but
we
have
a
very
good
framework
for
for
basically
implementing
any
custom
custom
protocol
adapter
that
needs
to
be
implemented
by
anybody
and
beyond
beyond
protocol
adapters
device.
Registries
is
one
of
the
the
crucial
components.
B
An
identifier
is
the
source
of
that
data.
Of
course,
we
provide
all
kind
of
monic
monitoring
solutions
to
be
able
to
manage
such
a
complex,
complex
platform.
So,
to
give
you
just
an
example
here
here,
example
of
how
things
work
basically
for
for
a
HTTP
protocol
right
so
with
HTTP,
you
know
so
you
can
do
you
know,
requests
and
response
on
on
on
any
kind
of
address
and
URL.
B
You
want
right,
so
we
want
to
provide
an
API
and-
and
you
know,
I
would
like
to
call
it
like
a
device
connectivity
API
and
try
to
solve
this
problem
once
and
and
and
and
so
that
people
can
can
build
applications
that
are
basically
compatible
to
each
other.
So
we
are
here
trying
to
send
like
a
data
by
sending
a
post
message
to
a
telemetry
URL,
and
that
message
will
be
by
the
protocol,
be
converted
to
a
mqp
message
with
a
bit
of
proper
address,
which
includes
the
tenant.
B
B
So
this
works
for
Laura
van,
but
we
created
the
same
thing
for
the
like:
a
generic
HTTP,
HTTP
adapter.
So
and
it's
an
interesting
thing
from
the
multiple,
multiple
perspectives.
So
one
is
that
it's
only
one
way,
communication
layer
right
and
we
need
to
send
something
back,
but
the
other
is
that
most
of
these
devices
that
connect
directly
to
the
cloud
are
usually
sleeping
a
lot
of
a
lot
of
the
time
right,
it's
battery-powered,
so
so
it's
important,
so
they
wake
up
occasionally
and
try
to
do
something.
B
So
how
how
we
do
this
with
only
HTTP
as
a
tool.
So
here's
well
here's
an
example.
So
a
device,
oh
when
it
wakes
up-
and
it's
ready
to
do
some
work.
It
sends
its
telemetry,
but
even
if
it
doesn't
set
telemetry,
it
can
send
like
a
empty
event.
So
to
say,
and
and
as
a
parameter
there,
we
hear
like
a
TD
T,
which
is
which,
which
means
time
to
disconnect
right.
So
this
device
saying
like
I'm,
sending
you
telemetry
data
and
I'll,
be
around
for
next
30
seconds.
B
Send
me
all
the
commands
that
you
need
for
me
right.
So
this
gets
converted
to
the
proper
aim.
Kappa
message
sent
to
the
application,
an
application
that
at
that
point
knows
that
this
device
is,
is
ready
to
receive
its
messages
and
it
sends
those
messages
through
the
network
and
HT
adapter
will
convert
that
into
like
a
proper
HTTP
response
back
right.
B
So
so,
in
that
manner
we
managed
to
to
to
even
deal
with
these
kind
of
devices
and
and
and
and
be
able
to
manage,
to
manage
command
and
control
in
this
in
this
environment.
So
this
is,
as
far
as
I
have
for
now
is
is
what
we
have
today
in
terms
of
the
cloud
connectivity
and
IOT
protocols
and
in
the
later
session,
in
the
deep
dive
session,
we
will
see
how
we
can
progress
that
and
make
even
better
architecture
and
and
plans
for
the
future.
A
The
recurring
aspect
of
kubernetes
is
that
all
aspects
of
the
system
go
through
a
stage
of
measuring
the
current
state,
comparing
it
to
the
desired
state
and
acting
to
make
the
system
get
closer
to
what
your
stated
goal
was.
The
whole
API
is
based
on
a
premise
that
you
don't
tell
kubernetes
how
to
do
things
you
make.
You
know
you
declare
in
the
API
what
your
desired
outcome
is,
and
these
CR
DS
allow
you
to
plug
in
new
things
to
be
controlled
by
the
API.
A
A
So
this
Cooper
A's
API
server,
if
you
do
an
extension,
gives
you
the
ability
of
crud
operations
create
update,
delete
of
whatever
resource
means.
When
you
add
the
custom
resource
definition,
the
API
server
itself
doesn't
actually
understand
what
these
resources
are.
They
rely
on
something
called
a
controller
that
also
plugs
into
that
API
and
the
Cooper
days
architecture
allows
this
plug-in
to
be
very
scalable.
A
You
know,
there's
a
net
CD
Etsy
D
database
key
value
pairs,
but
one
of
the
interesting
aspects
of
Etsy
D
are
that
you
can
subscribe
to
change
notifications
on
whatever
fraction
of
those
resources
you
might
be
concerned
with,
and
these
controllers
don't
even
have
to
run
in
kubernetes.
They
could
be
running
on
external
devices.
Things
that
aren't
running
on
x86
is
things
that
are
even
in
components
as
low
as
say:
arduino
x'.
If
this
controller
is
capable
of
engaging
with
an
HTTP
api,
you
should
be
able
to
get
it
to
work.
A
So
this
is
an
excerpt
that
I
took
out
of
the
proposal
to
put
CRTs
into
kubernetes.
It
came
out
believe
at
least
a
year
and
a
half
ago,
yeah
June
of
2018,
and
the
initial
proposal
actually
used
an
example
of
controlling
an
industrial
sensor
and
configuring,
whether
it
reported
back
in
units
of
degrees,
Celsius
or
degrees
Fahrenheit.
So
it's
interesting
that,
from
the
very
beginning,
people
sort
of
suggested
a
use
case
of
applying
the
kubernetes
control
plane
to
control
things
out
at
edge
and
things
that
aren't
containerized
workloads.
A
An
example
of
this
is
microsoft's
azure,
IOT
edge
that
actually
does
plug
in
c
RDS
into
the
kubernetes
control
plane.
I'm
not
going
to
give
you
the
deep
dive
explanation.
If
you
look
at
the
recording
of
our
talk
in
barcelona,
we
spent
a
couple
minutes
on
this,
but
the
link
there
is
to
a
site
that
will
allow
you
to
do
a
deeper
dive.
The
point
isn't
to
explain
how
azure
IOT
edge
works.
A
Although
it's
interesting
it's
to
point
out
that
this,
the
thought
of
extending
kubernetes
to
control
things
out
at
edge
is
real
and
people
have
started
to
do
it,
but
it
is
early
stages.
So
an
emerging
use
case
of
kubernetes
is
to
think
of
it
as
a
general-purpose
platform
for
managing
things,
and
that
is
not
necessarily
just
onboarding
devices,
but
perhaps
even
managing
the
networks
and
the
interconnects
that
bring
those
devices
in
to
allow
them
to
be
used
with
containerized
apps.
A
And
you
know
that's
a
good
use
case,
because
a
lot
of
these
things
might
ingest
things
like,
say,
security,
camera
images
that
could
feed
into
machine
learning
applications
running
in
containers
reduce
that
so
that
you
don't
really
need
to
push
every
image.
You
know,
4k
images
30
frames
a
second
all
the
way
up
to
the
cloud.
Maybe
you
can
look
at
those
images
recognize
automobile
license.
Plate
numbers
or
people's
faces,
and
the
real
thing
of
interest
is
just
that
much
smaller
data
stream
of
the
license
plate
burrs
or
the
person's
identities.
A
So
you
know
what,
if
we
could
use
this
and
then
and
apply
it
to
this
sector,
so
we'll
get
into
more
of
that
after
this
break.
At
this
point,
this
is
ninety
minutes.
Five
minutes
if
you
need
to
use
the
facilities,
but
if
not
we're
gonna
make
this
a
birds
of
a
feather
so
for
five
minutes.
If
you're
interested
in
industrial
IOT
devices
cameras,
why
don't
you
come
over
to
this
corner
and
meet
others
who
are
interested
in,
say,
hello,
introduce
yourself
we'll
put
in
that
up
us
and
corner?
A
If
you
do
that,
that's
retail
in
branch
office
like
supporting
stores,
fast
food
transportation
and
smart
cities
over
here
and
we'll
put
telcos
in
that
back
corner.
If
you
didn't
fit
any
of
those
four
choose
the
closest
one,
so
transportation
and
smart
cities
I'll
put
it
here,
because
we
don't
need
to
go
to
the
back
corner
and
telco
in
it's
5:05.
So
we'll
resume
the
presentation
at
five
ten,
but
either
take
a
break
or
try
to
meet
others.
A
Okay,
let's
get
started
if,
if
we
get
started
now,
there's
a
good
chance
we'll
end
early,
and
we
can
continue
these
birds
of
a
feather
discussions
at
the
end,
so
we're
moving
on
to
the
deep
dive
and
what
I
want
to
pose.
I
already
put
up
the
proposition
that
using
CR
DS
custom
resource
definitions
might
allow
you
to
use
kubernetes
as
a
control
plane
for
devices,
maybe
networks,
but
maybe
using
kubernetes
as
a
network
management
facility,
isn't
the
only
way
to
accomplish
network
management.
A
If
you
look
at
what's
going
on
in
the
container
deployments
on
kubernetes,
a
movement
arose
called
service
mesh
with
things
like
SEO
is
one
example
of
a
service.
Mesh
linker
Dee
is
another
one
that
has
a
fairly
established
user
base
and
I
I'd
like
people
to
think
about
whether
this
concept
of
having
an
external
controller
of
networking,
with
the
other
things
going
on,
isn't
of
interest.
A
A
A
This
is
probably
not
the
way
you
want
to
handle.
Over-The-Air
updates
having
a
helicopter
hang
a
guy
over
each
one
and
manually
update
the
software
and
configure
the
network.
So
my
point
here
is
that
networking
and
configuring
of
that
networking
can
collateral
things
like
health
checking
of
these
devices
monitoring
traffic
on
the
networks.
What
they
call
observability
is
something
you'd
really
like
to
have
now.
A
There's
a
forecast
here
that
came
from
a
Gardner
document.
I
found
online
that
says
that
they're
projecting
that
by
2022,
more
than
half
of
enterprise
generated
data,
is
going
to
be
created
outside
data
centers
and
initially
processed
outside
the
data
centers,
and
this
movement
to
lt5
I
think
is
akin
to
what
happened
when
the
world
moved
from
dial-up
modems
to
broadband.
You
know
I'm
old
enough,
that
I
lived
through
that
transition.
Where
you
had
a
household
and
you'd
make
the
announcement.
Does
anybody
need
to
make
a
phone
call,
or
does
anybody
expect
an
inbound
call?
A
Because
you
were
going
to
Ty
enough
now?
Broadband
gave
you
much
higher
bandwidth,
but
I
would
contend
that
the
biggest
Delta
that
we
really
was
transformative
was
the
fact
that
you
had
a
something
that
seemed
like
always-on
devices,
and
it
worked
you
to
a
world
from
one
shared
computer
for
your
household,
because
really
you
couldn't
use
more
than
one
when
you
had
this
dial-up
connection
to
something
where
each
family
member
might
have
multiple
devices.
A
Think
I've
heard
people
describe
this
effect
as
data
gravity,
where
there
it's
actually
tends
to
be
more
efficient
to
process
this
at
closer
to
the
source
of
ingest.
The
thing
I
think
I
mentioned
earlier,
of
not
feeding
frame-by-frame,
full
camera
images,
all
the
way
up
to
the
public
cloud,
but
analyzing
it
close
to
the
point
that's
generated
and
finding
out
that
the
volume
here
is
greatly
reduced.
A
So
a
service
mash
in
the
concept
in
the
context
of
like
SEO,
involves
a
data
plane
where
containerized
apps
talk
to
one
another,
as
well
as
a
control
plane
that
configures
the
rules
that
hook
these
apps
together,
and
you
don't
want
to
do
these
one
app
at
a
time.
You
want
these
to
engage
in
labels
that
would
control
the
policy.
That's
appropriate
for
these
point-to-point
connections.
A
The
existing
control
planes
up
at
level
7
offer
features
like
load,
balancing
trout
management,
maybe
quotas,
health
monitoring
of
the
apps
and,
by
analogy
I'd
call
it
health
monitoring
of
the
devices
potentially.
If
we
were
to
move
this
to
the
IOT
edge
space
and
perhaps
even
features
that
would
lean
into
the
security
aspects
of
what's
going
on
to
detect
whether
things
are
looking
right
from
a
security
perspective
or
wrong.
Some
of
these
meshes
ad
service
discovery
and
traceability.
Should
you
be
troubleshooting
issues
and
like
to
dis?
A
You
know
like
to
discern
we're
in
this
big
pipeline
of
steps.
The
bottleneck
really
is
so
I'll
give
you
an
example
of
something
I
think
this
concept
of
applying
service
mesh
and
the
generic
term
down
to
the
IOT
space
is
something
that's
gaining
traction
and
there
is
an
open
source
project
called
network
service
mesh
that
is
currently
being
contributed
to
by
quite
a
large
number
of
telcos
and
hardware
neck
networking
vendors,
as
well
as
people
who
provide
software
solutions
for
our
software-defined
network
functions
and
switching
I'm
not
going
to
drill
down
into
this.
A
The
link
is
there,
but
I
think
this
is
perhaps
a
data
point
that
proves
that
there
is
the
potential
to
do
a
service
mesh
like
concept
like
sto,
but
taking
it
down
to
these
specialized
networks
like
we
talked
about
in
part
1
of
this
talk,
this
is
an
example.
This
is
using
network
service
mesh
actually
using
amal
a
lot
like
kubernetes
there
to
specify
an
aspect.
B
So
what
you
want
to
do
is
is
basically
connect
all
these
things
right,
sososo
connect
all
these
services
living
in
different
private
networks
together,
but
not
address
them
using
the
network
addresses,
but
all
use
some
kind
of
network
overlay.
On
top
of
that,
to
try
to
do
do
things
differently
right,
and
for
that
reason
we
think
we
need
to
go
back
to
the
layer
7
again
and
and
and
provide
a
provide,
a
proper
tooling
there.
B
So
so
one
of
the
solutions
we
have
there
is
is
is
built
into
the
mqp
1.0
protocol
and
there
we
have
a
toll,
call
mkp,
router,
a
message
router,
which
works
on
a
similar
principle
like
like,
like
an
IP
router,
but
works
on
up
on
a
completely
another
network
layer.
It
works
on
on
layer,
seven
and
what
that
does
gives
us
is,
if
you
take
a
look
at
this
diagram
opportunity
to
do
a
couple
of
things.
B
If
you
take
a
look
at
these
these
arrows
that
connects
different
routers
on
different
sides,
you
will
see
that
that,
for
example,
we
can
avoid
VPNs
in
this
scenario,
because
all
all
the
all
the
all
the
physical
IP
connections
are
initiated
from
the
edge
to
the
cloud
right
and
and
once
we
have
this
IP
network
and
connectivity
on
that
level.
Sort
it
out.
We
have
an
overlay
layer
network
and
can
provide
a
duplex
connects
communication
between
the
services
over
that
right.
B
So
at
that
point
we
can
address
our
services
not
based
on
their
dns
names
or
IP
addresses.
We
can
use
a
semantically
logical
names
of
the
services
own
until
on
the
layer,
seven
and-
and
we
cannot
address
so
receive,
for
example,
well
laying
out
in
the
in
the
in
the
in
the
one
edge
site
from
this
service
a
sitting
in
the
other
edge
side,
and-
and
you
can
see
that
you
know
with
this
approach-
we
can
basically
do,
as
you
know,
east-west
communication
between
the
edge
sites
that
are
even
not
physically
physically
connected
right.
B
So
we
coined
the
term
virtual
application
networks
trying
to
define
all
these
concepts
because
it
doesn't
fit
completely
with,
with
with
other
networking
technology
trying
to
solve
this
kind
of
multi-site
multi
cluster
communication.
You
know-
and
you
know,
comparing
it
to
the
to
the
stos
service,
mesh
and
and
in
other
similar
technologies.
There
are
a
lot
of
overlaps,
but
but
there
are
some
some
differences
and-
and
you
know,
in
my
opinion,
this
technology
is
a
better
approach
to
trying
to
connect
these.
B
These
multiple,
multiple
edged
sites
right
because
we
it's
not
a
typical
hybrid
cloud
scenario,
even
because
you
know
in
a
typical
hybrid
cloud
environment,
you
have
a
small
number
of
public,
publicly
they're
addressable
services.
In
this
case
we
have
a
large
number
of
services
sitting
in
a
private
network
strength
trying
to
communicate
with
each
other.
So
this
diagram
can
show
us
a
little
bit
more
details
and-
and
the
main
takeaway
here
is
that
you
can
see
that
all
all
this
is
done
on
the
application
level
level.
B
So
so
not
not
special
needs
to
deal
with
the
network
to
deal
with
the
routers
VPNs
and
things
like
that.
We
define
our
military
application
network
on
on
the
application
level,
so
there's
no
any
special
authorization
policies
for
the
users,
it's
based
on
its
own
namespace
and
then
the
services
on
top
of
that
can
use
that
network
to
to
communicate,
to
communicate
to
each
other.
B
So
this
is
the
basic,
the
basic
schema
of
where
things
lay
in
another
way.
So
we
have
a
TCP
layer
as
I
show
on
different
on
different
diagram.
We
have
our
application
routers,
connecting
on
the
top
on
the
layer
on
top
of
that
and
and
one
once
we
have
that
we
can
define,
addresses,
addresses
on
the
layer,
steps
on
the
application
level
and
map
that
to
our
proper
services.
So
a
couple
of
things
we
get
there.
B
First
of
all,
we're
not
not
just
gaining
gaining,
we
can
do
things
properly
on
the
messaging
level,
so
it's
not
only
requested
reply.
Any
class
communications
anymore
once
we
have
this,
this
network
mqp
protocol
is,
is,
is
capable
of
doing
multicast
communication
or
any
communication.
We
can
hook
up
another
messaging
services.
We
can
cook
up
queues
as
a
service
behind
the
routers.
B
B
B
B
So
so,
with
all
these
that
that
we
talked
today,
I
wanna,
you
know,
lay
a
picture
of
where
you
know
this
is
where
we
are
today
and
and
and
where
we
gonna
go,
go
tomorrow
with
all
these
technologies
that
you
hear
right.
So
today
we
talked
about
Eclipse.
Hana
is
a
IOT
connectivity
platform
right
and-
and
it's
I
can't
say
it's
centralized
architecture,
but
it's
a
centralized
deployment
and
it's
all
with
all
cloud
cloud
native
and
cloud
technologies.
It's
a
centralized
deployment
technology
right.
B
But
but
the
question
is,
would
would
cloud
be
operating
in
that
use
case
right
and-
and
the
answer
is
always
no
right,
so
we
we
will
always
need
to
have
our
own
central
point
of
control
and
management
and
data
aggregation,
but
we
can
still
do
much
better
if
you
try
to
distribute
things
and
and
and
move
things
closer
to
the
to
the
devices
and
closer
to
the
edges.
So
there's
a
couple
of
things
we
want
to
try
to
do
so.
First
things.
B
First
thing
in
a
you
know:
it's
Horner
project
is:
is
we
want
to
try
to
build
a
nice
framework
to
be
able
to
put
these
protocol
adapters
outside
of
the
cluster,
so
talking
about
proper
device
gateway
way?
Why
we
want
to
do
it?
So
maybe
you
you
you're
gonna
use
this.
You
know
you
know
you
know
with
a
cloud
provider
that
will
not
allow
you
to
deploy
your
own
or
custom
protocol
adapters
there,
which
is
a
you
know,
a
probable
probable
solution
right.
B
So
so
what
you're
not
allowing
to
do
is
is
to
you
know,
use
the
same
tools
to
create
a
protocol
adapter.
You
know
in
a
whole
new
specific
way,
but
being
able
to
host
it
on
a
device
gateway
and
then
connect
it
to
to
the
standard
AMQP
and
protocol
adapter.
But
even
even
beyond
that,
I
think
the
the
end.
Endgame
should
look,
should
look
something
like
this
and
and
and
we
should
aim
something
like
this
and
having
like
a
full
distributed
deployment
of
of
horror.
B
And
that
means
that
we
want
to
put
protocol
adapters
on
the
edge
sites
having
mkp
network
built,
using
using
the
discover
project
and
and
being
able
to
cause
that,
on
the
on
the
on
the
on
the
edge
platforms
like
I
have
fog
which,
which
will
allows
us
to
you,
know,
connect
device
locally
and
use
basically
horno
as
a
as
a
device
connectivity
layer,
API
right
having
a
flexible
network
that
can
connect
these
things
together
and
and
and
how's
that,
on
the
on
the
appropriate.
Appropriate
age
platform.
B
Additionally
allows
us
to
the
host
our
business
services
closer
to
the
devices
right
on
the
edge
locations,
having
a
tighter
loop,
having
a
more
resiliency
having
less
latency
in
in
data
in
data
processing,
but
also
being
able
to
have
a
central
cloud
where,
where
important,
data
and
and
long-term
storage
data
should
go,
so
did
something
that
that's
the
work
I
think
in
front
of
us
and
where
we
gonna
be.
We
want
to
be
so
use.
Qubits
Uzziah
folk
as
is,
is
a
you
know.
B
C
Should
come
up
momentarily
how's
that
looking
ok
great,
let's
make
this
a
little
bit
bigger?
You
can
take
a
look
at
what
we're
gonna
do
here
on
the
stage,
so
thanks
everybody
for
staying
around
through
the
very
end
of
the
very
last
day
of
the
conference
and
getting
through
some
deeper
technical
material.
C
So
what
we're
gonna
do
here
is
we're
going
to
take
a
look
at
a
equivalent
of
a
you
know:
protocol
adapter
or
it
is
a
protocol
adapter
from
Bluetooth
Low
Energy
to
REST
API,
and
we're
going
to
do
that
right
here
in
the
room
with
the
stress,
berry
pie,
and
so
what
we're
looking
at
here
is.
This
is
what
we
call
an
edge
compute
network.
C
It's
the
last
hop
there
in
Los
Angeles,
not
much
I
can
do
about
that
without
GPS
coordinates,
but
so
to
view
the
whole
edge
compute
network
here
I've
got
some
global
nodes
and
now
the
important
thing
to
note
some
of
the
nodes
are
on
some
aren't
I
actually
had
a
lot
more
at
our
demo,
booth
and
I.
You
know
they're
currently
in
my
bag
so
offline.
C
This
node
has
some
information
about
what's
happening
and
I
can
see
some
some
information
about
the
raspberry
pi
right
here,
very
similar
to
what
you'd
get
from
an
instance
of
cubelet
rights,
reporting
in
available
ram,
cpu,
etc,
and
it's
also
reporting
in
some
information
about
what
microservices
are
running.
Currently,
none
I'm
going
to
go
ahead
and
do
a
deployment
of
a
micro
service.
C
So
in
no
situation
can
you
have
the
protocol
adapter
from
bluetooth
to
the
rest
of
your
system
exist
anywhere,
except
right
here
in
the
room,
and
this
is
commonly
in
the
case
for
legacy
machinery
for
anything.
That's
speaking,
Modbus
for
anything
that
is
speaking
a
can
bus
over
Ethernet.
All
of
these
ways
that
were
described
earlier
to
talk
to
the
machinery
of
the
world.
You
need
to
have
something
nearby
that
understands
how
to
talk
to
it
and
then
from
there
up,
you
can
use
JSON
or
XML
or
whatever
it
is.
C
C
So
what
we
have
here
is
a
micro
service
I've
named
the
application,
Bluetooth
abstraction
there's
a
micro
service
here
called
rest
blue,
as
I
mentioned,
and
some
of
the
slides
a
day
on
presented
earlier
I'm,
going
to
throw
that
down
to
this
Raspberry
Pi
that
I
have
here.
The
deployment
process
is,
you
know,
almost
fun,
I
CTL
deploy
application
from
a
file,
and
it
says
DLL
file
to
what
network
this
one.
Here
they
call
packet
two
off.
It
goes
and
you'll
see
that
the
microservice
will
show
up
here.
C
First,
it
shows
up
gray
and
then
it
immediately
turns
blue
gray
is
I've
issued
the
command
around
the
microservice.
It
goes
blue
as
soon
as
the
edge
note
has
replied
and
said,
I
got
the
command.
I'm
gonna
start
running
it.
So
this
will
take
just
a
moment
to
start
up,
and
as
soon
as
it
does,
I
can
go
and
I
can
query
it
and
I
can
query
it
on
the
command
line
here.
Using
curl
or
I
can
treat
it
like
a
REST
API.
C
That's
because
I've
now
thrown
a
hardware
abstraction
service
down
to
the
edge
it
can
be
utilized
by
anything
in
the
room,
including
other
micro
services.
So
if
we're
gonna
do
services
for
the
edge,
we
not
only
need
to
know
which
one's
get
orchestrated
where
but
also
how
they
can
be
open
for
the
other
micro
services
or
the
software
to
find
them
so
I'm
assuming
it's
running
now.
Actually
you
know
what
I
can
go
and
I
can
take
a
look
if
it's
running
now.
C
Let
me
look
at
the
details
and
see
starting
so
it'll
be
up
in
a
moment
and
I
bet
you.
If
I
query
on
the
command
line
with
this
command,
get
all
of
the
network
status.
I
wouldn't
be
surprised
if
the
application
is
shown
Oh
still
starting
we'll
give
it
a
moment
longer.
That's
the
beauty
of
the
the
edge
layer
here,
the
edge
compute
technology
is
that
I
can
actually
see
what's
happening
there.
It
is
now
it's
running
okay,
great,
so,
oh
no,
the
micro
service
is
still
starting.
Oh,
let's
get.
C
Let's
just
go
ahead
and
and
see
the
status
made
baked
into
20
seconds
to
come
back.
So
what
I'm
gonna
do
is
I'm
going
to
issue
a
curl
command
against
this
Raspberry
Pi
here,
which
is
at
this
IP
address,
and
it
so
happens
that
I
opened
it
down
port
I'll,
you
know.
Ten
thousand
five
hundred
and
the
endpoint
here
for
Bluetooth
is
devices.
Let's
see
we
get
a
the
micro
service
isn't
is
not
running
yet
we're
gonna
find
out.
Ok,
so
let's
see
the
status
here.
C
C
C
The
demonstration
is
a-ok
down
the
hall.
You
know
what
I
probably
is
disconnect
from
my
VPN,
where
I
have
another
device
at
that
same
IP
address
found
the
problem.
Ok,
great
I'll
turn
this
guy
off,
because
I
want
to
do
that
differently.
Okay,
let's
try
this
again.
Now,
let's
see
there,
we
go
here's
all
the
Bluetooth
devices
that
I
can
see
from
stage
and
now
let
me
pipe
it
into
JQ.
So
it's
a
little
bit
more
legible.
C
So,
let's
see
what
we
got
here,
a
lot
of
fun,
name,
stuff:
here's
my
device
that
I
was
looking
for
so
we'll
connect
to
that
in
a
minute.
Do
it
manually,
so
we've
gotten
anything
interesting
anybody's.
You
know
Apple
pencils
or
speakers
and
stuff
all
of
these
ones,
that
you're
seeing
with
the
masked
IDs
the
smartphone
sells
it.
Who's
got
a
tile
in
their
pocket.
Nice
very
nice,
alright,
actually
an
excellent.
C
We
do
a
quick
scan
for
anything
else,
industry,
interesting
and
then
I'll
move
on
to
showing
you
how
to
use
this
a
little
bit
more
looks
like
that's
all
the
good
stuff
for
the
moment.
So
if
I
want
to
talk
to
a
device
here,
I
can
let
me
power
this
on
it's
gonna,
flash,
green
or
blue
and
red,
while
it
waits
for
a
connection.
I
will
put
it
on
my
body
in
a
minute
here
to
get
my
heart
rate.
That's
what
it
is.
A
heart
rate
monitor.
C
So,
if
I
query
here
for
devices
I'm
looking
for
this
thing
that
says
rhythm
plus
and
I
had
it
before
and
we'll
get
it
we'll
find
it
here
again
and
normally
to
talk
to
Bluetooth
devices.
There
we
go
I
want
the
the
MAC
address
in
concatenated
form,
normally
to
talk
to
Bluetooth
devices.
You
have
to
scan
wait
for
something
to
broadcast,
just
ask
it
for
the
connection.
It
gives
you
the
connection.
You
then
query
its
available
services.
C
C
Yeah,
it
is,
and
you
really
wish
it
was
something
that
you
could
just
address
the
data
right,
give
me
the
data
for
this
stuff.
We're
gonna
do
that
right
now,
so,
instead
of
querying
this
command
here,
which
is
this
endpoint,
which
is
devices
I'm
going
to
get
device
by
mac,
Adid
MAC
address
here,
I
want
to
see
the
services
on
this.
This
wristband
thing.
C
So
these
are
the
services
that
are
available
and
let
me
put
that
to
Jake
you
actually
a
little
bit
easier
battery
service.
That's
a
cool
one
device,
information
heartrate,
that's
the
one
that
I'm
looking
for,
but
let's
ask
for
the
battery.
So
the
battery
here
is
at
one
eight
zero
F,
which
is
standard
for
Bluetooth,
Low
Energy
stuff.
So
now
I
can
do
services
actually
service.
One
eight,
zero,
F
and
now
I
want
to
ask
it:
what
are
the
characteristics
and
now
the
characteristics
just
battery
level?
C
C
To
a-19-
and
here
comes
my
data
in
base64
encoding
za
equals
equals.
If
you
do
the
decode
on
that,
it's
going
to
come
out
to
like
85
or
whatever
battery
level.
Now
here's
the
magic
watch,
this
I'm
gonna
go
ahead
and
clear.
You
could
hit
this
command
just
as
is,
and
I
don't
even
need
the
JQ
part
from
your
code.
One
command!
C
Somebody
can
build
that
as
a
micro
surface
and
you
can
tap
into
that
from
the
enterprise
level
and
those
are
data
streams
that
we
can
manage
off-site
right
once
they
go
upward
into
the
rest
of
your
enterprise
systems,
they're
digestible
and
when
you
issue
a
command
such
as
you
know,
reboot
or
update
firmware
it
pushes
down
and
something
at
the
edge
does
the
translation.
Then
you
go
from
there
now.
C
This
thing
is
currently
flashing
blue
because
it's
connected
already
I
have
to
restart
it
so
that
it
breaks
that
connection,
because
I
want
to
show
you
I'm
gonna
deploy
another
micro
service,
it's
actually
a
set
of
micro
services.
That's
going
to
be
fun!
So
let
me
go
into
this
directory.
So
here,
I
have
a
Yambol
file.
Config
cuke
on
this
yam
will
file,
describes
a
bigger
application.
It's
a
micro
service.
That's
going
to
get
my
heart
rate
and
I
have
put
the
data
label
on
it.
C
As
my
name,
you
can
label
it
with
whatever
you
want,
and
then
this
other
micro
service
is
a
UI
to
view
it
so
I'm
going
to
go
ahead
and
deploy
these.
So,
let's
do
I,
owe
Fogg
CTL,
deploy
application
and
then
cube
Khan
when
I
push
this
out,
which
there
we
go,
seems
to
be
working.
I'm
gonna
get
a
couple
more
micro
services,
they're
gray,
they're
about
to
go
blue
when
this
guy
answers
what's
gonna
happen
is
I
need
to
wear
this
on
my
wrist,
so
I
can
get
my
heart
rate.
C
I'll
just
have
to
hold
that
kind
of
tight,
okay,
great
so
we'll
let
those
get
pushed
down
and
once
they
push
down
it's
going
to
start
looking
for
this
device
again
it's
going
to
flash
red
and
blue
and
what
I'm
looking
for
is
I'm
waiting
for
the
micro
service
to
run,
and
then
it's
going
to
go
blue,
letting
me
know
that
it's
been
picked
up
and
then
there's
a
user
interface.
That's
going
to
allow
me
to
monitor
my
heart
rate,
and
that's
that
also
is
a
service
that
can
be
used
here
at
the
edge.
C
You
could
just
as
easily
put
that
UI
in
the
cloud,
because
I'm
sending
data
post
the
protocol
adapter
to
reach
the
the
rest
of
the
system.
There
we
go.
It's
gone
blue
so
that
micro
service
must
be
running
and
I
didn't
think
that
I'd
have
the
leather
jacket
on
while
wearing
this.
So
that
makes
things
a
little
tough
here
we're
gonna
go
to.
It
would
be
1
9,
2,
1,
6,
8,
1,
94
and
I'm.
Looking
for
88
99,
let's
see
if
we've
got
it
up
there
out
there.
It
is
great.
C
That
you're
not
nervous
I'm,
not
nervous
Adi,
just
made
me
nervous
earlier
I
had
someone
at
my
demo
booth
put
this
on
so
that
he'd
be
my
guinea,
pig
and
I
could
tell
that
he
was
wondering.
What's
this
gonna
do
to
me,
we
put
it
on
in
his
initial
heart
rate
120.
So
then
everyone
starts
laughing.
It
goes
up
225,
so
we
said
wait,
wait,
wait,
wait,
wait!
We
need
to
calm
this
down,
like
somebody
give
him
a
drink
or
something,
and
so
then,
as
he
watched
it,
biofeedback
is
amazing.
C
He
got
down
to
80
something
all
until
we
started
joking
and
laughing
it
again.
This
heart
rate
went
back
up.
So
what's
amazing
about
this
is
I,
don't
need
to
think
any
more
of
my
enterprise
systems
having
some
deep
knowledge
of
the
machinery
or
what
I'm
gonna
connect
to
or
whatever
I'm
free
to
make
an
enterprise
data
oriented
system
kubernetes
distributed.
You
know,
micro
services,
but
at
the
lowest
level
we
do
the
handling
for
those
weird
protocols
and
that's
how
we're
probably
going
to
make
the
edge
manageable.
C
A
You
got
a
taste
in
presentation
form
of
the
kind
of
discussions
we
have
in
the
kubernetes
IOT
and
edge
working
group,
but
we
meet
twice
a
month
on
zoom'
and
you
can
join
online
at
the
three
worldwide
cube
con
events.
We
have
these
kinds
of
presentations,
but
this
is
where
you
go
to
learn
more.
The
details
of
when
our
next
meeting
is
do
be
cautious
of
these
things
calibrated
to
certain
time
zones,
so
they
do
move
around
I
know
as
a
leader.
A
We
get
notifications
that
somebody
joined
and
there
are
a
lot
of
people
who
tried
to
join
in
an
hour
off
because
maybe
different
daylight
savings
time
shift
locations
and
we've
got
a
series
optimized
for
North
America
and
another
one
optimized
for
China
Eastern
Europe.
You
can
join
either
both
this
works
just
like
any
other
kubernetes.
Se
gore
working
group
you
go
in
to
get
hub
under
kubernetes
community,
find
our
our
group
and
there'll
be
a
link
to
join
a
Google
mailing
list.
He
joined
it
and
you
have
access
to
all
of
our
documents.
A
We
don't
leave
them
open
to
public
edit,
because
we've
had
incidents
where
spammers
or
other
people
graffiti
the
document.
But
it's
simple:
you
join
the
group
with
your
email,
but
you're.
Not
even
Google
gets
your
email,
but
it
isn't
shared
across
the
group.
Join
it.
If
there's
something
you'd
like
to
have
discussed
or
present
or
you
know,
have
the
organizers
tried
to
seek
out
a
speaker
on
you're
free
to
actually
put
suggested
agenda
items
in
a
future
meeting
and
we'll
try
to
make
it
happen
ground
rules.
A
This
is
this
cloud
native
compute
Foundation,
a
nonprofit
that
is
focused
on
open
source,
so
we're
not
interested
in
having
these
meetings
hijacked
and
turned
into
commercial
sales
pitches.
But
we
are
quite
welcome
and
we
usually
do
discuss
open
source
solutions
and
applying
things
like
kubernetes
to
use
cases
that
at
this
time,
aren't
as
popular
is
using
containerized
enterprise
apps
but
we're
getting
there.
A
We
have
already
published
these
things
typically
start
in
the
form
of
a
presentation
like
this
one,
then
we'll
take
the
information
we
presented,
maybe
turned
it
into
a
white
paper
and
the
last
ones
were
security,
focused
the
issues
and
potential
solutions
that
you
have
for
imposing
security
in
the
IOT
edge
space.
I
suspect
we
might
end
up
with
a
white
paper
on
protocols,
since
we
went
to
the
effort
to
do
a
little
information
gathering
here
and
but
you
can
look
at
that
white
paper
for
an
example
of
what
goes
on
with.
A
D
C
There
wasn't
in
my
part
of
the
demonstration,
but
the
way
that
this
aisle
fog
environment
was
stood
up
and
is
being
managed
as
by
kubernetes.
What
I
would,
if
you,
if
you'd
like
to
see
that
side
of
it,
and
you
can
either
ping
on
this,
this
working
group
slack
or
giving
my
contact
info
for
an
email,
but
the
demonstration
you're
probably
looking
for,
is
how
you
would
maybe
use
a
helmet
art
to
stand
up
some
edge
environment
that
that's
all
doable
as
well.