►
From YouTube: Replacing Legacy Gateways at the Edge
Description
SoloCon 2022:
Replacing Legacy Gateways at the Edge
Speaker:
Jad Savek
Field Engineer, Solo.io
Session Abstract:
The edge gateway in a kubernetes environment is a key component for exposing you application and delivering your business use-cases. As applications move into a distributed multi-cloud architecture, adopting a modern api gateway become crucial for connecting and securing micro-services. In this session, we will discuss how upgrading your gateway can significantly improve your application's security, resilience and advanced routing capabilities. We will also share edge gateway architecture best practices in multi-cloud environments.
Track:
Edge and API Gateway
A
A
A
A
A
Many
solutions
and
practices
have
emerged
to
help
manage
the
complexity.
Service
mesh,
for
instance,
can
help
manage
the
complexity
of
the
communication
of
distributed
applications
based
on
microservices
github's
practices
have
become
a
standard
for
simplifying
and
standardizing
automating
application
deployment
and
configuration
let's
zoom
into
the
edge
gateway,
which
is
the
topic
of
our
session.
Once
your
applications
are
deployed
to
your
clusters,
you
need
the
mechanism
to
make
those
applications
available
for
external
consumption.
A
Let's
first
have
a
quick
look
at
the
options
for
exposing
your
application
in
kubernetes,
the
basic
option
is
service
of
type
node
port
which
effectively
implements
layer,
4
port,
address
translation
mapping,
the
kubernetes
service
port,
a
unique
port
on
the
kubernetes
host.
The
approach
is
static
and
does
not
scale
and
cloud
native
deployment.
A
The
force
for
the
option
that
we're
discussing,
which
is
the
focus
of
our
discussion
here,
is
api
gateway.
It
is
the
most
feature-rich
option
for
modern,
distributed
applications
and
can
deliver
advanced
use
cases
for
traffic
management,
security
and
observability
as
well.
It
can
implement
features
like
service
discovery,
authentication
and
authorization
resilience
patterns,
canary
releases
rate,
limiting
and
many
more,
all
of
which
would
have
otherwise
required
the
application
to
implement
them
in
the
application
code
itself.
With
all
the
complex
complexity
that
comes
with
it.
A
A
Your
existing
gateway
might
be
lacking
the
flexibility
to
connect
to
services
external
to
your
cluster,
such
as
serverless
functions,
or
it
might
be
that
your
current
gateway
does
not
natively
integrate
with
your
service
mesh
or
might
not
support.
Github's
configuration
to
integrate
within
your
automation,
workflows,
no
matter
what
the
reasons
are.
A
A
A
Approaches
for
controlling
service
releases
might
include
canary
deployment,
blue
green
deployment,
traffic
shadowing
or
others.
For
instance.
Canadian
releases
is
a
common
pattern
where
a
new
version
of
the
service
is
introduced
and
traffic
is
gradually
migrated
to
it
to
ensure
proper
operation.
Blue
green
implements
a
typical
copy
of
the
environment.
What
traffic
shadow
is
shadowing
allows
for
creating
copy
of
requests
and
sending
them
to
a
new
version
of
a
given
service
for
production
testing,
for
example,
your
edge
gateway
is
in
the
perfect
position
to
facilitate
those
use
cases.
A
You
should
expect
from
your
edge
gateway
to
be
able
to
implement
resilience
patterns
and
abstract
them
from
business
logic
of
your
applications.
Key
use
cases,
for
instance,
may
include
the
implementation
and
tuning
of
request,
timeouts
retries
circuit,
breaking
or
even
simulate
injection
fault
injections
to
determine
the
your
application
behavior
under
abnormal
conditions.
A
A
Another
simple
example
of
transformation
is
rewriting
the
request
prefix,
which
allows
for
the
modification
of
the
prefix
for
communication
with
your
cluster
services,
for
instance,
more
complex
transformation
may
include
header
transformation
such
as
adding
or
removing
a
header.
A
typical,
typical
use
case
of
such
transformation
is
the
extraction
of
jot
and
information
which
allows
for
routing
to
services
based
on
identity
for
rings,
for
instance,
or
the
implementation
of
authorization
policies.
Accordingly,.
A
A
Your
gateway
can
help
terminate
those
tls
connections
for
different
applications.
This
means
that
it
should
carry
the
certificates
required
for
encryption,
identity
validation,
which
can
be
delivered
as
kubernetes
secrets.
For
instance,
it
should
also
support
service
name
identification
to
determine
what
certificate
to
serve
depending
on
the
domain.
The
client
is
requesting.
A
Your
gateway
is
the
gate
for
the
outside
world
to
access
the
various
applications
and
services
within
within
your
cluster,
whether
there
are
monoliths,
microservices,
serverless
functions,
etc
in
microservices
or
hybrid
application
architecture.
Any
number
of
those
workloads
need
to
accept
incoming
requests
from
external
clients.
A
Incoming
requests
may
require
authentication
to
validate
and
establish
the
client
identity,
but
also
the
service
they
are
requesting
and
to
define
any
access
or
traffic
control
policies.
Accordingly,
examples
might
include
routing
to
specific
services
based
on
user
or
group
identity
or
implementing
granular
access
control
based
on
identity.
A
Your
gateway
can
offload
those
authentication
capabilities
that
otherwise
would
have
needed
to
be
implemented
in
your
application
code.
Your
gateway
should
support,
also
different
type
of
authentication
methods
that
are
required
by
your
business
units.
Common
examples
might
include
oidc
saml
and
needs
to
support,
also
different
back-end
identity
providers.
A
Let's
look
a
little
bit
at
threat
prevention.
Your
gateway
requires
as
well
the
the
implementation
of
controls
to
provide
to
prevent
common
threats
for
sure
security
has
distributed.
The
responsibility
across
multiple
layers
within
your
architecture,
but
your
edge
gateway
should
play
its
role
in
threat
prevention
from
its
unique
position
at
the
gate
for
your
application,
access.
A
A
A
gateway
can
help
implement
web
functionality
web
application
firewall,
which
can
help
protect
your
application
by
monitoring
and
filtering
and
blocking
potentially
harmful
traffic
and
attacks
that
can
export
your
application
off,
can
do
this
by
intercepting
and
inspecting
the
network
package
against
known
threats
can
be
tuned
based
on
single
or
group
of
applications
bases.
Exposing
your
applications
also
opens
the
door
for
numerous
incoming
requests
to
your
application,
and
this
requires
implementing
global
rate
limiting
per
application
and
becomes
crucial
for
ensuring
the
quality
of
service
of
your
application.
A
Finally,
let's
look
at
some
additional
additional
considerations.
An
important
consideration
is
observability.
It
is
critical
for
monitoring
your
application's
performance
and
to
be
able
to
pinpoint
and
troubleshoot
application
performance
issues.
You
might
already
have
tools
in
your
environment
for
application
performance
monitoring.
A
Those
tools
might
rely
on
telemetry
and
tracing
information
received
along
the
application
or
the
request
path.
Your
gateway
can
provide
rich
information
at
the
entry
point
to
your
application.
This
information
should
include
metrics
access,
logs
and
traffic
and
tracing
information
for
your
application.
This
information
can
then
be
scraped,
analyzed
and
used
for
reporting
or
alerting
using
tools
like
prometheus
grafana.
A
As
you
cloud
native
application
deployment
matures,
you
might
find
that
you
need
to
support
multi-cluster
application
deployment
to
meet
your
business,
high
availability
or
scalability
requirements.
You
might
also
find
that
service
mesh
is
becoming
an
integral
part
and
the
requirement
for
you
to
meet
your
connectivity
and
security
requirements.
Your
edge
gateway
is
an
integral
part
of
your
environment
and
should
be
capable
of
natively
integrating
within
your
service
mesh
so
that
it
can
meet
your
organization,
traffic
management
and
security
requirements
in
multi-cluster
deployment
scenarios.
A
Now
that
we
have
spoken
about
key
use
cases
that
your
educator
can
can
can
help
the
river
and
that
upgrading
to
an
api
like
gateway
can
can
help
deliver.
Let's
talk
how
our
portfolio
can
help
you
upgrade
your
educatory
functionality
and
deliver
true
api
gateway
capabilities
solo
that
ios
portfolio
includes
a
comprehensive
solution
that
can
meet
your
north
south
and
east-west
use
cases.
A
You
see
here
that
it
includes
glue
edge
blue
mesh
and
additional
extensions
on
top
of
them.
Blue
edge
is
a
standalone,
modern,
api
gateway
based
on
envoy
that
is
packed
with
features
to
meet
broad
range
of
use
cases
we
have
developed,
developed
tons
of
filters
that
can
that
can
implement,
be
implemented
as
change
and
deliver.
A
All
of
the
of
those
use
cases
that
we
have
discussed
blue
mesh
is
a
service
mesh
management
solution
that
solves
the
complexity,
problem
of
managing
meshes
in
distributed
environments
and
includes
blue
mesh
gateway
as
well,
which
backs
similar
features
to
glue
edge
within
the
mesh
leveraging.
Is
your
ingross
gateway?
All
those
features
can
be
delivered
via
declarative
configuration
that
fits
perfectly
in
your
automated
github's
workflow.
A
So
whether
you
need
a
standalone
gateway
that
can
deliver
quick,
wins
and
deliver
quick
business
value
or
a
gateway
integrated
within
your
match.
We
got
you
covered.
We
are
engaging
with
large
customer
base
that
is
helping
us,
improve
our
product
and
shape
our
roadmap
to
align
with
real
business
problems.
A
The
migration
strategy
might
default
differ
depending
on
your
setup
and
requirements,
but
the
one
message
I
want
to
send
here
is
that
migrating
to
blue
edge
is
very
simple.
A
simple
strategy
that
we
have
seen
working
is
the
deployment
of
your
glue,
edge
gateway
in
parallel
with
your
current
existing
gateway.
A
In
this
case,
both
gateway,
both
gateways
can
coexist
and
point
to
the
same
services.
You
can
then
set
up
different
domain
aliases
for
testing
purposes.
Once
you
validate
your
your
gateway
is
performing
as
expected,
you
can
switch
a
given
domain
for
your
traffic
to
go
to
go
through
your
blue
edge
gateway.
This
process
can
be
repeated
in
testing
staging
and
pro
to
ensure
a
smooth
transition
in
all
environments.