►
Description
Microservices and APIs are key enablers in National Bank of Australia’s (NAB) Technology strategy. In this Kong Summit 2019 session, NAB Product Manager of API Platforms, Dennis Advani talks about how NAB’s API Platform Team enabled service teams to publish their own discoverable, reusable APIs quickly and autonomously by decentralizing API development capabilities and implementing their own API Management SaaS. Adoption over the last year has been phenomenal with more than 65 service teams onboarded and more than 100 API’s published to production.
A
Development
was
centralized,
we
had
five
hood
api's
deployed
on
a
single
gateway
and
the
config
was
monolithic.
So
for
that
reason
we
would
only
release
monthly,
so
Lily
also
heavily
regulated
environment,
lots
of
checks
and
balances
and
signing
off
in
place.
So
while
we
had
a
really
mature
process,
there's
no
getting
away
from
the
fact
that
it
was
a
bottleneck.
A
A
So
by
the
end
of
this
presentation,
you'll
have
a
pretty
good
idea
of
how
the
API
platform
team
responsively
delivered
self-service,
API
management
to
the
enterprise
and
I
highlight
responsibly,
because
you've
got
to
keep
in
mind
that
you
know.
We've
got
over
a
hundred
service
teams
looking
to
play
those
their
services,
who
used
to
rely
on
us
and
they're
sort
of
effectively
being
sort
of
thrown
out
and
on
their
own.
So
we
needed
a
way
to
ensure
that
we
put
the
guardrails
in
place
to
both
protect
themselves
and
the
bank.
A
We
really
wanted
our
teams
to
focus
on
value.
You
know
the
time
to
value
and
and
and
the
value
that
they
provide
was
providing
their
services.
So
we
didn't
want
them
spending
too
much
time
worrying
about
the
running
and
the
managing
of
the
Gateway
itself.
So
we
wants
to
provide
a
real
SAS
like
experience,
so
when
I
say
SAS
like
I'm
talking
about
not
having
to
worry
about
the
infrastructure
or
the
App
of
Kong
itself,
making
sure
it
scales
for
their
needs.
We
abstract
all
the
upgrades.
It
happens.
A
All
you
know
behind
the
scenes
you
know
so
whenever
we
add
new
features
or
upgrade
Kong,
don't
have
to
worry
about
it
and,
of
course
we
need
to
implement
automatic
governance.
This
is
also
a
big
change
for
the
API
platform
team
as
well,
because
traditionally
we
were
pretty
project
driven.
You
know
like
when
projects
come
in
I
want
to
deliver
something
we
pretty
much
deliver
what
they
asked
in
this
new
world.
You
know
we're
taking
that
real
products
and
services
mindset.
A
We
need
to
be
subject
matter
expert
and
we
need
to
be
its
was
quite
opinionated
of
what's
required.
We
need
to
sort
of
talk
to
our
customers
and
understand
their
needs,
and
we
also
need
to
stand
our
ground
on
on
best
practice
and
the
interesting
thing
is
it
kind
of
turns
the
tables
a
bit.
You
know
now.
It's
our
job
to
really
prioritize
based
on
features
that
will
benefit
the
most
of
our
tenants,
as
opposed
to
maybe
necessarily
the
noisiest
one.
A
So
the
solution
prize
is
about
six
components.
The
ones
on
the
left
are
managed
by
the
API
platforms
team.
So
we
ended
up
building
a
developer
portal
which
we
call
stargaze.
We've
got
the
kong
api
runtime
itself
with
which
we've
built
a
whole
number
of
CI
TD
pipelines
around
it,
and
then
we've
also
built
a
CLI
tool
which
we
call
swag
stirrer,
and
this
is
how
our
tenants
deploy
change.
I'll
go
into
a
bit
more
detail
in
that
in
a
little
bit.
But
of
course,
we've
also
got
some
services
provided
by
existing
NAB
teams.
A
I'm
gonna
go
through
about
three
different
use
cases,
onboarding
publishing
and
consumption,
and
between
those
three
use
cases,
we've
got
two
actors:
you
know:
we've
got
the
service
publishers
and
the
service
consumers.
So
in
this
case
it's
you
can
be
in
either
a
consumer
or
a
publisher.
You
need
to
approach
the
API
platform
team
and
get
onboard
with
us.
A
Onboarding
is
not
a
very
exciting
topic,
but
it's
actually
a
really
really
important,
because
for
us
it's
all
about
how
quickly
can
our
service
teams
jump
on
and
start
publishing
api's
and
we
need
to
make
sure
that
they
can
be
operationally
ready.
So
in
this
case
we
assign
them
a
unique
namespace,
and
once
we
have
that
namespace
we
we
use
the
API
platform
to
actually
onboard
them.
We
liaised
with
the
other
NAB
teams
and
we
actually
onboard
them
onto
the
identity
provider.
A
We
created
enterprise
logging
account
so
that
logs
get
shipped
straight
away
and
in
in
that
enterprise
logging
camp
we
actually
use
Splunk.
We
actually
pre
create
a
whole
number
of
dashboards
so
that
pretty
much
they're
kind
of
ready
to
you
know
see
how
their
AP
eyes
are
being
used.
Any
throttle
hits
what
sort
of
transactions
per
seconds
they're
getting.
They
just
hit
the
ground
running.
A
Now,
if
you're,
a
service,
publisher,
you'll
sort
of
go
up
to
the
top
and
then
we'll
actually
create
some
tenancy
infrastructure,
so
the
concept
of
a
tendency
for
us
is
really
just
the
underlying
infrastructure,
so
we
we
actually
create
a
ECS
cluster.
We
stand
up
a
radius
instance
as
well
as
Postgres
instance.
We
use
all
managed
services
in
8
OS
this,
because
we
don't
have
managed
anything.
We
don't
really
have
to
once
that's
in
place,
then
we
actually
start
creating
the
kong
environments
generally
for
production
you'd
only
have
one,
but
for
nonprofit.
A
Now,
if
you
happen
to
only
want
to
consume
api's,
we
kind
of
just
skip
the
tenancy
if
it's
just
infrastructure
part,
and
then
we
we
handover
the
tenancy.
When
we
handover,
we
give
a
really
detailed,
onboarding
email
about
all
the
things
they
have
to
do
to
start
using
it,
such
as
applying
for
the
ad
groups
and
and
so
on.
A
So
in
this
case,
at
the
open,
I
do
you
connect
plugin
and
there's
only
two
parameters
that
you
need
to
set:
we've
actually
pre-configured
the
majority
of
the
settings
for
them
and
only
exposed
the
settings
that
they'll
ever
need
to
change
in
the
course
of
normal
business.
So
it's
pretty
straightforward
and
then,
along
with
the
the
swagger,
we
also
have
the
concept
of
a
service
fall
and
the
service
fall
is
all
about
configuring,
all
the
the
backend
services
for
different
environments.
A
So,
as
you
can
see
here,
we've
got
the
Cistus
and
the
perf
environment
set,
and
we
also
allow
variable
interpolation
so
that
you
can
sort
of
configure
any
changes
so
that
the
whole
idea
of
this
service
fall
is
so
that
with
the
swagger,
the
swagger
remains
static
and
doesn't
change
as
you
deploy
your
api
into
different
environments.
And
you
put
all
those
changes
here
in
the
service
file.
A
So,
as
a
publisher,
you've
created
your
swagger
and
service
fall,
you've
then
put
it
into
what
we
call
a
service
folder
and
then
you
get
onto
the
CLI
tool.
So
it's
a
node.js
based
command
command
line
tool
and
it's
quite
clever
because
it
it
actually
interrogate.
What's
on
the
kong
runtime
checks
the
swagger
and
it
only
deploys
the
difference,
and
this
is
really
important
because
it
means
that
you
jet
you
in
theory.
A
You
only
need
to
test
what
has
changed
I
mentioned
before
deploys
to
the
Gateway
and
publishes
to
the
dev
portal
simultaneously,
and
this
is
an
important
one.
It's
the
only
way
our
tenants
can
interact
with
the
Gateway.
So
it's
really
a
control
point
for
us,
and
we
do
that
because
we
can
do
two
things
now
we
can
abstract
the
gateway
technology,
so
we
may
have
more
gateways
in
the
future
and
we
could
then
provide
exactly
the
same
experience
our
tenants.
A
It's
a
bit
of
an
introduction,
swag
stirrer,
so
there's
about
five
commands:
we've
got
apply,
which
is
what
you'd
use
to
deploy
a
service
folder
to
the
platform
list
will
show
you
what
is
running
in
the
runtime
at
that
point
in
time
you
can
validate
your
swagger
or
you
can
remove
a
service
and
the
last
command
purge.
Is
this
if
you
want
to
completely
wipe
the
Gateway
and
it's
sort
of
helpful
in
a
test
or
dev
environment,
so
I'll
just
show
you
a
quick
example.
A
So
in
this
case
we're
going
to
apply
one
of
the
folders,
so
you've
got
apply
and
then
Kong
and
Kong
is
actually
the
platform
and
I
mentioned
before
we
may
have
more
platforms
in
the
future.
So
you
just
switch
that
out
to
the
alternate
platform
you
point
to
then
your
service
folder
and
then
you
point
to
Kong's
admin,
API
and
then
the
last
one
dev
is
actually
the
environment
that
I
was
talking
about
in
the
service
file.
So
if
you've
got
persist,
tests
and
so
on,
you
would
change
it
and
that's.
A
Those
are
the
parameters
that
would
use
and
I've
just
got
very,
very,
very
boost
there,
so
we
run
it.
What
it
does.
It
just
does
a
check
between
the
two
and
then
at
the
end
in
blue.
We
can
actually
see
what's
been
deployed.
So
in
this
case
we've
got
the
example
service.
We've
got
limiting
advanced
applied
across
the
entire
service,
and
we've
got
two
two
routes
and
one
of
the
routes
has
rate-limiting
advance
and
a
request
size
limiting
there.
A
This
is
an
important
note
that
we
actually
only
provide
read-only
access
to
the
Kong
admin
portal,
for
the
reason
that
we
want
swag,
star,
sorry,
yeah,
sorry
so
I'd
start
to
be
the
only
way
that
you
can
deploy
and
then
what
we
do
is
we
publish
our
API
standards,
and
this
is
this
is
a
small
example
of
some
of
them.
So
we
we
have
sort
of
mandatory
route
fields.
Base
path
has
to
be
in
a
particular
format
and
what
we
can
then
do
is
start
to
program.
A
So
at
this
point,
our
publishers
have
altered
their
swagger
they're,
published
it's
gone
to
the
gateway
and
to
the
dev
portal.
So
this
is
our
dev
portal
stargaze.
It's
it's
been
done
in
react
and
we've
got
a
node.js
back-end
for
it
it's
a
landing
page
at
the
bottom.
You
know
we
just
sort
of
track
how
many
teams
have
been
on
boarded
a
number
of
production.
Api's
they've
been
pushed
out
for
drilling.
A
A
We
actually
have
to
have
separate
database
environments
for
prod
and
non
prod,
and
for
that
reason
we
had
to
create
separate
tendencies
and
you
can
actually
switch
between
them
and
switching
between
them
will
give
you
a
view
of
the
different
clients
and
different
API
is
that
you
have
published
in
those
different
contexts.
You
can
also
be
a
member
of
more
than
one
team,
so
I'm,
a
member
of
the
API
gateways
team.
A
But
if
you
remember
more
teams,
you'll
have
more
options
in
your
drop-down,
so
you
can
switch
between
them
and
as
a
consumer
as
you're
browsing
through
api's,
you
can
actually
see
you
can
actually
switch
environments
as
well.
So
you
can
actually
see
that
different
8,000
different
environments,
which
is
really
handy
because
you
may
have
different
versions:
you've
api's
on
different
environments
as
a
publisher.
We've
also
got
a
bit
more
of
an
admin
view
where
you
get
us
a
list
of
all
your
api
pods
and
the
methods
associated
with
them.
A
So
that
wraps
up
the
publishing
aspect
of
it
and
then
now
we
come
to
consuming
so
as
a
service
consumer
like
a
publisher,
you
still
need
to
apply
for
access.
You
need
to.
You
need
the
permissions
to
be
able
to
create
a
client
and
when
you
create
a
client,
you
can
then
add
scopes
immediately
through
self-service.
You'll
receive
the
client,
ID
and
secret
to
authenticate
against
the
IDP
and
in
parallel
will
send
an
email
to
whoever
owns
those
scopes
that
you
applied
for
and
then
once
they
approve,
then
those
ghosts
will
get
added
immediately.
A
This
is
an
interesting
one.
You
know
we
sell
servants.
Wanna
me
does
have
its
own
challenges:
it's
not
a
silver
bullet,
and
we
found
that
when,
when
we
on-boarded
people
that
they
needed
a
lot
of
help,
while
we
built
it,
it's
obvious
how
it
works
to
us.
It's
not
obvious
to
another
team.
We
we
started
off
doing
a
lot
of
one-on-one
training
with
our
teams.
A
We
actually
had
a
lot
of
teams
like
nothing
in
the
first
two
months,
we
had
30
teams,
approach
us
and
try
to
come
on
board,
and
we
were
actually
doing
one
our
face
to
face
sessions
with
them
each
one
of
them.
They
just
took
a
lot
of
our
time,
especially
when
we're
trying
to
build
this
new
platform
quickly.
A
Our
first
approach
was
to
actually
just
write
a
lot
of
documentation
and
and
interestingly,
even
though
we
had
a
lot
of
detail
documentation,
the
first
kind
of
feedback
we
got
was
there's
too
much
documentation,
there's
too
much
to
read,
so
we
actually
then
moved
to
videos
and
for
us
that
was
actually
the
sweet
spot.
What
we
did
so
we
actually
recorded
some
of
our
training
sessions.
A
It's
really
important
to
have
a
shared
responsibility
model.
You
know
where
we've
changed
from
being
a
centralized
team
where
people
walk
up
and
have
to
ask
us
to
do
things
to
pretty
much
providing
assess
service.
You
know
so
that
responsibilities
change
you
know.
So
in
the
past
we
were
fully
responsible
for
any
API
deployed
on
our
centralized
gateway,
but
now
we're
providing
an
API
platform.
A
So
as
long
as
the
Gateway
is
performant
and
and
functioning
we're
sort
of
doing
our
bit
as
the
API
platform
team,
so
our
tenants
now
have
to
be
in
the
mindset
is
like
well
I'm
responsible
for
the
API
itself.
I
need
to
monitor
it
and
I
need
to
put
alerting
on
it
and
I
need
to
be
checking
logs
and
making
sure
throttles
are
not
hit
and
an
capacity
managing
it.
A
That
just
has
to
be
well
documented
so
that
you're
managing
their
expert
expectations
when
they
come
on
board
and
they're
doing
their
bit
before
they
they
go,
live
and
then
last
one
says
it
could
have
been
really
clear
in
your
value.
Proposition
I
still
get
the
occasional
individual
or
a
couple
of
teams
that
come
up
and
go.
Then
this
is
still
complicated.
Well,
I
can't
I
just
go
on
280
lbs
and
stand
up
an
API
gateway
instance.
A
It's
true,
you
could
it'd
be
really
quick
and
you
get
your
API
exposed,
but
we're
talking
about
more
than
that.
You
know
we're
talking
about
discoverability
and
reuse,
so
I
put
together
a
bit
of
a
slide
around
like
the
value
proposition
that
we
provide
around
this.
You
know,
so
we
do
provide
that
API
discovery,
beliee
and
consumption
ecosystem.
It's
really
quick
to
discover
and
reuse
and
that's
through
the
dev
portal
and
we've
also
integrated
through
the
IDP.
We've
done
all
that
sort
of
plumbing.
So
the
IDP
is
connected
to
Kong
out
of
the
box.
A
We've
implemented
the
governance
and
API
standards
through
Oracle,
swag
star
and
then
we've
we've
also
met
all
our
security
and
regulatory
obligations.
We
actually
have
to
certify
platforms
for
for
confidential
data
and
so
on.
We
have
to
do
penetration
testing.
We
have
to
have
disaster
recovery
plans,
continuity
plans
and
we
have
to
ensure
Logging's
in
place.
Then
you
have
the
whole
suite
of
testing
that
we
have
to
do,
and
then
you
have
the
fact
that
we
provide
this
as
a
SAS.
So
we
provide
monitoring
of
the
platform
itself
and
we
release
new
features.
A
New
plugins,
we
update
Kong
for
you
every
month
and
we
also
provide
a
certification
of
performance.
So
rather
than
asking
us
every
time,
hey,
I've
got
10,
TPS
or
I've
got
100
TPS.
Is
it
going
to
work?
We
just
put
it
on
the
on
the
internet
and
say
we
can
do
X
number
of
TPS
if
you're,
underneath
that
you're
good.
So
you
put
that
in
perspective
compared
to
like
I'm,
going
to
stand
up
my
own
gateway
and
do
this
versus
all
of
that.
A
So
that
brings
us
to
today
so
where
we
were
a
year
ago
was
six
to
eight
weeks
and
now
we're
actually
able
to
onboard
our
teams
in
under
two
days
and
once
we're
on
boarded.
They
can
be
up
and
running
in
well
under
a
day.
So
we're
talking
about
three
days
now
and
the
reality
is
once
you're
on
boarded.
You
can
really
deploy,
as
often
as
you
like
every
minute.
A
We've
also
completely
changed
the
responsibility
model,
and
now
we've
we've
basically
given
autonomy
to
our
service
teams
to
operate
as
quickly
or
slowly
as
they
want
so
before.
I
wrap
up
I
just
want
to
call
out
the
amazing
work
that
our
team
in
Melbourne
have
done.
They've
been
absolutely
smashed
for
the
last
year
trying
to
get
this
out.
So
in
the
first
three
months
we
actually
developed
a
minimal
Viable
Product.
In
about
six
months,
we
managed
to
get
the
majority
of
our
core
features
built
in
the
last
six
months.