►
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
So
it
is
a
start
for
the
session
about
api
gateways
proxies
and
different
cloud
connectivity
patterns
for
developers.
Let's
start
with
small,
with
small
premise,
and
in
this
talk
we're
going
to
be
talking
a
lot
about
the
microservices
and
when
you
start
develop
this
microservices,
it's
small
is
nice,
it's
nice!
It
does
exactly
what
you
were
planning
it
to
do
and
after
that
that's
that's.
The
whole
purpose
of
microsoft
is
just
do
part
of
the
job.
That
was
the
part
of
the
job
that
that
needs
to
be
doing
something.
A
It's
micro
service
over
time.
Your
micro
service
needs
to
communicate
to
us
to
other
micro
services
and
adding
some
additional
functionality.
That
might
not
be
part
of
the
initial
mvp
initial,
the
business
task.
This
microservice
needs
to
be
doing
because,
apart
from
doing
the
business
task,
that
microservice
was
designed
to
do
there's
always
there's
always
day
two
responsibilities
day.
A
Two
responsibilities
are
security,
connectivity,
access
control,
authorization,
authentication,
encryption
of
the
traffic
and
so
far,
and
so
on
over
the
time
you
adding
those
functionalities
into
your
microservices
and
everything
is
growing,
your
microservices
is
becoming
a
big
thing
and
stuff
that
you
do
in
in
this
microsoft.
Early
far
beyond
that,
you
initially
designed
to
the
the
service
becomes
a
very
dark
place
and
maybe
even
some
dead
coat,
and
if
you
want
to
figure
out
what
is
going
on
there
and
you
might
find
yourself
like
a
charlie's
the
character
from
italy
signing
for
that.
A
A
So
today
I'm
going
to
be
talking
about
different
communication
patterns
for
these.
For
this
you
know
this
small
services
and
there's
a
they.
These
micro
services
are
arranged
in
the
mesh,
which
is
also
foreshadowing.
Things
that
we're
going
to
be
talking
about.
A
My
name
is
victor
gamov.
I
work
as
a
principal
developer
of
the
kids
at
company
called
kong
and
in
quant
we
develop
a
tools
and
solutions
for
developers,
so
they
can
build
their
next
bex
big
thing
and
we
would
like
to
have
tools
that
allow
them
to
build
the
cloud
cloud
connectivity
in
their
apps.
I
also
a
quarter
of
upcoming
manic
book.
I
was
told
that
it
means
it
will
go
the
printer
next
week.
So
to
celebrate
this,
there
would
be
some
discount
we're
gonna,
be
talking
about
kafka
as
well.
A
We're
going
to
be
talking
about
gateway,
we're
going
to
be
talking
about
service
measure
and,
at
the
end
also
we'll
talk
a
little
bit
about
kafka.
I
spent
some
time
in
my
professional
career
working
on
kafka
and
it
says
the
release
fall.
2021.
A
The
developers
are
really
bad
on
estimating
deadlines
so,
but
that
you
can
use
the
code,
kafka
a35
and
you
can
get
35
off
on
any
edition,
electronic
or
or
or
print.
So
we'll
start
with
something.
That's
that
many
of
you
probably
heard
at
least,
but
usually
it's
something
that
meets
every
request
and
as
a
developer,
you
need
to
understand
like
what
yeah,
what
is
this
and
how
you
can
apply
this
pattern
essentially,
but
what
is
api
gateway
anyway?
So
let's
get
a
quick
recap.
A
Essentially,
api
gateway
is
architectural
before
it
becomes
a
software
becomes
before
it
becomes
the
component
of
your
system.
It's
actually
a
architectural
pattern.
Api
gateway
is
something
that
sits
in
between
it's
additional
network
hub
that
proxies
or
transfer
requests
that
from
coming
from
your
client.
That
goes
into
your
upstream
service,
the
api
that
your
client
wants
to
access,
and
you
can
do
interesting
things
around
this
api
gateway,
develop.
A
Some
of
you
might
say,
wait.
It
just
looks
like
proxy
or
like
to
be
precise,
it's
more
like
reverse
proxy,
because
it
goes
other
in
other
direction
and,
as
the
barry
allen
said
from
justice
league,
it
feels
like
a
little
bit
of
oversimplification
of
the
thing.
So,
yes,
it's
additional
network
hop
that
it
looks
like
a
proxy.
A
However,
there's
a
couple
things
where
the
this,
this
architectural
pattern
and
software
that
implements
this
can
help
so
I'll
start
with
the
I'll
start,
with
first
bar
service
connectivity,
the
connectivity
between
your
client
that
will
try
to
reach
your
application
and
connectivity
between
your
upstream
service
service
that
you
want
to
serve
through
this
api
gateway.
A
With
this
simple
use
case
with
service
connectivity,
you
want
to
provide
external
access
to
some
sort
of
service.
Your
your
your
piece
of
functionality,
you
developing
something
that
you
will
be
selling
in
future,
so
you're
developing
something
that
will
be
available
as
api
or
some
of
the
service
that
will
be
exposed
as
api.
A
We'll
start
with
some
simple
things
that,
because
we
in
these
days
were
working
on
application
layer
protocols
or
also
known
as
level
seven
protocols,
a
level
seven
will
correspond
to
level
seven
in
network
model
where
protocols
like
http
and
protocols
like
https
grpc,
will
will
sit
there.
So
those
traffic
policies
we'll
be
we're
going
to
be
talking
about
some
of
the
rules.
A
How
this
traffic
can
be,
how
this
step
of
traffic
will
work
and
when
the
client
interacts
with
our
api
gateway,
we
can
enforce
different
policies
in
order
to
add
additional
functionality.
In
some
cases,
this
api
gateway
also
can
be,
can
can
do
things
like
load,
balancing
or
like
if
you're
this
api.
It
would
be
instance
of
one
api
and
you
need
to
spread
the
load
between
different
api
calls
that
your
client
does
api
gateway.
A
Can
be,
can
load
this
at
this
balance,
in
other
things
around
enforcing
some
of
the
traffic
shaping
or
things
that
your
application
might
not
be
designed,
but
you
need
to
have
certain
rules
to
enforce
in
order
this
application.
In
order
this,
the
api
thing
will
be
available
and
will
be
compliant
with
certain
requests.
A
A
Enterprise,
the
space
space
vessel-
and
this
is
his
role
and
in
our
case
it
might
be
some
sort
of
like
a
web
service
that
will
be
accessible
through
some
sort
of
api.
Like
think
about
this,
we
designed
some
super
cool
system
that
will
be
due
image
recognition
and
it
will
be
available
through
api.
A
We
designed
this.
We
developed
this.
We
deployed
this
and
after
that,
when
we
ready
to
we
deployed
this
for
testing
and
when
we're
ready
to
ship
this
to
production,
the
some
of
the
operations
concerned
might
arrive,
so
how
you
would
enable
some
of
the
say,
load
balancing
right,
so
you
put
the
proxy
on
top
of
it,
how
you
would
implement
rate
limiting
it's
easy.
A
You
can,
if
you,
if
you
in
a
java
world,
for
example,
you
can
use
any
available
framework
that
allows
you
to
implement
like
either
it's
going
to
be
bucket
for
j
or
xylen4j
that
allow
you
to
implement
some
sort
of
rate,
limited
logic
into
your
application,
or
you
need
to
support
different
versions
of
this
api.
You
need
to
do
version
one
and
version
two,
because
when
you
start
implementing
this,
you
provided
access
to
some
of
the
better
version
of
this
api
and
a
lot
of
users
start
using
this.
A
A
So
all
these
things
needs
to
be
somehow
implemented
and
who
will
implement
those?
That's
the
question-
and
this
is
neat
part
where
you're
using
this
the
api
gateway
pattern.
You
can
offload
these
functionalities
into
pieces
of
structure
instead
of
putting
this
inside
your
application
code
again.
If
we
will
bringing
back
jean-luc
picard
at
some
point
of
his
professional
career,
he
received
some
of
the
augmentations
that
automatically
make
him.
A
He
still
performs
his
his
biological
functions,
but
also
he
received
this
automatic
augmentations
for
his
for
his
service,
so
with
the
ability
to
enable
those
additional
pieces
of
functionality.
Without
you
explicitly
code
this
without
explicitly
sitting
there
and
writing
apps,
it's
good
that
if
we,
for
example,
okay,
we
can
say
yeah
the
victor,
we
can
implement
everything.
I
understand
you
like
we
in
the
java
world,
however,
with
microservices
and
the
approach
of
building
the
systems
with
the
smaller
teams,
we
enable
those
teams
use
whatever
language
they
like.
A
If
they
want
to
use
java,
they
can
use
java
with.
If
they
want
to
use,
go,
they
can
use
go,
but
if
they
will
try
to
implement
all
these
pieces
of
functionality
as
a
part
of
their
application.
So
in
this
case
they
need
to
make
sure
that
the
framework
that
they
will
be
using
will
support
this
piece
of
functionality
and
for
that
matter
the
api
gateway
provides.
A
The
entrance
basically
admits
all
client
requests,
putting
some
of
the
additional
pieces
of
functionality,
including
rate
limiting
loading
load,
balancing
logging
capturing
some
metrics
due
rate
limiting
and
so
far,
and
so
on,
to
provide
you
access
to
any
type
of
service,
that's
available
outside
world
another
another
example.
Here
there
might
be.
You
develop
your
service
that
will
be
using
some
some
some
protocol
like
jrpc,
but
to
consume
this
service.
A
You
need
to
make
sure
that
your
clients
also
support
your
pc
with
the
capabilities
that
available
on
the
api
gateway
side
of
things,
you
can
provide
a
some
sort
of
proxy
functionality
that
will
transform
your
grpc
call
on
the
back
end
on
your
upstream
service
with
rest
that
will
be
exposed
to
client,
that's
also
possible.
It
also
can
be
done
automatically.
A
Slightly
different
and
bigger,
when
we
developed
our
api
as
a
product,
so
we
start
getting
more
and
more
apis.
Remember
let
me
show
you
remember
this.
You
know
we
started
with
one.
We
started
with
one
service.
We
started
with
something
small
and
after
that
we
actually
start
growing
our
system
we're
adding
more
services,
but
for
for
the
user,
this
needs
to
be.
A
This
needs
to
be
something
straightforward.
You
don't
need
to
enforce
your
internal
architecture
to
to
external
clients,
so
api
gateway
allows
you
to
perform
some
sort
of
aggregation
of
apis
and
based
on
the
different
endpoints
that
were
exposed
to
the
clients.
Those
would
deal
with
the
different
pieces
of
of
your
infrastructure.
A
If
you
go
in
slash
billing,
it
might
be
redirecting
you
to
a
billing
service.
If
you
go
to
slash
orders,
it
would
be
some
another
server,
it's
another.
It's
going
to
be
another
another
service,
but
think
about
this,
like
when
I
said
the
client.
It's
not.
This
client
not
necessarily
needs
to
be
a
client
external
client,
the
the
people
who
interact
with
your
product
by
by
client.
It
also
can
be
another
department
who
wants
to
use
this.
A
Your
micro
service-
and
this
is
also
applicable
for
situation
when
you
develop
the
product
internally,
so
api
is
a
product,
can
be
also
internal
things
similar
things
like
like
a
private
cloud
right,
so
the
private
cloud
is
something
that
one
team
developed
and
provided
as
a
service
to
another
team,
same
thing
here,
so
some
of
the
teams
they
develop
apis
in
organization
and
they
communicate
through
those
apis
and
those
apis
provide
as
a
product.
A
Once
this
become
a
something
that
the
people
are
on
board
with,
so
we
start
develop
like
a
platform
that
serve
needs
of
manis.
A
A
Usually
these
days
open
api
standard
is
the
way
how
the
people
using
this
kind
of
their
specification
and
agree
upon
the
contract
of
this.
Once
you
agree
about
this
contract
people
just
like
okay,
so
we're
done
we're
good.
So
now,
let's,
let's
build
our
apps
and
it's
good
that
if
one
of
the
teams
will
provide
access
to
those
pieces
of
functionality
quickly,
they
may
be.
You
know
coding,
faster
they're,
developing
things
faster
like
or
like
they
already
have
something,
but
they
need
to
change
a
little
bit
after
that.
A
This
old
api
will
be
compliant
with
the
new
specification.
However,
in
many
cases
it's
not
it's
not
true.
It's
not
it's
not
the
case
because
it
takes
time
to
say,
but
can
developers
to
develop
backhand
and
front-end
developers
to
develop
a
front-end
pieces.
So
this
is
where
the
mocking
side
of
things
comes
into
play.
What
about
take
this
part
of
specification,
or
rather,
where
is
it
yeah?
So
we
will
take
the
this
guy
we'll
take
this
part
of
specification
and
turn
it
into
living
service.
A
However,
it
will
have
us
some
mock
responses,
maybe
predefined
responses
or
if
we
design
this
responsible,
return,
200
or
503
404
this
type
of
stuff.
So
you
can
start
building
your
apps
and
api
gateway
can
actually
provide
the
ways
how
you
can
mock
these
type
of
things,
including
testing
phase
as
well,
so
how
you
would
test
your
apis,
how
you
would
test
your
specification
next
thing
is
that
support
in
a
runtime.
A
Things
that
I
I
mentioned
in
the
when
I
was
talking
about
when
I
was
talking
about
a
yeah
this
one,
so
api
is
a
product.
Different
clients
will
try
to
reach
your
api
and
also
the
most
important.
The
biggest
problem
that
many
organizations
are
facing
is
discovery.
A
They
don't
know
which
api
to
call
we
we've
watched,
which
parameters
today,
like
literally
today,
we
had
this
meeting
with
use
case
breakdown
with
one
of
our
customers
and
before
they
onboard
it,
with
some
of
the
tools
that
I
will
be
talking
about
in
a
few
seconds,
the
huge
biggest
problem
for
them
was
discover
apis
discover
what's
available,
so
the
new
teams
start
developing
some
of
the
pieces
of
functionality
that
will
be
helping
to
drive
business.
A
They
don't
know
if
there's
something
is
available.
Some
api
is
already
available
or,
if
it's
available,
but
in
a
you
know
what
form
so
the
api
gateway
has
opportunity
to
not
only
take
this
specification.
That
was
the
part
of
design.
That
was
something
that
we
designed
here
on
design
phase,
but
also
we
can
generate
a
developer
portal
that
will
include
all
information
about
what
api
available
documentation.
A
Some
of
the
snippets
that
the
people
can
run
to
test
this
api,
how
to
maybe
even
generate
some
sdks
based
on
this
api,
say
you
say:
there's
api
there's
back
end
and
you
want
to
develop
a
ios
client
that
would
be
cool
if
you
go
in
there
in
this
in
this
portal
and
get
sdk
that
will
be
serving
some
of
the
underlying
needs.
A
So
you
don't
need
to
implement
like
some
of
the
retries
logic
or
retrieval
or
marshalling
of
the
json
turn
it
into
some
object
that
you
will
be
manipulating
in
your
in
your
application
code.
So
those
parts
of
onboarding
are
important
here
as
well
and
now,
when
we're
successfully
running
this,
when
we're
successfully
running
this
in
in
production
things
to
understand
how
this
api
is
used,
maybe
implementing
some
sort
of
monetization
logic
to
figure
out
okay.
So
this
api
was
used
by
this
in
this
client.
A
How
we
can
understand
like
we
can
understand-
and
we
can
start
like
charging
this
or
you
know
when
I
say
charging
it
not
necessarily
needs
to
be
kind
of
like
some
of
the
monetary
value.
Maybe
there
there
would
be
some
of
the
heavy
consumers.
You
need
to
put
some
of
the
rate
limiting
on
top
of
this,
so
they
will
not
overwhelm
your
api
and
you,
so
you
continue
to
serve
this
to
other
things,
to
monitoring
to
see
if
there
are
any
errors
in
who
bring
this
error.
A
So
this
api
gateway
fella
this
this
central
thing
becoming
something
much
more
than
simple
proxy.
So
remember.
In
the
very
beginning,
we
started
with
the
simple
idea
of
just
okay,
so
we're
gonna
start
with
something
that
will
just
would
be
another
network
hop
in
in
our
application
and
after
certain
explorations
and
putting
some
of
the
more
information
and
understanding
more
information
about
this
api
gateway.
We
came
in
into
understanding
of
one
that
the
api
gateway
can
be
full
lifecycle
management
system
that
allows
you
to
do
things.
A
But
let's
talk
about
next
things
when
I
said
gateway
admits
it's
essentially
some
something
or
someone
who
invites
you
to
to
join
right.
Think
about
this
as
a
host
of
the
party
host
meets,
you
checks
your
credentials.
That's
your
of
authentication,
authorization,
metaphor
checks
your
credential
and
allows
you
to
to
enter
system,
and
it
would
be
weird
or
maybe
not
so
you
might
have
so
the
next
thing
that
you
need
to
go.
You
go
into
the
party.
A
You
meet
this,
the
host,
who
invites
you
and
you
go
into
party
enough-
that,
in
order
to
figure
out
what
is
going
on
there
in
order
to
understand
where
you
should
go,
you
can
meet
other
hosts,
maybe
maybe
other
proxies
so
internally.
There
could
be
like
multiple
different
proxies,
but
what
if
we
can
take
this
proxy
functionality
and
provide
the
general
knowledge
about
what
is
going
on
on
this
body
through
different
guests?
Who
can,
after
that
propagate
this
information?
To
you
think
about
this?
A
Like
you
joined
the
party
and
after
that
there
would
be
someone
who
will
explain
you
everything.
So
you
already
came
in
to
party
and
someone
will
greet
you
and
say
hey
so
welcome
to
this
party.
You
can
find
this
stuff.
Is
there
the
restrooms
there,
the
our
the
one
cat,
the
the
table
and
or
or
or
this
like
a
open
table?
Everything
would
be
available
there.
So
you
know
how
to
do
this,
so
with
this
we
will
have
some
sort
of
centralized
control
that
allows
to
guests
to.
A
You
know,
perform
their
duties
as
guests
in
in
a
way
how
they
wanted
to
do
it.
You
know,
and
there
would
be
no
no
need
to
ask
permission
every
time,
you're
already
there
and
you
will
give
them
permission
to
do
so.
So
this
is
where
we're
going
into
the
into
the
place
that
I
like
to
demonstrate
with
another
star
trek
reference.
A
So
in
this
case
we
talk
about
our
borg,
collective,
so
remember
so,
with
these
augmentations
that
the
proxy
or
this
api
gateway
provided
to
our
service.
Other
services
got
the
same
augmentations
now
the
global
control
and
how
those
services
are
communicated
to
each
other.
They
can
communicate
directly.
They
don't
necessarily
need
to
go
through
some
centralized
the
service
discovery
mechanism.
A
They
just
know
there
is
convention
how
they
can
communicate
and
they
don't
need
to
have
a
central
place
to
ask
how
to
how
to
communicate
to
each
other.
So
in
this
case,
the
services
are
relatively
independent,
but
they
still
have
certain
augmentations
that
I
was
talking
about
all
these
things
around.
A
The
traffic
traffic
management
traffic
shaping
and
so
far
so
on,
and
they
will
form
a
some
sort
of
thing
that
will
be
performed
as
as
one
whole
thing
in
in
star
trek
movies
we
were
introduced
to
concept
of
war
queen
and
the
war
queen
is
was
the
entity
that
can
control
and
have
a
centralized
brain
of
the
operation.
A
So
essentially,
this
is
a
fantastic
illustration
of
of
concept
of
service
mesh
with
service
mesh.
We
do
have
let
me
point
out
here
so,
with
the
service
mesh,
we
have
control
plane.
That's
our
brain
of
operation,
there's
something
that
knows
a
little
bit
more
about
everything
and
the
information
persisted
somewhere.
A
A
It's
our
borg
drones,
as
you
can
see
here.
This
is
our
service.
This
is
our
jean-luc
picard
over
here.
So
let
me
this
is
our
jean-luc
picard
here.
A
Or
some
others
who
get
into
a
borg
assimilation
process-
and
this
is
our
augmentations-
this
is
our
augmentations.
This
is
something
that
allows
us
to
perform
some
extra
work
without
interfering
with
our
service.
This
is
service
mesh
architecture.
In
a
nutshell,
we
have
a
control
plane
that
has
some
information
about
the
the
traffic
policies
and
how
these
services
will
communicate.
A
We
have
our
data
plane.
This
is
something
that
a
small
proxies,
more
small
gateway
that
sits
next
to
your
service
and
provides
you
ways
how
you
can
communicate
with
other
services
or
you
can
communicate
with
war
queen
and,
most
importantly,
that
our
service
stays,
as
is
we
don't
need
to
do.
We
didn't
need
to
do
any
modification.
It
starts
out
with
this
architecture,
with
the
additional
proxies
that
will
sit
next
to
our
service
and
the
way
how
it
will
be
implemented
in
the
real
world.
A
I'll
talk
in
a
few
minutes,
we
can
do
multiple,
interesting
things.
We
can
start
by
defining
some
of
the
more
granular
traffic
rules
between
what
service
can
access
what
service.
In
this
case,
we
can
enforce
different
entitlements.
So
not
necessarily
all
the
services
needs
to
have
access
to
all
the
services
we
can
enforce
things
like
traffic
level
encryption.
A
Our
services
will
will
encrypt
the
traffic
communication
between
each
other,
and
this
thing,
most
importantly,
can
be
automated
and
automatically
updating
certificates
when
the
certificate
will
expire
after
certain
time.
So
this
is
our
our
borg
ship
that
we
have.
A
Next
thing,
with
the
with
the
borg,
we
might
have
a
multiple
different
cubes
and
those
different
cubes
can
also
communicate
through
this,
and
the
service
mesh
allows
us
to
create
so-called
multi-multi-zone
mesh.
So
we
can
deploy
our
services
in
multiple
different
data
centers
and
we
can
span
one
mesh
across
multiple,
multiple.
A
A
That's
the
service
mesh.
Now
you
can
ask
okay,
so
it's
all
good
and
nice,
and
very
interesting,
but
like
which
way
which
one
to
choose
like
which,
which
is
which
sometimes,
when
you
start
reading
things
in
internet,
the
people
talking
about
okay,
so
gateway
is
the
for
north
south
traffic
and
the
service
mesh
is
for
east-west
or
west
east
traffic.
What
does
it
even
mean
like
why
we
need
to
like
it's
probably
natural
for
us
people?
I
don't
know.
A
I
noticed
that
u.s
people
are
very
good
oriented
in
in
the
in
in
the
environment.
They
know
where
the
north,
they
know,
where's
east.
So
this
one
oh
go
to
east
go
to
west.
I
don't
understand
this,
like
I'm
a
geographically
impaired,
and
I
cannot
figure
out
this
without
compass
or
gps
or
whatnot,
so
I
need
to.
I
need
to
have
like
a
simple
instructions.
I
need
to
have
instructions
that
say
okay
in
case
of
this
go
this
in
case
of
this
go
left,
go
right
and
so
far.
A
So
so
that's
why
I
do
have
this.
This
diagram,
that
decision
decision
diagram
that
I
want
you
to
walk
through
now,
so,
first
of
all,
which
one
to
choose
and
where
to
choose
so
we're,
starting
with
the
on
the
top
we're
developing
api
or
service,
and
we
are
planning
to
offer
this
as
a
service,
meaning
that
there
would
be
clients
there
would
be
clients
in
in
the
sense
of
customers
or
would
be
the
clients
in
the
sense
of
your
application
clients.
A
Yes,
it's
going
to
be
consumed
on
outside,
so
in
this
case
there
would
be
a
gateway
that
sits
on
the
edge
and
the
way
why
I'm
distinguishing
two
things
here
is
because
there
might
be
different
requirements
from
perspective
of
compliance,
internal
security
and
service
service
level,
agreement
that
you
have
of
your
customers,
because
if
you
offering
this
api
internally,
you
might
have
a
less
strict
requirements
on
where
it
needs
to
be
deployed
or
how
it
needs
to
be
protected.
There's
a
whole.
The
whole.
A
How
it's
called
like
the
the
division
or
whole
new
ideas
around
the
concept
of
zero
trust
and
how
the
services
need
to
trust
to
each
other?
I'm
not
going
to
cover
it
today,
but
in
in
general
idea
of
this.
Is
that,
like
nothing
is
secure
and
you
need
to
always
be
paranoid
about
security
and
paranoid
about
accessing
certain
things,
and
that's
why
the
edge
and
your
internal
api
gateway?
A
They
might
have
a
different
different
requirements,
so
so,
for
example,
for
in
external
for
age
gateway,
you
might
have
a
ssl
termination
on
the
on
edge.
So
all
the
traffic
that
comes
into
the
system
needs
to
go
through
tls
or
https,
but
internally
it
not
necessarily
needs
to
be
encrypted.
A
This
is
something
that
very
important
that
I
haven't
spoke
yet
there's
a
concept
called
a
sidecar.
It's
another
architectural
pattern.
It
means
that
there's
something
that
runs
next
to
your
application
and
will
provide
certain
pieces
of
functionalities.
Think
about
the
sidecar!
As
a
have
you
ever
seen
the
bike
with
sidecar.
So
it's
essentially
same
similar
concept
that
came
in
popularized
through
the
kubernetes.
This
architectural
pattern
is
popularized
in
kubernetes
world
unit
of
deployment
in
kubernetes
world
is
pot.
A
A
I
think
I
think
they
might
share
some
of
the
file
system
file
system
bits,
but
in
our
case
we're
more
interested
in
in
localhost
side
of
things.
Now
the
when
they
can
talk
to
each
other
through
localhost,
one
container
can
be
served
as
a
proxy,
so
all
the
traffic
that
goes
into
one
container
will
go
through
this
proxy.
So
that's
why
this
sidecar
in
reality,
many
implementations
of
service
mesh
use.
This.
A
Use
this
project
called
envoy,
it's
the
proxy
written
in
ic,
plus,
really
tiny,
and
this
is
super
fast
battle
tested
and
stuff
like
that,
and
it
can
be
used
by.
A
It
has
a
protocol
where
the
configuration
of
this
proxy
can
be
changed
in
a
runtime.
So
that's
why
it
can
be
used
as
a
your
data
plane
if
we
oops.
If
we
look
at
to
this
this
slide,
this
is
where
we're
sitting.
This
is
where
this
is
where
our
envoy
is
sitting,
it's
our
data
plane,
so
the
control
plane
sends
all
the
information
to
control
this
to
this
data
plane.
A
And
can
change
configuration
and
runtime
so
during
the
startup
of
this
pod,
one
of
the
pods
in
youth
containers?
Third,
one
container
that
can
run
it
can
modify
some
of
the
iep
table
rules.
So
all
the
traffic
that
how
happens
in
in
this
spot
will
go
through
this
sidecar
container.
So
that's
why
it's
one
of
the
rules
where,
if
you
can
afford
this,
if
you
can
do
this
in
your
deployment,
if
you
your
choice,
is
yes.
A
So
you
need
to
select,
if
you
do
part
of,
if
you're
starting
your
own,
if
you're
starting
your
own
work,
cube
or
you
creating
something
is
a
part
of
another
cube,
so
you
will
either
join
existing
mesh
or
creating
new
service
mesh.
A
A
The
api
gateway
can
still
be
the
part
of
this
picture,
so
essentially
we're
going
into
route
this
route
like
very
similar
route
here,
one
way
or
another.
You
will
need
to
have
some
sort
of
gateway,
some
sort
of
proxy,
but
it
really
depends
of
how
you
want
to
deploy
it.
If
you
deploy
this
in
a
in
environments,
where
you
can
support
sidecars,
you
go
with
service
mesh.
If
you
doing
something
that
will
be
externalized
and
available
to
outside
world
you're
going
through
the
route
of
thinking
about
this,
I
mentioned
kafka,
not
casually
casual.
A
What,
if,
for
my
application
connectivity,
I
use
kafka
how
this
like,
if
or
for
that
matter,
event
driven
approach.
I
want
to
use
event
driven
approach.
How
this
thing
that
you
were
just
talking
about
will
change.
We
changed
the
approach,
how
you're
doing
this
and
every
time,
every
time
when
we
talk
about
kafka,
I
like
to
indulge
myself
by
bringing
some
of
the
data
data
aware
and
when
I
say
data
I
mean
lieutenant
data
data,
aware
connectivity.
A
A
few
years
ago,
gwen
shapira.
A
She's,
a
she's,
the
engineer,
engineering
manager
in
in
confluence
she's,
helping
to
build
a
confined
cloud,
so
she
did
the
talk
when
she
were
talking
about
how
kafka,
similar
or
different
from
service
meshes
and
how
the
stuff
can
be.
A
How
how
engineers
need
to
think
about
this,
and
we
started
this
to
how
the
services
will
communicate.
So
essentially,
this
is
how
the
services
now
communicate
in
in
our
in
our
case
right.
So
we
do
have
one
service
that
call
another
service
and
there's
another
service
that
calling
two
services
in
order
to
get
a
response.
A
A
It
can
save
communication
or
represent
communication
between
system
in
the
form
of
log,
not
this
type
of
log.
So
I'm
not
log4j
or
something
for
that
matter,
but
rather
than
in
something
that
will
be
ordered
in
time
and
would
be
persisted
so.
A
Whole
history
of
things
that
happen
in
the
system
will
be
revolve
around
the
concept
of
immutable,
transactional
law
and
kafka
will
be
providing
the
way
where
the
information
about
the
services
will
be
stored.
So
there
will
be
no
direct
communication
between
the
systems
in
in
this
case,
you
change
the
way
how
you
thinking
about
the
services,
so
services
are
not
talking
to
each
other
in
in.
A
Using
verbs
to
communicate
and
the
passing
around
entities
like
you're
sending
this
part
of
request
response,
but
rather
you
sending
events
that
will
represent
something
that
happened
in
the
system
and
another
service
which
would
be
interesting
in
having
state
will
be
able
to
create
desired
state
for
itself.
So
this
topic
is
slightly
off
chart
of
the
or
like
a
little
bit
off
from
today's
conversation.
A
But
I
just
wanted
to
bring
this
up
that
it's
also
possible
to
to
implement
this
pattern,
even
with
service
mesh
and
api
gateway
and
some
of
the
patterns
that
you
can
use
in
your
application
design.
So
when
you
start
building
event-driven
systems,
when
you're
going
away
from
the
passing
around
entities
and
start
saying
events,
the
way
how
you
can
think
about
your
interactions
or
your
interactions
between
your
microservices.
A
A
There's
a
two
type
of
patterns
that
available
either
it's
gonna,
be
one
event
orchestration
or
event
choreography.
A
This
approach
is,
first
of
all,
it
has
a
single
point
of
failure
right,
so
your
logic
of
the
system
will
depend
on
enterprise,
service
bus
and
the
way
how
you
will
update
the
code
and
the
in
the
in
the
service,
bus
and
the
on
this
logic.
Another
approach
that
would
be
more
suitable
for
independent
microsoft
in
the
microservices
world.
It's
actually
event
collaboration
or
or
choreography,
where
each
event
or
which
each
system
knows
on
which
event
they
need
to.
A
React
there
would
be
one
topic
with
all
the
orders
and
only
if
the
new
order
will
be
placed
in
the
order
service
or
the
service
will
react
and
based
on
some
of
the
stuff
that
order
service
will
do
payment
service
will
be
invoked
so
order
service
will
prepare
the
order,
and
after
that,
we'll
send
this
to
say.
Order
was
validated
and
it's
ready
to
be
sent
to
payment
gateway.
A
Sorry
for
for
naming
is
hard
in
the
world
of
I.t.
So
when
I
say
this
gateway,
it's
not
necessarily
me
so.
Api
gateway,
it's
just
like
payment
gateway,
something
like
some
some
api
that
you
need
to
invoke,
and
so
far
so
so
in
this
case,
payment
service
doesn't
need
to
know
anything
beyond
itself.
A
It
only
knows
that
if
there
would
be
a
order
validated
event
only
this
time
the
payment
service
will
be
triggered.
So
in
this
case,
we
still
have
full
history
of
events
that
store
somewhere
in
our
event,
store
in
the
particular
case,
where
we
store
this
in
kafka
and
based
on
the
certain
the
things
that
happened
in
the
real
life.
A
A
Another
pattern
that
fits
well
into
topic
of
my
conversation
today:
it's
where
you
can
use
gateway
and
mesh
together,
so
the
your
internal
architecture
will
be
served
through.
A
The
the
communication
and
the
entitlements
will
be
based
on
service
mesh
and
your
users
user
activity-
it
can
be
user
activity
or
it
can
be,
another
services
will
try
to
go,
will
go
through
gateway,
that's
gateway,
so
this
is
our
api
gateway
and
in
quank
we
build
also
like
api
gateway
and
the
service
mesh.
The
service
mesh
that
I
was
talking
about.
It's
called
kuma,
and
this
is
where
my
application
is
running
so
users
or
like
services
will
interact
through
gateway.
A
Internally,
application
will
interact
through
service
mesh
things
around
security,
internal
security
or
like
enabling
mtls
between
service,
providing
some
of
the
traffic
policies
between
different
microservices
and
see
how
they
will
be
interacting
with
each
other
or
even
dealing
with
the
services
like
kafka
or
connecting
to
services
like
kafka
or
connecting
to
databases
and
so
far,
and
so
on
also
can
be
handled
by
a
service
mesh
service,
mesh
gateway.
A
And
in
order
to
connect
two
worlds,
there's
another
path.
Another
pattern,
and
the
the
funny
is
the
funny
story
here
is
that
it's
called
event
gateway
that
allows
us
to
bridge
event,
driven
approach
and
the
request
response
approach
so
essentially
gateway
can
expose
through
the
in
in
case
of
quant.
There
would
be
some
plug-in
that
needs
to
be
enabled
here,
but
your
application,
it's
a
rest.
Application
will
try
to
or
rest
or
jrpc
or
whatever
this
application
will
try
to.
A
So
this
is
how
you
can
use
a
gateway
in
order
to
you
know
like
from
this
from
this
particular
example,
in
order
to
bring
the
event
somehow
so
the
gateway
also
can
be
here
that
will
be
submitting
those
events
order
submit
event,
so
everything
would
be
work
very
close
together
in
order
to
to
serve
this
three
things
that
you
need
to
remember
from
today's
talk,
so
gateway
admits,
meaning
that
a
gateway
brings
the
traffic
in
to
your
system.
A
You
can
put
additional
functionality
to
to
this,
the
doorkeeper
or
or
or
doorman
door
person
to
to
do
some
additional
things.
Maybe
do
a
ssl
termination,
maybe
do
rate
limiting
in
order
like
you,
have
a
bouncer
right
that
not
allowed
to
go
as
many
people,
as
you
have
in
your
system,
so
think
about
this.
This
way,
mesh
on
the
other
side
connects
the
services,
provides
the
communication
patterns
between
a
different
application,
or
maybe
it
provides
like
a
very
fine-grained
communication.
A
Between
between
different
services,
mesh
connects
and
no
pun
intended,
but
kafka
streams
in
this
case,
like
stream
of
events
and
the
way
how
the
kafkas
can
be
can
present
here,
can
present
here
as
one
of
the
the
communication
protocols
when
I
when,
when
we're
talking
about
gateway
and
apis,
not
necessarily
this
api
would
be
100
translated
to
a
request
response
api,
a
kafka
api
becomes
very
ambiguous
from
perspective
of
how
it
can
be
used
and
from
perspective
of
actual
implementation.
A
There
is
actually
multiple
different
implementation
of
kafka
api
that
allows
different
clients
to
talk
to.
There
is
on-prem
implementation.
There
is
a
cloud
this
managed
implementation,
different
implementation
of
different
languages
and
so
far
and
so
on.
So
you
can
use
this
pattern
still,
but
you
need
to
like
figure
out
like
which
way
you
want
to
go.
Gateway
can
be,
cannot
meet
your
events
through
event,
gateway
pattern.
Remember
from
from
from
this
one,
and
I
wanna
is
a
as
a
last
a
slide.
A
I
wanna
tell
you
if
you
wanna,
learn
more
join
me
bi-weekly,
I
do
live
streams
or
we
call
it
kong
builders,
where
I'm
breaking
down
different
different
demos.
I'm
breaking
down
different
patterns
tools,
kubernetes
and
service
meshes
a
lot
of
things
so
subscribe
to
our
youtube
channel
and
join
our
community
at
the
kwank
hq
dot
com,
slash
community.
We
have
a
discus
forum
with
your
questions
and
hope.
I
will
see
many
of
you
there.
My
name
is
victor
gamov
and,
as
always,
have
a
nice
day.