►
Description
Don’t miss out! Join us at our upcoming events: EnvoyCon Virtual on October 15 and KubeCon + CloudNativeCon North America 2020 Virtual from November 17-20. Learn more at https://kubecon.io. The conferences feature presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
The Past, Present, and Future of Cloud Native API Gateways - Daniel Bryant, Datawire
An API gateway is at the core of how APIs are managed, secured, and presented within any web-based system. Although the technology has been in use for many years, it has not always kept pace with recent developments within the cloud native space, and many engineers are confused about how a cloud native API gateway relates to Kubernetes Ingress or a Service load balancer. Join this session to learn about: - The evolution of API gateways over the past ten years, and how the original problems they were solving have shifted in relation to cloud native technologies and workflow - Current challenges of using an API gateway within Kubernetes: scaling the developer workflow; and supporting multiple architecture styles and protocols - Strategies for exposing Kubernetes services and APIs at the edge of your system - A brief guide to the (potential) future of cloud native API gateways
https://sched.co/ZepZ
A
A
I
always
like
to
do
a
high
level
tldr
for
my
talks.
Kind
of
set
the
direction
where
we're
going
to
go
and
provide
some
key
takeaways
early
on
edge
gateways
have
undergone
a
series
of
evolutions
driven
by
architecture.
When
I
say
edge
gateways,
I
mean
the
gateways
at
the
edge
of
your
data
center
that
are
getting
traffic
from
users
to
your
backend
systems.
Over
the
past,
20
or
so
years,
architectures
have
clearly
changed,
adopting
microservices
and
kubernetes
moving
to
that
cloud.
A
Native
way
of
working
not
only
changes,
the
architecture
microservices
and
functions,
but
also
the
workflow
changes
too,
and
therefore
you
need
to
choose
your
cloud,
api
gateway
solution
intentionally
and
the
kind
of
hidden
message
in
this
talk
really
is
it's
not
just
about
the
cloud
native
api
gateway?
It's
about
any
part
of
your
platform,
the
change
in
architecture.
The
change
in
workflow
dictate
different
requirements
to
our
platform
components.
So
you
need
to
think
about
the
api
gateway.
A
This
is
me
at
daniel
bryant,
uk,
on
github,
twitter
and
so
forth.
I
work
as
a
product
architect
at
datawire.
I
also
do
a
lot
of
work
in
the
java
space
right
for
info
cue.
I've
done
a
book
with
my
buddy
abraham
marin
perez.
You
can
find
me
on
twitter
and
the
datawire
slack
and
on
the
kubernetes
slack.
A
If
you
want
to
chat,
please
do
reach
out
to
me
so
when
I
say
the
edge
in
this
talk,
I'm
talking
about
the
boundary
between
your
data
center
and
your
users
edge
is
one
of
those
kind
of
overloaded
terms,
but
this
is
what
I
mean
when
I'm
talking
about
edge
in
this
talk
now.
The
thesis
as
I
mentioned
at
the
tldr,
is
that
the
evolution
of
the
edge
has
been
driven
by
application
architecture
over
the
past
25
years
or
so
so
I
think,
back
to
1995.
A
I
was
actually
in
high
school
here,
but
just
getting
into
doing
a
bit
of
work
on
the
side
I
was
loving
java.
I
was
seeing
a
lot
of
java
j2ee
java
monolithic
applications
back
in
the
you
know
in
the
90s
we
weren't
even
sure.
If
the
web
web
browser
was
going
to
be
the
delivery
mechanism,
applets
were
there
and
a
bunch
of
other
things
too.
But
fundamentally,
it
was
a
client
server
type
architecture
with
a
database.
A
A
A
This
is
when
we
started
to
see
the
rise
of
software
proxy
software
edge
gateways,
though
aj
proxy
in
2001
engine
x,
both
doing
fantastic
work
in
the
early
2000s.
The
software
load
balancer
was
still
targeting
sysadmins.
It
was
kind
of
you
know,
pre-devops
devops
wasn't
really
a
thing
back.
Then
purpose
was
still
very
much
the
same
as
the
hardware
load,
balancers
high,
scalability,
high
availability
and
it
offered
very
much
the
same
features
but
the
beauty
of
being
software
was,
it
was
more
malleable.
A
You
could
easily
more
easily
configure
it
and
it
also
was
often
cheaper
to
run.
You
didn't
require
dedicated
harbor
anymore
to
run
the
actual
load
balancer
2005
time.
This
is
when
I
started
my
career
just
finished
college
or
university.
Web
2.0
was
all
the
rage
as
silly
as
it
may
seem.
Now.
This
was
massive.
I
did
a
lot
of
work
in
the
e-commerce
space.
A
lot
of
work
with
google
maps
too
ajax
was
a
big
thing.
Anyone
who
talks
about
ajax
probably
shows
their
age
like
me,
but
this
was
a
really
big
thing.
A
It
drove
interactivity
with
the
web,
which
we
hadn't
seen
before,
with
the
standard
request
and
response
model
pre-ajax.
It
was
all
I
make
a
request.
I
get
the
response
back,
I
make
another
request.
I
get
a
whole
html
page
back
ajax
and
the
xml
http
request.
Object
fundamentally
changed
all
this.
We
could
make
smaller
calls
and
dynamically
update
our
web
page,
and
this
at
the
time
was,
was
revolutionary.
A
It
did
put
more
strain
on
the
back
end,
though
no
longer
be
doing
one
big
request
and
response.
You
were
now
doing
the
initial
big
request
and
response,
but
lots
of
smaller
requests
to
fill
in
bits
of
the
web
page
and
the
dom
dynamically.
So
this
drove
the
rise
of
something
called
an
application
delivery
controller
adc
the
primary
target
again
was
still
sysadmin
admins,
but
it
was
all
about
acceleration
at
the
application
level.
A
So
high
availability,
ssl
offload
tll
tls
offload,
as
we
say
now,
lots
of
caching
aggressively
compression
you
know,
zipping
all
the
responses
and
and
still
doing
some
of
that
low
balancing
stuff
too
f5
engine
x,
doing
a
lot
of
work
in
this
space
of
big
ip
and
things
and,
of
course,
f
I've
now
own
nginx,
which
is
quite
interesting
too.
But
these
are
the
kind
of
primary
to
hardware
and
software
providers
to
be
fair.
A
There
was
many
others
as
well,
but
these
are
the
two
I
bumped
into
the
most
of
my
work
in
london
2010
time.
This
is
the
rise
of
the
kind
of
eye
generation
and
the
proliferation
of
apis.
You
know
it's
doing
a
lot
of
work
with
google
maps
a
lot
of
work
with
stripe
and
so
forth,
and
this
is
when
we
started
to
see
the
api
gateway
pop
up.
You
know
the
target
now
is
not
only
sysadmins
at
the
edge
of
the
systems,
but
it
was
api
developers
too.
A
Kong
started
popping
up
mass
shape
and
so
forth,
and
there
was
an
ecosystem
developing
around
these
apis.
You
know,
could
we
monetize
these
apis
and
this
gateway
was
very
much
focused?
It
was
evolving
around
this
concept.
It
looked
more
at
the
layer
7
protocol.
Typically,
this
was
http,
but
it
was
looking
at
the
http
application
level
protocol
to
do
interesting
things
based
on
http
headers.
It
would
route
accordingly
pre
this.
It
was
mainly
layer,
4,
ips
and
so
forth.
There
was
lots
of
interesting
dev
portals
analytics.
A
How
do
you
monetize-
and
this
is
really
the
first
generation
of
when
we
started
to
see
this
kind
of
hybrid
sysadmin
and
developer-
focused
product
at
the
edge
2015?
This
is
when
we
started
to
see
some
of
the
challenges
with
scaling,
particularly
you
know
like
rails
apps,
I
did
a
lot
of
work.
Rails,
love,
rails
and,
but
you
know
twitter
in
particular,
was
struggling
with
ruby
on
rails
app.
A
I
was
doing
a
lot
of
work
consulting
at
the
time
and
seeing
similar
things
rails
was
fantastic
to
get
you
up
and
running
quickly,
but
as
your
system
took
more
load,
it
was
actually
quite
challenging
to
scale
at
a
certain
point-
and
this
is
when
the
rise
we
saw-
you
know
the
monolith
kind
of
being
becoming
a
router
and
pulling
out
these
mini
services.
You
know
people
weren't
calling
at
microservices,
perhaps
at
this
time,
but
they
were
pulling
out
services.
A
This
is
when
you
see
the
rise
of
the
second
generation
of
api
gateway.
It
takes
some
of
the
routing
and
cross
functional
concerns
away
from
the
the
monolith,
the
mini,
lift
as
we're
saying
here
and
pulls
them
into
a
single
location.
Before
you
know,
every
piece
of
traffic
was
going
through
the
monolith.
You
know
twitter's
monorail,
it
was
making
routing
decisions
and
therefore
you
wanted
to
extract
some
of
that
functionality
into
an
api
gateway
to
allow
you
to
shrink
down
that
monolith,
and
this
is
what
we
saw
with
the
rise
of
second
gen
api
gateways.
A
Users
still
the
same
deal
sysadmins
devops
as
it
was
being
sort
of
called
now
api
developers
very
much
in
the
mix.
Here,
too,
you
wanted
to
centralize
cross-cutting
app
concerns,
so
things
like
auth
and
rate
limiting
you
didn't
want
to
do
them
in
each
micro
service
or
each
mini
service.
You
wanted
to
pull
them
up
into
a
gateway,
authentication
rate,
limiting
monitoring
and
routing.
These
were
the
main
kind
of
features
on
offer
with
this
second
gen
api
gateway,
so
into
cloud
native
applications
is
what
we
all
know
enough.
A
A
They
are
built,
released
and
operated
by
independent
teams.
That's
the
beauty
of
microservices.
We
can
split
up
our
application.
We
can
work
independently
on
it.
We
can
release
independently
and
we
can
scale
independently,
as
microservices
have
become
popular.
There's
been
a
rise
of
interest
around
things
like
container
technology
kubernetes.
I
did
a
bunch
of
work
on
mesos
pre,
this
kind
of
thing.
A
It
does
create
some
more
challenges
with
matching
up
the
user's
requests
to
the
back
end
services,
there's
different
locations.
Now
your
apps
might
be
running
in
kubernetes
and
vms
in
function
as
a
service.
You
know
there's
more
protocols
that
are
popped
up.
No
longer
do
you
have
to
have
just
one
protocol
and
one
monolith
you
can
have.
You
know
multiple
services,
each
doing
different
protocols,
each
doing
different
being
specialized
in
different
functionality.
A
We
see
different
load
balancing
requirements.
You
know
some
of
the
particularly
more
the
heritage
apps
I
work
with.
You
have
to
have
sticky
sessions
because
that's
just
the
way
the
app
works,
some
of
the
more
modern
micro
services
you
can,
you
know,
ram
robin
no
problem
at
all
and
there's
often
different
auth
requirements
again
back
end
systems,
heritage
systems
that
have
been
around
for
a
long
time,
often
integrate
with
custom.
A
So
this
notion
of
a
cloud
gateway
which
I
introduced,
you
know
upfront.
It
needs
a
bunch
of
different
things.
You
need
the
api
gateway,
type
management
capabilities.
You
know,
authentication
dev
portal,
metrics,
that's
very
much
faster
for
the
developers.
You
also
need
operational
support
like
adc
like
traffic
management
capabilities.
You
need
that
sort
of
resilience.
That
timeout
says
retries,
there's
rate
limiting
that
kind
of
thing
and
as
he
did
on
the
previous
slide,
you
also
need
to
weave
in
this
real-time
service
discovery.
A
A
This
means
the
typical
cloud
native
api
gateway.
You
see
now
is
a
combination
of
a
bunch
of
these
things
from
the
past,
we're
weaving
in
these
kind
of
the
primitives
of
hardware
and
software
low
balances,
we're
weaving
in
application,
delivery,
controller
acceleration
functionality
into
the
api
gateway.
Clearly,
there's
api
management
needed
as
well
and
there's
also
this
dynamic
service
discovery.
A
The
biggest
challenge,
though,
is
micro
services
lead
to
an
even
bigger
change
at
an
architecture
and
a
workflow
level
developers
are
now
on
call
it's
not
always
popular
in
some
of
the
places
that
I
go
into,
but
we
are
being
encouraged
to
own
the
services
we
write.
Yeah
netflix
talk
a
lot
about
this
notion
of
full
cycle
development.
They
seem
to
clearly
steal
still
value
operations.
They
clearly
still
value
platform
teams,
but
they
are
very
much
supporting
teams.
A
These
teams
create
platforms,
create
apis,
create
automation
and
so
forth,
and
we,
as
developers
can
consume
that
in
a
self-service
manner
to
get
our
job
done,
release
functionality
to
the
end
user,
application
teams
fundamentally
have
a
responsibility,
and
hopefully
the
authority
for
delivering
a
service
right
from
you
know,
coding,
testing
deploying
releasing
this
increased
agility
increases
the
feedback
loop
and
that's
what
we
all
want
in
this.
You
know
modern
world
right.
You've
read
the
book
by
dr
nicole
forsgren,
accelerate
jess,
humble
they
finally
did
a
lot
of
work
in
this
space.
A
This
is
a
change
in
workflow
just
to
re-emphasize
this.
You
know.
Clearly
the
architecture
is
changing
somewhat,
as
well
as
you've
seen
sort
of
over
the
history,
but
microservices
is
fundamentally
about
scaling,
developer
productivity
and-
and
we
really
not
only
have
to
think
about
the
architecture
with
our
api
gateway,
now
our
edge
gateway.
We
have
to
think
about
the
workflow
and
this
you
know
we
kind
of
have
to
update
the
thesis.
Now
the
evolution
of
the
edge
will
be
driven
by
application
architecture
and
the
development
workflow,
and
this
leads
to
a
couple
of
challenges.
A
We've
seen
quite
a
lot
in
the
datawire
team
when
folks
try
to
adopt
a
cloud
native
gateway
in
the
kubernetes
space.
So
the
two
biggest
challenges
we've
seen
at
the
edge
with
kubernetes
and
microservices.
The
first
one
is
scaling
the
edge
management.
You
know
back
when
I
was
working
on
my
java
monolith,
the
development
team,
and
I
we
owned
the
whole
monolith.
We
owned
things
like
auth
and
the
tracing
and
the
rate
limiting
and
the
circuit
breaking.
They
were
typically
implemented
as
java
libraries.
A
So
if
we
want
to
change
them,
no
biggie,
we
just
changed
them
in
the
code.
The
api
gateway
was
typically
owned
by
the
ops
team.
You
know.
Sometimes
we
did
need
to
change
the
api
gateway,
maybe
open
a
port
to
do
some
kind
of
new
protocol
support
and
to
do
that,
we
just
raise
a
ticket.
Ops
would
then
have
a
look,
give
us
some
feedback
and
eventually
complete
it.
A
Obviously,
now
we're
pulling
up
a
lot
of
these
cross-cutting
concerns
like
auth,
tracing,
caching
and
so
forth,
into
the
api
gateway,
they're,
no
longer
libraries,
but
I
as
a
developer,
still
need
to
interact
with
these
things.
You
know
these
things,
maybe
they're
called
the
experience
of
how
the
application,
how
the
back
end
services
work
now.
Not
only
is
these
being
pulled
up
into
this
api
gateway
which
ops
you
know
often
owns
the
challenge
is:
there's
more
and
more
services
being
spun
up.
A
You
know
if
I've
got
10
micro
services,
20,
30,
40
or
whatever,
if
I'm
raising
tickets
to
all
the
ops
folks,
this
is
actually,
you
know
going
to
be
a
way
to
slow
the
feedback
cycle
down.
Really
we
as
developers
need
this
self-service
way
of
configuring,
the
various
edge
management
properties.
You
know
configuring
what
we
want
when
we
expose
our
api
and
this
kind
of
leads
on
to
the
second
challenge.
We've
seen
about
supporting
diverse
edge
requirements
with
microservices,
I
don't
have
to
just
run
rest
across
all
my
platform.
A
I
can
run
rest
on
one
service,
I
want
say
a
strong
contract
and
some
streaming
capability
grpc
for
the
next
service,
and
then
I
might
want
to
say
web
sockets
for
like
a
online
chat
thing
as
well,
and
that's
not
a
problem,
because
we've
each
got
individual
micro
services
on
the
teams.
We
can
choose
the
right
tool
for
the
job,
the
right
protocol
for
the
job
and
off
we
go
now.
We
still
want
to
mix
and
match
various
cross-cutting
concerns
with
these
edge
requirements.
A
A
Stack
and
we
see
a
lot
of
green
field
projects
very
much
number
three,
but
we
see
a
lot
of
heritage
projects,
one
two
doing
their
thing,
and
some
of
them
are
also
migrating.
The
way
to
three
and
it'll
become
clear,
as
I
walk
through
these
strategies
briefly
now,
why
folks
are
doing
this,
there's
pros
and
cons
for
all
of
these
approaches
here
now,
I'm
only
going
to
cover
this
in
like
10
minutes
or
so
so.
A
If
you
want
to
know
more
I've
written
a
blog
post,
you
can
find
it
on
the
ambassador
blog
on
itunes,
bunch
of
other
places
as
well.
I
go
into
much
more
depth
that
the
team-
and
I
have
done
quite
a
bit
thinking
about
this
and
chatted
to
lots
of
end
users
and
lots
of
customers,
so
you
can
download
a
pdf
deep
dive
into
some
of
the
ideas
that
I'll
kind
of
do
a
whistle
stop
tour
of
now.
A
So
the
first
solution
is
deploying
an
additional
kubernetes
api
gateway,
and
this
is
literally
you
know
simple.
As
it
sounds
you
deploy
an
additional
in
cluster
gateway,
you
either
do
it
below
the
existing
gateway.
You
can
see
in
the
image
on
the
left.
We've
got
our
traditional
stack
above
and
then
we
spun
up
a
new
kubernetes
cluster.
A
We
put
a
new
gateway
in,
and
the
existing
api
gateway
simply
passes
through
routes
through
traffic
targeted
at
the
kubernetes
cluster,
without
doing
anything
and
the
gate,
the
old
gateway,
still
routes
through
to
the
existing
system
for
other
functionality.
You
can
also
deploy
this
under
the
layer,
4
load
balancer,
so
sometimes
folks
will
have
like
a
big
ip
type
load,
balance
up
front
or
a
global
load
balancer
these
kind
of
things,
and
you
can
simply
then
route
to
the
old
api
gateway
at
a
layer,
4
level
or
all
the
new
kubernetes
gateway.
A
A
The
cons,
however,
is
there
is
increased
management
of
working
with
two
gateways
as
much
as
it's
easy
to
spin
up
a
new
kubernetes
class.
That's
spinning
up
a
new
gateway,
that's
the
kind
of
incremental
approach.
Now
you've
got
two
eight
two
api
gateways
in
the
mix
and
the
ops
team
and
platform
team
typically
has
to
know
the
quirks
of
both
and
also
know
the
quirks
of
how
they
interact.
A
It
is
also
challenging
to
expose
all
the
functionality
to
each
independent
microservice
team.
So
it's
fine.
If
you
could
do
everything
you
need
in
the
kubernetes
world,
in
your
api
gateway,
but
if
you
need
to
modify
the
other
gateway
outside,
that's
typically
a
raising
ticket
situation
and-
and
that
can
be
a
bit
slow
in
terms
of
getting
that
fast
feedback,
you
should
try
and
push
push
as
much
edge
functionality
as
possible
into
the
new
gateway.
That's
definitely
a
sort
of
a
good
thing,
we've
seen,
and
then
you
get
those
like
the
development
teams.
A
The
microservice
teams
can
move
faster
because
they
can
do
more
things
via
the
kubernetes
conflict,
typically
of
either
kubernetes
yaml
for
edge
functionality.
It
does
need
to
remain
centralized
stuff
that
does
need
to
remain
in
that
existing
api
gateway.
You
definitely
want
to
set
up
things
like
slas.
You
know
if
we
raise
a
ticket
and
want
to
open
new
port
in
the
api
gateway
is
like
a
24-hour
turnaround-
sla,
for
example,
24-hour
service
level
agreement,
and
then
we
need
to
use
those
slas
and
factor
into
our
release
cycle.
A
A
Moving
on
to
the
second
strategy,
extending
an
existing
api
gateway.
Now
this
is
implemented
by
modifying
or
augmenting
the
existing
api
gateway
solution.
I've
seen
some
teams
do
this
custom.
Do
it
do
it
sort
of
manually
with
some
go
code
or
bash
scripts
or
whatever,
and
there
also
is
support
for
existing,
say
hardware,
load
balancers
and
the
actual
vendor
itself
has
written,
say
a
custom,
ingress
controller
or
a
custom
operator.
That
kind
of
thing
that
joins
the
dots
between
the
api
endpoints
exposed
in
the
api
gateway
and
the
back
end
services.
A
So
we
as
developers
we
write
our
deploy.
You
know
our
deployment
services
and
kubernetes.
We
might
put
some
annotations
on
there,
some
other
kind
of
metadata
and
when
we
deploy
that
yaml
when
we're
doing
a
cue
catalog
or
deploy
it
via
a
github
pipeline,
the
ingress
controller
or
the
operator
looks
at
the
annotations
on
the
services
and
then
out
of
bound
calls
out
to
the
api
on
the
api
gateway
and
makes
the
config
changes
for
us.
A
So
we're
not
manually
hacking
around
in
the
existing
api
gateway,
we're
specifying
all
our
routing
config
in
kubernetes
annotations
and
then
the
english
controller
or
the
operator
is
automating
that
update
into
the
api
gateway.
Now
pros
for
this.
You
know
you
can
reuse
existing
tried
and
trusted
api
gateway.
That's
why
we've
seen
a
lot
of
folks,
you
know
building
on
their
own
functionality
onto
the
existing
api
gateway,
and
you
can
leverage
the
integrations.
You've
got
with
your
api
gateway
with
all
the
other
on-premise
infrastructure
and
services.
A
Sometimes
you
still
need
to
do
those
changes
out
of
bounds,
and
it
creates
a
two
workflow
model
where
I
can
do
most
of
the
coding
most
of
the
changing
of
config.
In
the
kubernetes
world,
but
then
occasionally
I
have
to
raise
tickets
with
the
existing
ops
team
to
make
tweaks
on
the
on
the
api
gateway.
We
do
recommend
that
you
shift
away
from
the
traditional
api
ui
driven
configuration
model
of
the
existing
gateway
as
much
as
possible.
A
We've
had
a
few
gnarly
bugs
with
folks
we've
worked
with
where
they
have
clashes
between
the
config
they've
got
in
their
kubernetes
world
and
the
actual
config
being
loaded
say
from
the
existing
heritage
world.
Maybe
routes
overlap
or
some
kind
of
conflict
in
the
way
the
protocols
are
supported.
So
you
do
need
to
be
very
careful
about
syncing
up
the
the
old
and
the
new
world.
Here
we
also
like
to
say
before
adopting
this
strategy.
Look
at
an
architectural
roadmap,
look
at
where
you're
going
in
the
future.
A
The
danger
is
you
get
that
sunk
cost
fallacy
where
folks
are
already
committed
now
to
extending
existing
api
gateway,
and
it's
not
really
fit
for
purpose
as
you
move
and
adopt
more
and
more
of
the
cloud
native
way
of
working
so
strategy,
three,
this
is
deploying
an
in-cluster
edge
stack
all
of
your
edge
stack
now
everything
from
the
wafts.
You
know
to
the
low
balancer
and
the
api
gateway
is
deployed
actually
in
the
kubernetes
cluster,
and
it
replaces
your
existing
architecture
or
more.
If
not,
this
is
a
green
field.
A
Implementation
yeah,
if
you've
got
a
bunch
of
stuff,
that's
already
running
and
making
you
money
outside
of
kubernetes.
This
can
be
a
big
lift
strategy.
Three
can
be
a
big
lift.
We
see
a
lot
of
green
field,
folks
approaching
this
and
a
lot
of
heritage,
brownfield
solutions
wanting
to
get
towards
this
space,
but
recognizing
it's
going
to
take
them
a
while
to
do
that.
This
is
simply
deploying
all
your
edge
components
into
kubernetes.
A
It
makes
it
really
nice
then,
because
we
as
developers
on
each
of
our
micro
services,
we
can
say
you
know
perhaps
different
rules
for
the
waff
or
this
you
know
the
cdn
now
the
caching
and
so
forth.
We
can
tailor
individually
within
the
kubernetes
yaml
config.
What
we'd
like
for
our
individual
services,
which
is
very
powerful?
You
know
ops,
are
kind
of
providing
this
as
a
service
and
we
as
developers,
we
simply
consume
it,
which
you
know
I
like
quite
a
lot,
so
the
pros
edge
management
is
simplified
into
a
single
stack.
A
It's
all
running
on
kubernetes,
there's
no
pass-throughs
nice
yeah
and
it
does
very
much
support
the
the
single
way
of
working
the
single
source
of
truth.
Things
like
git
ops
githubs
can
be
challenging
to
implement
when
you've
got
strategy,
one
or
two,
where
you've
got
a
mix
of
things
going
on,
because
there
is
often
no
single
source
of
truth.
So
you
know
this
is
very
much
kubernetes
native
way
of
working.
A
The
cons
are
obvious
right.
It's
a
large
architectural
shift
asking
your
ops
team,
your
platform
team
to
move
everything
into
the
cluster
is
a
big
ask.
Right
and
probably
you
know
if
you've
got
an
existing
systems.
This
is
going
to
be
very
much
a
incremental
migration
approach,
probably
with
like
strategy
2
over
time
to
get
towards
where
strategy
3
is
at
and
platform
teams
often
have
to
learn
new
proxy
technologies.
A
You
know
a
bunch
of
folks
have
been
sort
of
using
old-school
proxies
and
then,
when
they
rock
up
to
the
cloud
native
world,
they're
more
in
tune
with
things
like
envoy,
but
envoy's
different
than
say
some
of
the
older.
You
know
hardware
and
low
balances.
They
have
to
learn
the
quirks
of
how
envoy
works
compared
to
their
old
systems.
A
The
beauty
of
this
stuff,
as
I
mentioned
already,
is
that
each
microservice
team
is
empowered
to
maintain
their
edge
config.
We
can
configure
everything
by
our
crds
for
annotations,
and
this
removes
the
burden
of
raising
tickets
with
the
ops
team
to
get
things
done,
the
stack
aggregates.
All
these
you
know
distributed
configs
into
a
single,
consistent
config
at
the
edge.
It's
very
easy.
A
If
we've
got
everything
in
our
kubernetes
yaml
to
look
at
the
yaml
and
figure
out
exactly
how
each
service
is
configured
no
longer
do
we
have
to
look
at
multiple
locations
and
we
have
to
dive
into
our
hardware
load.
Balancer.
Do
you
understand?
What's
configured
there
versus
what's
configured
in
kubernetes
and
so
forth?
A
I've
mentioned
before
a
lot
of
folks
when
they
do
move
this
way
working.
They
don't
bring
their
old
systems
with
them,
often
harbor
low
balances,
it's
quite
tricky,
to
bring
into
kubernetes
world,
so
they
do
often
look
at
things
like
envoy.
You
know
at
datawell,
we
know
macklein
and
the
lift
team.
Well,
they've
done
fantastic
work.
Many
other
folks
from
google
and
other
places
have
built
on
top
of
onboard
proxy
now
and
it's
just
a
fantastic
piece
of
kit.
You
know
we've
built
ambassador
on
onboard
proxy
and
so
we're
all
in
on
envoy.
A
So
in
conclusion,
over
the
past
25
or
so
years,
api
gateways
edge
gateways
have
undergone
a
series
of
evolutions.
This
has
primarily
been
driven
by
architecture.
We've
moved
from
hardware
to
software,
as
we've
got
more
things
in
the
back
end
and
more
requests
are
being
made
in
a
dynamic
fashion.
Software
is
more
malleable.
We
can
update
it
more
quickly,
it's
often
easier
to
scale,
it's
often
cheaper
to
scale
compared
with
hardware,
too,
we've
moved
from
layer,
4,
routing
level,
networking
to
layer,
7.
A
we're
now
making
decisions
on
routing
based
on
http
metadata
such
as
headers
cookie
values,
and
we
can
even
do
really
funky
stuff.
Like
you
know,
if
a
person
is
viewing
this
page
with
a
user
agent
that
indicates
they're
on
an
ipad
or
version
x,
we
can
write
them
to
this
service
versus
other
users
on
android,
say
route
to
this
service.
So
there
is
an
increased
demand
by
engineers
by
us,
as
developers
to
make
finer
grained
routing
decisions
and
that
we
need
the
layer
7
awareness
to
do
this.
We've
moved
from
centralized
management.
A
You
know
one
platform
team,
one
development
team
to
decentralized
now
the
platform
teams
are,
you
know,
super
valuable,
but
they
often
provide
services
to
be
consumed
in
a
decentralized
fashion
by
individual
micro
services
teams.
We
need
that
self-service
functionality
as
you
adopt
this
cloud
native
way
of
working,
adopting
microservices
adopting
kubernetes.
This
is
a
change
in
workflow.
In
addition
to
architecture,
microservices
are
fantastic:
they're,
primarily
focused
on
scaling,
developer,
work,
independent
release
being
able
to
scale
independently
and
so
forth.
This
is
a
change
of
workflow.
A
Now
we
are
multiple
teams
working
around
microservices
working
around
a
bounded
context
and
therefore
we
do
need
to
scale
edge
management
appropriately.
Individual
teams,
individual
development
teams,
need
to
be
able
to
do
a
self-service
kind
of
model
for
consuming
what
the
platform
or
ops
team
are
producing
for
them.
So
we
can
just
say
I
want
this.
You
know
waft
configuration
this
routing
configuration
and
so
forth.
All
in
our
way
we're
normally
doing
development,
which
often
there's
kubernetes.
You
know
config
files,
kubernetes
example
files.
These
days.
A
We
need
to
support
multiple
protocols
and
cross-functional
requirements
and
again
we
as
developers
need
to
be
able
to
self-service
config
how
this
is
set
up.
You
know
we
need
to
say
I
want
grpc.
I
want
it
configured
this
way
and
load
balancing
done
this
way.
This
kind
of
thing
bottom
line
it's
about,
choosing
your
solution
intentionally,
as
I
hinted
at
in
the
beginning
of
the
presentation.
A
As
you
move
to
cloud
you
know
in
terms
of
cloud
technologies,
cloud
native
architectures
cloud
native
ways
of
working.
You
often
need
to
rethink
the
traditional
approaches,
the
traditional
platform
components
that
you've
used.
You
can't
simply
lift
and
shift
your
old
way
of
working
and
you
can't
simply
lift
and
shift
your
old
technology
or
you
can
sometimes,
but
you
don't
get
the
full
benefits
of
of
what
this
whole
cloud
native
world
offers.
A
So
choose
your
solution
intentionally
really
think
about
the
needs
of
the
edge
really
think
about
the
needs
of
your
services
and
how
they're
going
to
evolve
over
the
coming
time.
So
many
thanks
for
watching
the
talk.
If
you
want
to
learn
more
the
team
and
I
put
together
a
pdf
and
accompanying
blog
posts
and
so
forth,
available
at
the
first
url
there.
We
also
chat
to
lots
of
interesting
people,
both
customers
and
thought
leaders
in
the
space
like
katie
comanji
dave,
cydia,
kelsey,
hightower
charity
majors.
We
put
those
up
on
our
website
as
podcasts.
A
You
can
find
those
on
soundcloud
or
on
the
ambassador
website
and
of
course,
we
blog
extensively
too.
So
we'd
love
to
hear
your
thoughts
on
any
of
this
content.
You
can
find
me
hanging
out
in
the
datawire
oss
slack
channel.
You
can
find
me
on
twitter
and
github
and
so
forth
at
daniel
bryant
uk.
Thanks
a
lot.