►
Description
SaaS cloud deployments are highly distributed with workflows that stitch them together to deliver differentiated services at scale and on-demand. When regulated verticals like finance customers use such deployments, the requirements around security, compliance and visibility, access control, tenant-separation with authentication/authorization, rate-limiting, ability to connect to federated identity solutions — and above all — resilience, availability and DR become critical to such deployment topology. As Symphony delivers secure collaboration solutions for FinTech with its distributed cloud stack, we will discuss how Kong played an important role as an API gateway in achieving the specific requirements above and share a customer perspective of Kong.
A
B
A
A
A
A
A
As
you
can
see,
we
not
just
do
messages
or
conferencing.
We
also
have
bots
that
actually
trade
in
our
finance
community
so
creating
these
bots,
bringing
third
party
bots
onto
our
environments,
both
on
the
client
side
and
other
api
integration
side.
To
make
this
happen
and
controlling
the
bots,
ensuring
that
their
rate
limited.
That's
critical.
So
we'll
talk
about
that.
We
raised
about
460
million
in
various
rounds
up
to
series
e
right
now,
it's
a
late
stage,
company
well
established
as
a
unicorn
in
secure
collaboration
for
the
finance
industry.
A
A
A
We
connect
multiple
clients,
whether
it's
desktop
android,
iphone
or
any
other
client,
and
even
bots
and
agents
that
come
in
with
proper
and
continuous
compliance
story.
So
our
investors
are
all
over
the
world,
but
mostly
finance
vertical.
So
you
can
see
that
so
now,
let
me
focus
on
the
role
of
kong
in
symphony
solution.
A
As
I
explained
earlier,
we
have
about
135
plus
clients,
flavors
of
clients,
mobile
web
desktop
agent.
Many
other
things
all
of
those
clients
with
proper
symphony
client
sitting
on
them
require
authentication
and
authorization
to
access
our
cloud
platform,
and
this
is
more
like
a
social
media,
fanout
effect
where
we
render
content
to
multiple
clients
and
multiple
users.
At
the
same
time,
we
have
groups
like
rooms
created
in
which
we
can
have
thousands
of
users
to
which
we
have
to
render
our
content.
A
A
A
A
There
is
a
very
critical
requirement
for
a
central
api
gateway,
and
this
is
where
kong
came
in
to
help
us
with
cons
solution.
We
built
an
api
gateway
that
controls
all
these
incoming
bots
and
users
rate
limits
them.
That
also
does
the
required
api
connectivity
to
our
api
endpoints
with
proper
authentication
and
authorization.
So
we
actually
have
the
authorization
pieces
where
sometimes
we
play
a
role.
Sometimes
the
customers
idp
plays
a
role.
A
In
any
case,
the
what
we
call
sns
key
is
exchanged,
and
then
we
created
json
web
token
and
the
jwt
is
now
verified
at
the
api
gateway
level
before
any
of
these
apis
are
allowed
inside
plus,
of
course,
standard,
not
south
routing.
So
if
you
really
look
at
the
pieces
here,
kong
has
played
a
central
role
as
our
api
gateway
that
connects
to
our
services
and
also
helps
connect
between
our.
A
This
is
the
distributed
platform.
Our
symphony
back-end
platform
has
to
connect
to
certain
multi-tenant
services,
whether
it
is
customer
plug-ins
through
a
screening
environment,
whether
it
is
multi-tenant
services
of
our
own,
like
a
directory
or
something
like
that.
We
have
to
connect
again
through
the
api
gateway
that
helps
us
arbitrate,
the
not
self
traffic
leave
alone.
A
The
fact
that
when
we
become
a
more
and
more
distributed
and
scalable
platform,
we
may
need
certain
tokens
for
the
east-west
traffic
in
a
service
mesh
like
environment,
for
which
kong
has
promised
a
few
of
their
future
solutions
as
well.
So
from
khan,
we
got
easy
plugins
for
rate
limiting
jwt
based
tokens,
and
we
also
distinguish
bots
from
users
at
the
api
gateway
level,
so
that
you
can
streamline
and
rate
limit
somebody
trying
to
automatically
create
havoc
on
the
network
with
their
bot
would
be
controlled
by
the
api
gateway
from
kong's
plug-in.
A
In
this
particular
case,
we
have
heavy
expectations
from
con
on
availability,
disaster,
recovery
and
resiliency
because
of
the
central
role
they
play
here
in
terms
of
the
benefits
feedback
and
next
steps
that
we
got
like.
I
said
it
fills
the
required
void
for
us
in
the
not
so
traffic
api
gateway
requirement
for
access
rate,
limiting
authentication
and
authorization
operations.
We
depend
on
kong,
so
what
does
this
mean?
It
requires
a
scalable
con
solution,
a
con
cluster,
a
zero
downtime,
where
we
can
actually
do
the
upgrades
in
a
blue-green
environment
and.
A
Api
gateway
cluster,
so
that
we
never
lose
connectivity.
So
if
kong
goes
down
symphony
platform,
connectivity
would
become
a
problem,
so
concreme
was
very
responsive.
They
have
given
us
some
implementation
guidance
on
the
plugins.
We
worked
together
on
resolving
few
open
questions
and
issues
and
a
joint
plug-in
development
really
helped
us,
together
to
rate
limit
our
bots
users
and
devices.
A
So
the
rollout
approach
with
kong,
api
gateway
will
be
with
these
clusters
in
a
redundant
multiple
deployment
environment.
It
is
part
of
our
ci
cd
pipeline.
The
ami
that
we
picked
up
from
kong
will
be
part
of
our
ci
cd.
We
have
good
visibility
and
api
usage
metrics
we
get
out
of
this
that
can
be
shipped
to
splunk.
A
The
integration
that
we
have
done
is
for
authentication
and
authorization,
but
for
further
multi-factor
authentication.
We
will
be
ready
to
do
such
integration
and,
as
you
can
see,
the
customers,
admin
control
of
rate,
limiting
parameters,
so
every
customer
can
have
their
own
certain
rate
limits
that
they
want
to
apply.
All
of
that
is
part
of
what
they
do
on
the
con
console
for
us
with
that.
B
Thank
you
very
much
ravi,
so
you
heard
a
little
bit
about
our
requirements
about
the
symfony
platform,
so
I'm
going
to
share
a
little
bit
about
how
we
implemented
the
api
gateway
solution
using
kong.
First
of
all,
we
decided
to
deploy
kong
on
aws
kong
is
multi-cloud
and
can
be
deployed
on
premise.
We
are
for
the
moment
more
comfortable
with
aws
for
this
initial
version
of
the
implementation
of
the
api
gateway.
B
So
we
try
to
follow
certain
architectural
principles
such
as
fully
baked
ami
model,
immutable
infrastructure,
ephemeral
instances
and
that's
how
we
approached
the
problem
and
deployed
kong's
data
plane
and
control
plane
through
an
autoscaling
group
with
ec2
instances
and
a
launch
template
that
launches
dc2
instances
based
on
a
pre-baked
ami
kong
also
requires
a
database
to
store
the
configuration
and
we
used
based
on
kong's
recommendation,
aurora
postgres,
which
is
a
fully
managed
relational
database.
Cluster
managed
by
aws,
and
some
of
the
plugins
also
require
redis.
B
Now
the
data
plane
is
just
a
reverse
proxy,
so
it
has
to
communicate
with
the
rest
of
our
platform,
which
is
depicted
in
this
diagram
at
the
bottom.
The
symphony
cloud
deployment
and
the
way
that
the
data
plane
has
connectivity
through
it
is
through
a
mix
of
different
options
that
aws
provides
us
so
for
private
connectivity
to
other
vpcs,
where
our
services
are
running.
We
use
the
transit
gateway
to
access
some
of
the
aws
services.
B
B
So,
as
ravi
mentioned
before,
we
use
splunk
for
log
aggregation,
so
our
data
plane
and
control
plane
instances
are
sending
logs
to
splunk
and
we
also
ship
metrics
to
cloudwatch
for
monitoring,
as
well
as
for
automatic,
auto
scaling
in
aws
and
alerting,
alarms
and
other
things,
and
then,
in
terms
of
our
devops
tooling,
to
be
able
to
create
this
infrastructure,
we
rely
on
terraform,
so
kong
has
provided
some
terraform
modules.
We
they.
We
loosely
based
our
terraform
modules
on
those
provided
by
kong.
B
It's
more
like
an
inspiration,
but
we
built
our
own
and
then
those
that
that
infrastructure
as
code
is
represented
or
is
versioned
and
stored
in
github.
Then
we
use
jenkins
pipelines
to
execute
any
changes
that
need
to
be
performed
on
those
clusters
either
to
create
a
cluster,
distort
destroy
a
cluster
or
modify
a
cluster.
B
B
Next,
in
terms
of
the
functional
requirements,
ravi
mentioned
a
little
bit
about
it
as
well.
One
of
the
first
requirements
that
we
had
is
a
to
build
a
multi-tenant
api
gateway.
In
our
case,
our
sas
platform
serves
multiple
customers.
Each
customer
can
have
multiple
tenants
and
for
us
to
be
able
to
build
a
multi-tenant
api
gateway.
We
used
kong's
workspace
features,
so
each
tenant
is
represented
as
a
workspace,
and
each
workspace
has
its
configuration
its
routes,
its
services
for
for
routing
purposes.
B
Kong
also
handles
the
tls
communication
with
the
client,
so
we
also
use
kong's
sni,
support
and
and
certificate
support,
and
each
workspace
also
has
a
collection
of
plugins
that
we
use
to
implement
in
the
requirements
of
authorization
rate,
limiting
visibility,
etc.
So
we've
we
use
plug-ins
such
as
the
open
id
connect,
plug-in
the
request,
transformer
plug-in
response,
transformer
plug-in
we've
created
our
own
custom,
syslog,
plug-in
based
on
the
open
source
version
of
the
of
the
syslog
plug-in.
B
B
We
transform
the
templates
and
the
data
files
for
our
tenants
that
contain
all
the
information
about
the
routes
and
the
plugins
etc,
and
through
a
jenkins
pipeline,
we
run
dec
to
apply
that
configuration
through
our
control
plane.
So
that's
how
we've
implemented
both
we
create
the
infrastructure
and
we
manage
the
configuration
of
our
api
gateway.