►
From YouTube: Webinar: How To Choose Right Proxy Architecture For Micro-Services Based Application Delivery
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
In this webinar, you will learn how to choose the right proxy architecture for your micro-services and Kubernetes based application delivery to balance simplicity and benefits. This is THE most comprehensive and rigorous comparison of 4 architectures, which you always wanted to know but could not find anywhere.
We will exhaustively discuss pros and cons of following 4 architecture choices
Unified ingress
2 tier ingress
Service Mesh Lite
Service Mesh
Key metrics for evaluation will include simplicity, efficiency, security, scalability, observability, integration with CNCF tools, impact on CI/CD strategy, advanced traffic engineering options, ease of deployment, skill sets required, team structure, and more. You will also learn real-life customers examples of which architecture they chose and why.
Both cloud native novice and experts will benefit from this session. Are you ready to build your own decision tree to select the right architecture, if yes, please attend this session?
Speakers:
Pankaj Gupta, Senior Director – Cloud Native Apps @Citrix
Mikko Disini, Director Cloud Native Apps @Citrix
A
I'd
like
to
thank
everyone,
who's
joining
us
today
welcome
to
today's
CNC
elf
webinar.
It's
on
how
to
choose
the
right
proxy
architecture
for
micro
service
based
application,
delivery,
I'm,
Karin
I'm,
a
CNC
ambassador
and
community
manager
on
the
Azure
container,
compute
team
and
I'll
be
moderating.
Today's
webinar
we'd
like
to
welcome
our
presenters
today.
It's
Pankaj
Gupta
senior
director
at
Citrix
music
on
the
cloud
native
application,
delivery
team
and
Nico
disini
director
on
the
cloud
native
application
delivery
team
at
Citrix,
just
a
few
housekeeping
items
before
we
get
started
during
the
webinar.
A
You
are
not
able
to
talk
as
an
attendee.
If
you
look
at
the
bottom
of
the
window,
the
zoom
window
there's
a
Q&A
box
at
the
bottom.
Please
go
ahead
and
use
that
to
drop
in
your
questions
and
we'll
get
to
as
many
of
them
as
we
can
at
the
end.
With
that
being
said,
I
will
now
hand
it
over
to
Pankaj
and
we
go
to
start
off
today's
presentation.
Thank.
B
You
Karin.
Thank
you,
honest
for
joining
the
webinar
today
how
to
choose
the
right
proxy
architecture
for
micro
services
based
application,
delivery.
I
think
this
is
the
most
critical
decision
you
will
make
to
choose
the
right
architecture
as
you
advance
towards
micro
services
based
applications
as
you
modernize
your
applications,
you
also
have
to
consider
modernizing
your
application
delivery
infrastructure,
which
is
built
on
application
delivery
controllers
also
previously
known
as
load
balancers.
B
We
have
a
pretty
packed
agenda,
we
start
with
importance
and
the
challenges
of
choosing
the
right
architecture,
and
this
is
the
only
place
you
will
find
a
very
comprehensive
view
of
various
architectures
available
in
the
marketplace.
You
need
not
to
shift
through
tons
of
information.
You
will
find
a
single
place,
various
architectures
and
pros
and
cons
for
each
one
of
them.
B
B
B
As
you
build
your
business,
critical
applications
on
micro
services
or
kubernetes
environment,
you
have
to
choose
the
right
architecture
and
choosing
right
architecture
will
determine
how
best
you
can
deliver
the
experience
to
your
users.
What
kind
of
visibility
you
get,
what
kind
of
security
you
get
and
choosing?
That
is
not
easy,
because
you
have
multiple
stakeholders
like
developers,
platform
team,
networking,
team,
SEC
of
steam,
dev
upstream
site,
reliability,
engineers
and
many
more
and
each
has
unique
needs.
B
You
have
to
also
load
balanced,
not
just
the
north-south,
which
is
traditionally
done
for
tier
3
web
applications.
But
now
you
have
to
load
balance
and
offer
same
visibility,
same
security
for
east-west
traffic,
which
is
in
a
very
simple
world,
the
traffic
between
the
micro
services
or
between
the
containers
or
among
the
parts.
B
The
biggest
challenge
is
going
to
be
the
trade-offs
between
benefits
and
the
complexity,
and
each
organization
is
a
different
journey
for
cloud
native
application.
A
skill
set,
some
are
experts
and
some
are
noise
and
we
are
going
to
provide
you
a
simple
framework
to
choose
the
right
architecture
make
no
mistakes,
architectures
are
complex
and
they
are
evolving
because
the
clause
is
changing
pretty
fast
and
there
is
a
lot
more
open
source
innovation
is
coming,
so
you
can
take
the
decision
wisely.
B
A
quick
recap
of
layer,
4
and
layer,
7
load,
balancing
simple
words
layer
for
load
balancing
is
very
simple,
very
primitive,
based
on
just
IP
address
and
ports.
It
is
also
STD
PA
and
SD
TPS
blind
and
doesn't
have
capabilities
to
rewrite
the
payload
or
look
into
the
payload
or
in
simple
words,
ability
to
do
content.
Switching
while
layer,
seven
load
balancing
is
very
feature-rich.
B
Having
a
deep
packet
inspection
capabilities
layer,
several
load
balancing
also
gives
you
better
user
experience
because
you
can
offer
and
one
special
persistence
and
in
layer
four.
If
you
are
doing
just
session
persistent
based
on
IP
address,
which
you
can
change
over
the
period
of
time,
you
may
not
deliver
the
best
user
experience
while
layer,
seven
load
balancing
takes
the
benefit
of
using
the
cookies.
B
So
even
if
the
IP
address
changes,
you
can
still
offer
the
great
experience
how
the
resources
are
allocated
for
load,
balancing
or
the
decisions
for
that
is
based
on
a
very
detailed
customizable
health
check,
they're,
seven
verses
in
layer
4,
it's
a
just
ping
or
TCP
handshake.
Only
advanced
packet,
lookup
capabilities
of
layer
7
also
helps
you
to
offer
better
security.
B
B
We
will
be
discussing
for
architecture
straight
which
we
have
plotted
today
on
Tues
exorcists,
one
is
the
complexity,
and
one
is
the
benefits
on
the
lower
bottom
most
corner.
You
see
two-tier
ingress,
which
is
the
most
simplest
to
deploy
and
takes
the
north/south
load.
Balancing
is
split
into
two
tier
ingress,
which
is
represented
here
by
green
and
the
blue.
We
will
be
discussing
a
variant
of
that
which
combines
these
two
two-tier
ingress
into
a
unified
ingress
and
the
Nirvana
or
the
north-eastern
or
the
most
advanced.
Most
feature-rich
architecture
is
sandwich.
B
Mashed,
which
has
emerged
as
a
Northstar
architecture.
For
many
of
the
companies
is
the
service
mesh.
We
are
going
to
do
a
very
detailed
insight
into
that
service.
Mesh
is
very
complex
too.
So,
if
you
want
all
the
benefits
of
service
mesh
architecture,
but
want
much
lesser
complexity,
we'll
be
talking
about
today,
the
service,
much
light
architecture.
B
This
for
architectures
help
you
to
move
to
cloud
native,
a
pure
speed.
You
can
choose
the
right
act,
architecture
by
balancing
between
benefits
and
complexity
and
whether
you
are
a
cloud
native
pro
or
a
cloud
native
nowise.
This
framework
will
help
you
to
choose
the
right
architecture
for
today
and
for
tomorrow's
means.
B
They
bring
platform
governance,
they
are
responsible
for
operational
efficiency
and
developer
agility
and
they
are
the
connecting
tissue
among
multiple
stakeholders,
starting
with
DevOps
DevOps,
top
care,
abouts
or
faster
release,
faster
deployment
cycle
automation
and
was
rollout
techniques
like
canary
and
progressive
rollout
developers,
care
about
user
experience
faster
troubleshooting
and
how
their
micro
services
are
discovered
and
does
they
are
routed
site,
reliability,
engineers,
primary
focuses
on
application
availability
that
requires
extremely
good
observability.
Quicker
incidence
response
and
post-mortems
of
the
incidence
of
those
incidents
doesn't
occur
again.
B
Net
ops
team
traditionally,
who
has
managed
and
run
application
delivery
controllers,
are
also
load
balancers.
Some
people
call
it
a
responsible
for
network
policy
compliance
and
also
managing
controlling
and
managing
the
network
and
dev.
Sir
coughs
is
all
about
application
and
infrastructure
security,
but
the
automation
is
becoming
more
and
more
important,
so
we
just
saw
at
least
six
stakeholders
and
each
unique
needs
that
gives
a
blueprint
which
you
can
use
to
evaluate
these
four
architectures,
and
these
are
the
seven
attributes
on
which
we'll
be
evaluating.
B
These
four
architectures
is
starting
with
application
security,
which
is
the
critical
requirement
for
DevOps
and,
to
be
honest,
everyone
in
the
organization
observa
T,
which
is
a
very
critical
for
SRS
continuous
deployment
for
DevOps
teams,
as
well
as
for
developer
the
scale
and
performance
for
every
team.
Member
and
the
emergence
of
open
source
tool,
has
really
accelerated
the
pace
of
innovation.
So
we'll
be
talking
about
how
different
architectures
enable
the
open
source
tool
integration.
B
Many
of
them
come
from
CN
CF
in
last
two
years,
if
Steel
is
emerging
as
a
northeaster,
open
source
control,
plane
and
we'll
be
touching
upon
how
each
architecture
fares
for
sto,
unified
control,
plane
integration
and
the
most
important
one.
What
kind
of
IT
skill
set
required
for
each
of
these
architecture?
B
B
Or
expert
it
is
still
that
simplest
and
to
get
to
the
production.
The
reason
for
that
is,
there
is
much
less
learning
for
platform
and
networking
teams.
They
still
manage
their
existing
knowledge
and
administrative
control.
Let's
go
a
little
bit
deeper
into
that
in
two
tier
ingress
for
north-south
traffic,
your
ABCs,
their
load
balances.
Are
they
split
into
two
parts
and
each
is
doing
a
different
function?
B
You
see
a
blue
load
balancer,
which
is
managed
by
platform
team
and
responsible
for
north-south
layer,
7
load,
balancing
so
for
north-south.
You
have
to
load
balancers.
One
is
green.
When
is
blue,
each
managed
by
a
different
team
and
does
a
different
function
and
you
can
run
the
authorisation
weather
on
the
green
or
the
blue
load
balancers
for
traffic
between
the
micro
services
or
kubernetes
nodes.
B
This
architecture
uses
standard,
open
source
cube
proxy
load
balancer,
which
is
a
open
source,
very
basic
layer
for
load
balancer,
which
has
the
basic
capabilities,
are
just
doing
a
round-robin
load
balancing
and
which
has
benefit
of
simplicity,
but
also
like
so
many
features,
which
we
are
going
to
look
at
pretty
quickly
why
this
is
also
simplest
and
quickest
production
because
same
blue
sorry
same
green.
A
DC
on
the
top
can
also
be
used
to
do
layer,
4
layer,
7
load-balancing,
for
your
existing
monolithic
applications.
B
Let's
look
at
the
7
attributes,
which
we
talked
about
before,
starting
with
application
security
load.
Balancers
or
application
delivery
controllers
have
been
very
effective
for
excellent
production,
for
north-south,
which
benefit
is
still
remains
to
continue
in
this
environment
also,
but
queue
proxy
have
lot
of
limitations
in
terms
of
the
application,
security
or
communication
between
the
micro
services.
B
B
B
Many
of
the
application
development
teams
are
moving
towards
continuous
integration,
continuous
delivery,
continuous
deployment
and
wants
to
use
advanced
traffic
control
techniques
like
progressive
rollout,
Canary,
automated
canary
analysis,
blue
and
green
deployment
model
faster
rollbacks.
All
those
functionality
is
pretty
applicable
here
for
north
and
south,
but
the
cue
proxy
has
limitation
with
integration
with
the
newer
tools,
so
you
leg
that
functionality
here
for
a
scale
and
performance
not
so
out.
The
scalability
is
extremely
good.
B
But
our
recommendation
is,
if
you
are
using
to
proxy
for
east-west
traffic.
Ipbs
is
the
mode
to
go
for.
Of
course,
it
is
a
little
bit
more
complex
to
deploy
than
standard
IP
table
modes
for
open
source
tool.
Integration
like
promises,
graph
Anna,
is
connector
efk
and
many
others.
You
can
integrate
extremely
well
for
north-south
traffic,
but
queue
proxy
doesn't
have
that
many
api's
and
also
doesn't
support
many
of
the
modern
open-source
tools
there.
So
you
are
limited
there
if
you
are
moving
or
considering
or
plan
to
move
to
sto
in
future.
B
In
this
architecture,
you
can
support
sto
for
North
South.
Many
of
the
ad
sees,
including
from
Citrix,
have
a
gateway
or
the
functionality
of
history
of
communication.
Api
is
included,
but
correctly
cube.
Proxy
is
not
still
enabled
and
the
most
important
one
is
the
IT
skill
set.
That
requires
the
minimum
training
for
played
from
a
networking
team
and
both
can
move
at
their
own
speed.
To
summarize,
this
is
still
the
simplest
and
quickest
way
to
production
for
cloud
native
expansion
device.
It
gives
you
excellent
security,
observer
fatigue.
B
B
Represented
here
by
Brown
ADC,
it
is
still
managed.
It
is
managed
by
platform
team.
But
here
critical
requirement
is
the
platform
team
has
to
be
very,
very
network
cell.
There
are
few
benefits
here.
You
reduce
one
ADC,
hop
or
tier,
so
it
gives
you
simplicity
from
the
previous
version,
but
the
team
has
led
from
team
has
to
be
very
network
savvy.
B
You
also
reduce
one
hop
latency
and
many
of
our
customers
are
deploying
and
considering
this
for
their
internal
applications,
but
also
it
makes
them
future-proof
if
they
want
to
deploy
external
applications
later
or
customer-facing
applications
where
they
require
where
for
SSL
to
be
added.
So
it
makes
you
future
proof
for
their
features
and
functionality
for
security,
observability,
continuous
deployment,
scale,
open
source
support
are
very
similar
or
exactly
same
to
the
previous
architecture.
So
we
are
not
going
to
go
into
details.
B
B
Simple,
provided
your
platform
teams
are
very
Network
savvy.
It
again
gives
you
excellent
north/south
capabilities
for
east-west
you
are
at
par
with
the
previous
version,
previous
architecture,
let's
move
to
the
gold
star
or
not
star
architecture,
which
is
most
advanced.
Most
modern
really
addresses
lot
of
functionalities,
which
teams
are
looking
for
north-south,
not
reformed,
east-west
traffic,
that
is
the
service
mesh.
B
Their
benefits
and
disadvantages
of
both
the
advantage
of
having
a
sidecar
attached
to
each
part
is
that
it
has
excellent
visibility
as
every
traffic
flows
through
the
sidecar,
but
it
also
adds
the
complexity.
Another
benefit
is
you
can
offload?
Some
of
the
common
functions
from
each
micro
service
to
site
are
like
retry
and
the
rhythms.
If
the
certain
micro
service
doesn't
respond.
B
Let's
look
at
into
more
detail
by
the
way
the
north-south
is
very
similar
to
what
we've
seen
in
the
first
architecture
and
for
sidecar.
You
have
choice
to
deploy
a
Citrix
EPX
as
a
sidecar
or
you
can
deploy
envoi
or
other
similar
products
for
application
security.
It's
pretty
consistent
with
the
previous
two
architectures
we
have
seen
for
north-south,
but
you
get
an
X
production
for
east-west
because
of
the
sidecar.
You
can
enforce
policy,
you
can
enforce
egress
or
ingress
policy.
B
You
can
do
the
rate-limiting,
you
can
rule
run
the
mutual
TLS
between
the
pods
or
micro
services.
You
can
run
the
encryption
between
them
and
if
you
want
to
build
super
secure
applications,
whether
you
are
in
the
finance
applications
or
where
the
you
need,
applications
for
defense
or
many
other
high
security
applications.
This
is
the
architectures
to
go
for
for
observability,
having
a
sidecar
attached
to
each
part
and
having
a
visibility
of
every
application.
Traffic
flow
gives
it
tremendous
visibility
or
observer
T,
and
you
can
build
amazing,
actionable
insights
from
them.
B
So
it
gives
it
tremendous
continuous
deployment
capabilities
through
advanced
traffic
integration
by
integrating
tools
like
a
spinnaker
for
east-west
traffic,
also
east-west
traffic,
here
inherently
benefits
from
distributed
architecture
a
scalability,
but
there
are
few
things
you
have
to
watch
out
here.
This
architecture
is
as
good
as
your
sidecar
quality.
If,
if
a
sidecar
takes
six
milliseconds
of
latency,
that
means
you
are
adding
two
hop
latency,
which
is
equivalent
to
12
milliseconds.
But
if
your
side,
car,
like
Citrix
CPX,
takes
only
one
millisecond,
then
your
performance
is
for
matters.
So
here
the
quality
of
sidecar
matters.
B
Tremendously,
one
more
caveat
you
have
to
be
aware
of.
If
you
are
building
a
very
large
micro-services
based
applications
which
has
multiple
parts,
these
sidecar
tend
to
add
up
more
CPU
and
more
memory,
because
each
requires
a
defined
memory
and
CPU.
So
these
total
CPU
and
memory
for
hundreds
of
sidecar
or
maybe
in
some
cases
thousands
of
sidecar,
can
add
up
pretty
quickly.
B
It
also
integrates
very
well
for
east-west
traffic
with
sto
api's,
but
please
be
aware,
if
you
add
this
to
your
control
plane
for
authorization,
each
packet
has
to
go
to
a
history,
a
mixer
that
may
add
that
may
add
one
more
hop.
History
or
mixer
is
going
through
a
modernization.
So
watch
out
for
this
face
how
the
next
version
of
history
of
mixer
evolves
and
how
is
scalable
it
becomes
last,
but
not
the
least,
is
the
IT
service
requirement?
B
B
This
is
the
architecture
to
go
forth,
but
please
be
aware
about
the
complexity,
but
what,
if
you
really
wanted
all
the
service
much
like
benefits
and
features
but
much
simpler?
That
is
the
fourth
architecture.
We
are
talking
here:
service
mesh
like
many
of
our
customers,
who
are
not
ready
for
service
mesh
yet,
but
want
all
the
benefits
of
service
mesh
like
secure
traffic
between
micro-services,
fine,
grained
traffic
management
observe
ready.
They
go
for
this
architecture
in
this
architecture.
B
All
the
communication
between
parts
of
micro
services
for
east-west
traffic
passes
through
a
centralized
application,
delivery
controller
in
kubernetes
form
factor,
it
could
be
a
CPX
or
it
could
be
NY
and
having
a
centralized
load.
Balancer
gives
you
policy
control
security,
gives
you
fine-grained
traffic
management,
and
you
can
implement
policy
and
observer
T
much
easily
than
the
previous
architecture.
Of
course,
you
have
to
select
the
right
memory.
Size
right,
CPU,
resources
for
purple
ABC
shown
here,
and
your
render
or
Citrix
will
be
able
to
help
you
with
that
in
terms
of
features
and
functionality.
B
A
B
Otherwise,
every
the
policy
or
security
functionality
which
you
looked
at
in
the
pure
service
match
you
can
still
implement
here
absurdity
and
continuous
deployment.
Is
that
exactly
the
same
as
the
previous
one?
From
a
benefit
perspective
for
a
scale
and
performance,
it
is
still
very
highly
scalable,
but
one
additional
benefit
for
scale
and
performance
for
this
architecture
versus
the
pure
service
match.
You
reduce
one
harm
because
you
don't
have
it
to
sidecars
between
the
two
parts.
Now
you
have
a
one
single,
centralized
load
balancer
between
them.
B
It's
the
benefit
for
open
source
tool,
integration
and
sto.
Integration
is
pretty
much
the
same,
but
for
the
IT
skill
set.
That
is
the
game
changer
here.
It
requires
minimal
training
for
platform
and
networking
tips.
The
training
requirements
or
learning
requirements
are
pretty
similar
to
the
first
architecture,
two-tier
Andreas,
which
we
have
seen
another
added
benefit
of
this.
B
If
you
already
have
a
two-tier
ingress
architecture,
you
can
very
easily
transition
this
to
this
service,
mesh
light
architecture
and
take
benefit
of
security,
better
Observatory,
better
continuous
deployment
for
east-west
traffic
or,
if
you
are
a
cloud
native,
no
vice
want
to
get
your
feet.
Wet
with
the
new
micro
services
based
application,
you
can
start
with
two-tier
ingress,
but
have
a
easy
road
map
to
transition
to
service
mesh
life
and
take
the
benefit
of
enhanced
application.
Security,
observer,
80
and
many
other
features
for
east-west
traffic.
Also.
B
B
If
you
have
a
network
savvy
teams
unified
in
races,
that
seems
like
a
great
choice,
but
you
still
let
the
east-west
intelligence,
if
you're
looking
for
a
best
observing
best
security,
the
Northstar
service
mesh
is
the
architecture
of
choice,
but
it's
complex,
but
if
you
want
to
offer
very
similar
features
of
service
mesh
but
much
simpler
service
flashlight
is
the
architecture.
Now
you
are
armed
with
four
architectures
evaluation
criteria
across
seven
attributes
and
details
about
how
each
attribute
and
architecture
fares
well
for
north-south,
as
well
as
east-west
traffic.
B
C
You
thank
you.
Punk
I'll,
try
it's
Miko
disini
I'm
in
product
management
at
Citrix
ADC.
So
let
me
talk
to
you
about
how
we've
approached
the
cloud
native
marketplace
for
our
customers
and
really
what
you've
done
is.
We've
looked
at
the
customer
requirements.
There
are
different
stakeholders
in
these
themes
and
what
you
find
is
that
the
goal
really
is:
how
do
you
insert
all
native
architecture
in
a
freely
efficient
manner
and
that's
how
we
came
up
with
this?
C
We've
we've
discovered
these
four
different
modes
of
potential
deployments
and
and
that's
what
we've
made
made
available
to
our
customers
first
of
all,
and
it
gives
them
an
option
to
start
in
one
place
and
then
move
on
to
another
another
environment
as
they
as
they
grow
and
expand
your
architectures
or
change
their
direct
apologies.
Second
thing
is
we
looked
at?
What
do
our
stakeholders
really
need?
There's
platform
theme.
Folks,
there's
an
app
developer
folks,
develop
themes
and
the
ADC
team,
and
we
discover
that
one
is
it's
important
to
insert
into
different
types
of
kubernetes
platform.
C
So
one
thing
we've
done
is
to
make
sure
that
we
can.
We
can
tie
into
different
kubernetes
distributions,
Enterprise,
create
kubernetes,
managed
services,
kubernetes
platforms
and
then
tie
into
different
CN
eyes
so
that
we
can
plug
into
these
environments
and
then
make
it
easy
for
existing
NetScaler
to
say
DC's
to
plumb
into
these
kubernetes
platforms
and
then,
as
well
as
for
the
DevOps
and
developers
who
are
new
to
a
DC's
expose.
The
api's
expose
the
Citrix
ADC
features
as
kubernetes
friendly
API.
C
So
they
can
plug
that
plug
that
in
as
part
of
the
mo
configurations
when
they
deploying
their
applications.
For
example,
third
bit
was
performance
and
scale.
So
we've
seen
this
time
and
time
again
where
new
architectures
are
deployed,
there's
a
need
for
exposing
that
the
architecture
to
outside
traffic
and
then
being
able
to
scale
that
over
time
to
two
up
to
the
production
grade,
and
so
what
they've
done
is
make
sure
that
customers
can
do
that
in
an
efficient
way.
C
They
can
leverage
the
scaling
capability
of
their
footprint
of
a
Citrix
IDC's
use
existing
clustering
technology,
for
example,
which
are
scale
out
technologies.
To
do
that
and
be
able
to
you
quickly,
adapt
to
the
changing
micro-services
footprint,
the
app
topology
as
containers
come
and
go,
and
you
containers
are
spun
up
and
the
auto
scaled
be
able
to
adapt
to
that,
so
that
the
ingress
devices
can
can
change
configurations
on
the
fly
and
then
adapt
to
this
new
app
architectures
in
terms
of
API
security.
C
A
deceased
are
used
heavily
forces
for
securing
the
traffic
into
a
perimeter
and
there's
a
variety
of
tooling
around
that
part
of
its
laughs.
Part
of
it
is
as
a
cell
and
so
making
that
available
to
our
cost
to
inside
the
kubernetes
cluster.
As
a
key
point
here
is
being
able
to
to
insert
such
policy,
so
we
can
protect
api's
that
are
being
exposed
to
these
clusters
and
in
providing
things
like
rate
limiting,
so
that,
if
particular
quarters
thresholds
are
expire,
breached
rate,
limiting
fresh,
are
deployed
and
and
and
being
able
to
use.
C
What
they've
done
is
is
be
able,
since
the
ad
sees
in
the
path
of
the
traffic
and
be
a
very
rich
set
of
data
that
we
collect.
We
can
expose
this
into
a
service
graph
as
part
of
our
ADM,
without
explain
later.
That
then
allows
customers
to
view
their
micro
services.
Look
at
traffic
flows,
look
at
layer,
seven
data
such
as
HTTP
errors,
latency
and
then
bandwidth
and
then
and
and
identify
hotspots.
C
So
next
slide,
please
bunker,
and
so
I
mentioned
tooling.
So
the
what
we've
done
is
we've
looked
at
the
the
tools
that
our
customers
are
using
and
we've
identified
that
there's
really
fuse
right.
One
is
monitoring
and
logging
and
being
able
to
plug
in
our
rich
data
to
Delta's
to
so
these
are
using
tying
into
Prometheus
and
kevanna
tying
into
if
EF
case,
as
I
mentioned,
elasticsearch
flew
in
the
affluent
Cabana
then
tying
to
tray
saying
so.
We
distribute
the
tracing
time
to
Zipkin
as
a
tracer
and
then
plugging
into
in
existed.
C
Multiple
types
of
CN
is
like
calico
panel
flannel,
for
example,
and
then
supporting
things
like
helm
and
then,
of
course,
supporting
G
RPC
so
forth.
Three
very
more
than
up
architectures
with
HTTP
two
in
G
RPC
support
support
for
those
and
we're
seeing
as
well
so
the
need
for
now
providing
value
to
the
CIC
D
pipeline.
So
we
done
integrations
with
spinnaker,
but
we
can
provide
spinnaker
with
our
rich
set
of
data
to
tell
spinnaker
and
that
an
app
is
working
well
and
therefore
we
to
continue
our
deployment
or
an
app
is
not
working.
C
Well
has
a
bunch
of
errors
and
therefore
to
rollback
our
deployment.
So
that's
that's
all
available
and
then
plugging
into
into
the
primary
Enterprise
create
kubernetes
distributions,
as
well
as
cloud-based
kubernetes
services
like
I
mentioned
near
gke,
eks,
azure,
kubernetes
servers,
open
share,
for
example,
and
then
and
now
working
on
your
steal
support,
for
you
still
believe
that
that's
an
important
future
migration
next
slide,
please
so
the
cornerstone
of
our
so
far,
implementation
for
cloud
native
is
starts
with.
C
Will
the
load
balance
ADC
is
the
load
balancers
and
the
proxies,
and
we
have
multiple
form
with
our
approaches.
We
have
multiple
form
factors
that
we
make
available
as
and
make
them
kubernetes
aware,
and
we
tie
them
into
the
into
new
workflows,
for
example,
that
developers
develop
CI
CD
tooling,
require
so
that
you
can
leverage
these
load
balancers
in
this
kubernetes
environment.
C
So,
let's
start
with
the
proxies
we
have
I
mentioned
multiple
types
of
proxies
in
different
form:
factors
that
offer
layer
four
to
layer,
seven
functionality,
virtual
load,
balancers
like
the
VPX,
it's
available,
both
on
Prem
in
the
cloud
we
have
container
base
load
balancers
like
the
CTX,
it's
available,
Society
artists
available
as
an
ingress
device.
So
we
have
recently
announced
a
bare-metal
netscaler
called
the
beat
the
BL
x4
for
Perry
metal
use
cases
for
more
modern
deployments,
and
we
have
a
a
rich
set
of
hardware
load
balancers,
the
MPX.
C
We
have
many
customers,
if
deployed
ears,
have
actually
used
the
MPX
for
Tier,
one
for
unified
ingress
deployments,
and
we
have
a
a
multi-tenant
version
called
the
STX,
where
you
deploy
multiple
virtual
load,
balancers
into
hardware
platform
and
that's
also
being
deployed
by
our
customers,
leveraging
their
existing
footprint
as
ingress
devices
for
their
clusters.
What
ties
us
all
together
is
we
have
a
very
common
code
base
of
functions
available
in
one
load.
Balancer
format
and
form
factor
is
available
across
all
form
factors,
so
that
simplifies
tooling.
C
It
allows
our
customers
to
use
their
existing
operational
tooling
to
run
to
insert
kubernetes
enter
into
their
environment.
So
that's
security
profiles,
for
example.
That's
monitoring,
for
example,
that's
layer,
7
policies
and
we
use
we
develop
a
platform
called
Citrix
ATM,
which
is
a
both
cloud
service,
as
well
as
a
on
Prem
deployment.
That
ties
us
all
together.
Adm
is
a
product
of
products.
It's
a
control
plane,
a
monitoring,
provides
monitoring
and
analytics
observability
and
it
controls
existing
NetScaler
footprints
and
modern
at
scale
their
footprints
and
modern
architectures
next
slide
for
visit
and
time.
B
Until
you
will
find
if
we
publish
a
lot
of
our
code
and
trial
versions
of
our
products
at
github.com,
if
you
have
not
checked
out
yet
github.com
slash
citrix,
I
strongly
encourage
you
to
point
your
browsers
to
github.
We
have
an
excellent
material
about.
You
can
try
CPX.
You
will
see
the
best
practices
how
to
integrate
from
Asus
and
any
other
open-source
tool,
which
also
have
lot
of
detailed
and
simple
configuration
for
these
architectures.
B
And
if
you
wanted
to
learn
more
about
citrix
cloud
native
solutions,
you
can
point
browsers
to
our
website
and
if
you
need
a
much
more
detailed
conversation
so
that
discussion
please
reach
out
to
me
co
or
myself.
Our
emails
were
there
in
the
first
slide,
which
will
be
available
later,
and
we
can
do
a
very
detailed,
deep
dive
discussion
with
your
team's
back
to
you.
Karen.
A
Awesome
thanks
conclusion:
we
go
for
a
great
presentation.
We
now
have
a
few
minutes
for
questions.
If
you
have
questions
you'd
like
to
ask,
please
drop
them
in
the
Q&A
button
at
the
bottom
of
the
screen
and
we'll
get
to
as
many
as
we
have
time
for
so
right
now.
We
have
two
related
questions.
The
first
one
is
someone's
asking
about
so
they've
been
using
ambassador
for
north-south
traffic
and
SEO
for
east-west
traffic.
While
it
does
involve.
Oh
sorry,
oh
I
get
I
got
answered.
Okay,
it
says.
A
B
C
When
you
deploy
the
app
you,
you
point
the
app
so,
for
example,
the
second
P
wrap
that
can
happen
when
you
deploy
the
app
you
you
on
the
deployment
you
you
pointed
back
to
a
the
central
load,
that
is
the
load
balancer
as
the
in
this
case.
English
load
balancers
a
service
for
other
traffic,
so
that
will
push
it
to
the
central
load
balancer,
and
then
this
would
be
consistent
with
Caracol
policies.
Making
sure
that
you
are,
you
don't
infringe
upon
any
other
Calico
network
policies
that
you
may
have
in
place.
C
C
That's
a
good
question,
a
side
car
so
he's
referring
to
service
mesh
in
this
case,
I'm,
not
I,
can't
say
that
they're
in
production,
but
I
have
customers
talking
to
us
about
service
meshed
deployments
potentially
for
2020
and
clearly
the
the
they're
looking
at
sto
and
envoy
as
the
model
I've
also
seen.
Some
of
our
customers,
who
are
using,
for
example,
console
plus
an
envoy,
is
potentially
as
much
of
autonomy
but
console
plus
another
sidecar.
B
To
summarize,
you
certainly
have
a
open
source
option
as
a
NY,
but
if
you
are
looking
for
a
more
vendor
supported,
sit
rates
does
offer
CPX
as
a
sidecar
and
if
you
want
to
do
a
trial
or
want
to
read,
get
more
information
reach
out
to
us
privately.
And
we
are
happy
to
share
more
insights
and
set
up
the
trial
or
answer
more
questions
on
that
and.
A
C
Actually
true
thick,
could
you
email
me
offline
I,
think
you
have
several
technical
questions,
I'd
like
to
be
able
to
talk
to
you
directly,
so
we
have
ideas?
Yes,
that's!
That's!
That's!
So!
First
of
all,
CP
access
based
on
we
have
a
full
TCP
stack.
So
we
have
a
lot
of
control
on
TCP
and
UDP
HTTP
HTTPS,
of
course
HTTP
too
as
well.
So
that's
one
thing
it's
wrong,
but
the
static
stack
is
that
it's
got
multi-protocol
support,
so
I've
I
have
a
better
ways
of
controlling
TCP
ports.
C
I
said
I'd
like
to
be
able
to
talk
to
you
more
in
detail
on
how
we
can
do
that
for
you.
In
fact,
the
factory
is
one
use
case
for
NetScaler
for
Citrix,
a
diseases
that
we
in
certain
applications
supporting
legacy
apps,
for
example,
because
our
ability
to
control
these
ports,
TCP
ports
and
those
were
embedded
TCP
stack.
So.
B
Just
to
summarize
Citrix
IDC's
kubernetes
environment
includes
sidecars
support,
many
of
the
legacy
protocols
which
is
not
available
in
other
offerings
in
the
marketplace,
and
we
can
walk
you
through
or
share
more
insights
on
that,
but
that's
a
huge
differentiation.
We
also
see
a
lot
of
customers
who
has
very
similar
requirement
to
support
the
protocols
which
are
supported
beyond
other
parallel
offerings
in
the
marketplace,
and
that
comes
from
supporting
various
legacy
and
emerging
protocols
over
the
many
years
with
citrix
ADC,
which
was
previously
known
as
not
a
scalar.
A
Great
thanks
to
me
go
for
a
great
presentation,
and
that
looks
like
that's
all
the
time
we
have
now.
Thank
you
for
joining
us.
The
webinar,
recording
and
slides
will
be
online
later
today
and
we're
looking
forward
to
seeing
you
all
at
you
out
of
you
to
see
NCI
webinar
have
a
great
day.
Thank
you.
Yeah
thank.