►
From YouTube: Elastic Service Mesh for OpenShift
Description
The rapid adoption of microservices architectures and cloud-native applications is driving networking and operations teams to evaluate networking tools needed to support them. A full spectrum of application services from service discovery, autoscaling, and security; to visibility, and performance monitoring are necessary to support production-grade microservices and container-based applications on the OpenShift Platform. Load balancers built on legacy appliance-based architectures are inflexible unable to mirror the needs of modern applications. In this session, product experts from Avi Networks – an OpenShift Partner, will discuss and demonstrate how Avi’s Elastic Service Mesh delivers these services at scale for the OpenShift Platform.
A
Good
afternoon
everyone,
my
name,
is
Steve
Ali
and
I'm,
a
senior
director
of
systems,
engineering
for
avi
networks
and
I
brought
along
with
me.
My
good
friend,
Bhushan
PI
systems,
engineer
solutions,
architect,
eme
everything
so
I'm
going
to
talk
to
you
a
little
bit
about
avi
networks
and
how
we
integrate
with
OpenShift,
specifically
and
just
as
far
as
a
little
bit
of
background.
Ivy
networks
has
been
around
for
over
five
years
now
and
we
have
a
global
footprint.
A
But
what
we
do
is
in
the
space
of
the
next
generation:
software-defined,
application,
delivery,
controller,
there's
a
lot
of
words,
but
we're
next-gen,
100%
software,
and
we
provide
ADC
services
such
as
load,
balancing
SSL,
offloading,
caching,
compression
DDoS
mitigation,
web
application,
firewall
services
all
together
and
I'm,
going
to
go
through
the
little
bit
of
the
architecture
to
help
help.
You
understand
exactly
what
this
looks
like
so.
A
Let's
just
take
a
step
back
for
a
second
and
talk
about
the
last
decade
and
a
half
of
where
the
ADC
space
has
really
come
from
or
or
developed
out
of
the
stone
Age's
like
how
we
like
to
refer
to
it,
but
there
are
a
lot
of
things
that
we're
a
characteristic
of
ADC
vendors
of
ADC
services
that
that
nowadays
provides
some
pretty
significant
challenges
for
customers
as
they
roll
out
new
application
workloads.
One
of
those
is
that
it's
done
on
proprietary
hardware,
it's
very
monolithic,
you're
tied
to
that
physical
environment.
A
A
That
can
become
problematic
for
large
deployments
if
you
have
to
go
log
into
each
H,
a
pair
active
standby
and
configure
them
separately,
that
that
is
a
significant
issue,
there's
also
very
low
automation.
A
lot
of
those
legacy
platforms
were
not
built
on
open,
rest-based,
API
environments,
they're,
not
a
object-oriented.
You
can't
simply
just
plug
in
other
open
API
tools
and
get
them
up
and
running
right
away.
A
fourth
one
is
very,
very
limited,
telemetry,
meaning
your
visibility
is
pretty
much
confined
to
the
two
pair
that
you're
logging
into
at
that
particular
time.
A
So
when
you
talk
about
an
entire
distributed
fabric,
it
doesn't
really
exist.
When
you
look
at
legacy
legacy,
solutions
that
are
out
on
the
market
very
limited,
analytics
and
insights,
it
doesn't
really
help
with
development
priorities
either
and,
lastly,
it's
static
capacity.
You
put
a
physical
box
in
place.
You
have
X
amount
of
capacity
per
that
physical
unit,
and
that's
it
once
you
hit
that
limit.
You
have
to
upgrade
that
physical
device
or
put
in
another
device
moving
applications
around
is
not
based
on
application
need
or
n
client
need.
A
It's
based
on
the
physical
limitations
of
that
physical
appliance
that
you
have
those
services
running
on.
So
what
is
avi
do
differently?
How
what
did
we
bring
to
market
now
that
differentiates
us?
The
first
thing
is
that
we've
completely
decoupled
the
management
plane
from
the
data
plane
we
have
created,
what's
called
the
avi
controller
and
that
handles
all
management
or
control,
plane
function,
and
then
we've
also
created
the
avi
service
engines,
which
are
the
worker
nodes.
Those
are
the
physical
ADC
devices
and
I
say
physical.
A
Those
are
the
software
ADC
services
that
are
sitting
out
there
deployed
in
any
environment
that
you
want
them
to
be
in,
but
the
controller
is
now
in
charge
of
that
entire
distributed
data,
plane,
architecture
or
fabric
those
service
engines
can
be
deployed
in
any
ecosystem,
so
they
can
go
into
a
traditional
bare-metal,
on-prem
environment.
They
can
be
deployed
in
a
virtualized
environment.
They
can
also
be
deployed
in
a
containerized
environment.
That's
what
we'll
talk
about.
A
One
of
the
things
that
you
get
from
this
architecture,
obviously,
is
the
built-in
visibility,
because
you
log
into
one
place
the
AVI
controller
and
you
have
visibility,
insights,
analytics
data,
telemetry
points
to
this
entire
distributed
fabric.
The
other
is
automation,
we're
built
on
a
hundred
percent
open
API,
and
you
can
automate
based
on
what
we've
already
done.
The
work
that
we've
already
put
into
other
third-party
integration
tools-
and
then
lastly,
is
the
capacity
the
performance
of
this
fabric
can
expand.
A
We
call
this
elastic
h.a
and
we
can
show
a
little
bit
of
this,
but
we
can
expand
and
contract
this
fabric
based
on
real-time
traffic
needs.
Sometimes
it's
predictable.
Sometimes
you
know
that
you
have
a
registration
event
or
a
particular
seasonal
traffic
event
that
comes
up
and
you
can
pre-plan
for
that.
Others,
such
as
a
volumetric
attack
a
DDoS
attack,
for
instance.
You
can't
plan
for
those
things,
so
we
can
expand
and
contract
on
demand,
as
the
traffic
dictates
all
right.
So,
let's
just
focus
on
the
containers
piece
and
specifically
container
networking
challenges.
A
We
talked
a
little
bit
about
the
legacy
component
right,
the
traditional
load
balancers
or
a
DC's
that
are
out
there.
Proprietary
hardware
very
inflexible
static.
It's
it's
sometimes
very
difficult
to
move
into
a
multi
cloud
deployment
model.
That's
one
side
of
the
of
the
spectrum,
then
the
other
is
these
lightweight
proxies
traditionally
deployed
in
an
open-source
format,
but
the
the
downfall
with
those
is
that
they're
not
fully
featured
that's
a
huge
issue.
They
might
be
providing
services
for
that
one
particular
application,
but
that's
it.
A
You
don't
necessarily
have
the
the
the
wide
range
of
application
services
that
you're
used
to
in
a
traditional
ADC,
a
lot
of
of
do-it-yourself
that
it
can
take
quite
a
bit
of
operational
effort
to
get
these
things
up
and
running
or
working
with
other
third-party
tools.
And
lastly,
and
probably
the
most
important
for
this
conversation
is
that
you
oftentimes
will
have
different
solutions
for
both
north-south
and
east-west
services
and
I'm
gonna
touch
on
that
a
little
bit
more
so
container.
Networking
requirements
specifically
for
openshift.
A
These
are
the
things
that
we're
here
to
address
when
we
deploy
in
an
open
shift
environment
service
discovery
is
a
big
one.
We
can
automatically
go
out
and
discover
all
the
services
that
are
already
running
and
in
the
OpenShift
master
and
pull
them
into
the
avi
configuration.
We
also
have
global
and
local
application
services.
So,
as
you
look
to
deploy
between
different
data
centers
between
different
cloud
environments
between
different
theaters
or
regions,
we
can
all
do
that
in
one
seamless,
dataflow
application.
Maps.
A
There's
no
way
for
me
to
explain
this,
so
we're
gonna
show
it
to
you
in
the
demo.
It's
really
slick
and
cool,
but
it'll,
allow
you
to
manipulate
the
entire
OpenShift
environment,
application
performance
monitoring
again,
it's
that
insight
to
both
the
north-south
that
ingress
traffic
as
well
as
the
east-west
and
we're
gonna
show
you
that
as
well
and
then
the
security
micro
segmentation.
So
when
you're
talking
about
true
application,
service
discovery
and
segmentation
for
security
services,
that's
all
built
in
and
available
through
avi.
A
Alright,
so
the
first
very
common
deployment
for
any
type
of
a
OpenShift
or
container
deployment
or
container
environment
is
going
to
be
that
ingress
north-south
traffic.
You
have
an
end-user
client,
that's
coming
in
they're
asking
for
a
DNS
query.
We
respond
with
the
appropriate
address
and
we
will
get
them
to
whatever
node
or
pod.
That
service
is
living
in
right,
we'll
even
load-balanced.
A
The
second
thing
that
I
touched
on
earlier
is
that
east-west
part,
how
do
we
do
the
exact
same
thing
now
as
far
as
delivering
those
application
services?
Only
within
the
openshift
cluster
oftentimes?
It's
not
just
an
end-user
coming
into
the
environment
from
the
outside
right.
It's
it's
one
service
connecting
to
another
service.
We're
gonna,
provide
the
exact
same
level
of
ADC
services,
the
load,
balancing
the
the
cache
compress
SSL,
whatever,
whatever
you
need
from
an
ADC
standpoint,
we're
going
to
now
provide
that
between
services
inside
the
cloud.
A
A
What
we
can
do
is
create
two
strands:
two
flavors
of
the
same
application.
If
we're
running
everything
on
version
one
or
the
blue
deployment,
we
can
take
all
those
services
and
gracefully
bleed
them
off
we're
not
going
to
necessarily
kill
them,
but
we'll
bleed
them
off.
So
the
service
is
coming
into.
The
blue
deployment
are
gonna
remain
until
they
gracefully
die.
In
the
meantime,
we
can
stand
up
the
green
app
and
we
can
start
sending
new
connections
over
to
that
application.
A
A
Sorry
I
forgot
my
builds
here.
The
second
use
case,
which
is
another
pretty
common
one
but
can
often
be
dismissed
or
forgot
about,
is
the
fact
that
a
lot
of
times
the
traffic
will
initiate
from
inside
of
the
cluster
and
it
will
try
and
reach
a
service
that
is
outside
of
the
cluster.
In
this
case,
we
have
a
database,
that's
living
outside
of
the
cluster
it's
initiated
inside.
We
need
to
be
able
to
protect
that
database
with
a
firewall
of
some
kind
databases.
Excuse
me.
A
In
this
case,
this
step
has
already
been
done.
It
takes
roughly
30
seconds
to
set
up
from
the
beginning.
I
didn't
want
to
have
to
do
it
live
here
so
that
that
piece
is
already
done.
What
we
are
going
to
show
you
is
how
we
bring
up
the
avi
controller,
how
it
identifies
all
of
the
different
nodes
inside
of
the
avi
cluster,
and
we
will
deploy
a
service
engine
per
node.
That's
already
in
existence
there
step
three
is
we'll
deploy
an
application
and
step
four.
A
A
And
we
have
now
the
service
engines
up
and
running,
so
what
that
meant
is
that
our
controller
has
created
this
cloud.
It's
gone
off
and
it's
it's
talked
to
the
OpenShift
bus.
It
has
decided
that
there
are
three
openshift
nodes
that
are
out
there
in
existence
and
we
deployed
a
service
engine
that
that
load
balancer,
that
software-defined
load
balancer
inside
of
each
of
those
nodes.
A
So
this
is
living
inside
of
natively
inside
of
the
OpenShift
cluster
right
now
and
along
with
that,
we
are
taking
all
of
the
the
the
projects
that
we
have
listed
here
that
you
can
see
inside
of
openshift.
We
we
associate
all
of
those
projects
specifically
with
tenants
inside
of
avi.
Now
tenants
to
us
is
just
a
way
to
create
a
multi-tenant
environment,
so
you
can
create
projects
inside
of
OpenShift.
That
will
equate
to
tenants
inside
of
AVI.
A
A
And
there
they
go
they're
starting
to
fill
in
we're
waiting
for
the
health
checks
to
complete.
We
want
to
make
sure
that
they're
up
and
running
successfully
and
as
soon
as
they
are
we'll
start
throwing
some
traffic
at
them
will
generate
some
traffic
and
start
putting
load
on
them.
Now.
What
Bhushan
just
did
is
he
changed
from
a
list
view
to
a
map
view,
and
this
is
going
to
show
the
the
application
map
that
are
referred
to
in
the
slide
and
once
we
start
generating
traffic
now
you'll
start
to
see
this.
A
When
we
dig
into
it
a
little
bit,
we
can
show
exactly
what
what
metric
we
want
to
look
at
so
right
now
we're
looking
at
latency.
We
can
take
a
look
at
throughput
or
we
can
take
a
look
at
the
errors
we
know
exactly.
This
is
the
visibility
that
we
were
talking
about.
We
know
exactly
what's
happening
between
each
of
these
services,
that's
already
deployed
or
that
we
created
live,
and
we
can
now
map
out
exactly
which
service
should
be
talking
to
which
service
and
secure
that.
A
So
before
we
throw
this
into
production
environment,
we
can
lock
down.
The
communication
that
we
know
should
be
should
be
available
to
talk
to
each
other,
throw
it
into
production,
and
now
we
don't
have
to
worry
about
any
any
security
breaches
within
the
cluster
itself.
We
can
do
that
by
whitelisting.
So
right
now,
we've
pulled
up
a
whitelist
and
we've
secured
catalog
to
only
be
able
to
talk
to
marketing
and
inventory.
Those
two
services
are
what
can
talk
to
catalog
in
this
particular
case.
A
A
So
we're
gonna
go
into
the
analytics
of
this
application.
This
is
the
exact
same
level
of
visibility
that
you
get
from
every
single
virtual
service
that
you
can
figure
inside
of
avi.
This
could
be
a
bare-metal
server
running
in
a
data
center.
It
could
be
an
open
shift
node.
It
could
be
an
AWS
instance
GCP
instance.
It
doesn't
matter.
We
give
incredible
insight
and
data
analytics
to
every
virtual
service.
A
We
have
both
significant
and
non
significant
logging
capabilities,
and
here
you
start
to
see
the
examples
and
if
we
click
on
one
of
these,
what
you
see
is
really
cool,
because
we
can
show
you
exactly
the
communication
path,
the
data
path
between
the
end
user
and
the
back
end
server.
So
we
know
exactly
how
long
each
segment
takes
the
the
LAN
connection,
perhaps
the
local,
the
local
network,
the
which
is
the
server
RTT,
the
app
response.
So
we
know
exactly
what
the
communication
and
latency
looks
like
inside
of
the
application
and
then
the
data
transfer.
A
If
that
application,
has
to
go
back
and
call
a
database,
we
know
how
long
that
takes.
Each
of
those
segments
is
stitched
together
and
we
present
it
to
you
both
ingress
and
egress,
for
a
total
round-trip
time
now.
In
this
case,
it
was
extremely
quick,
2
milliseconds
for
the
entire
transaction
to
take
place,
but
there
will
be
others
where
we
can
pinpoint
exactly
where
there
may
have
been
a
delay.
So
that's
that's
really.
It
I
appreciate
everybody
listening
in
and
have
a
great
afternoon.
Thank
you.