►
From YouTube: Building a modern application infrastructure at USAA
Description
For more great content, visit https://solocon.io
SoloCon 2022:
Building a modern application infrastructure at USAA
Speakers:
Jesus Mireles
Technical Architect, USAA
Session Abstract:
USAA provides financial services for millions of military members and their families. Join Jesus Mireles to hear how they are developing and running modern applications to delight their customers and deliver outstanding services. In this talk Jesus will discuss some of the challenges and requirements for USAA’s API Management Platform. You will hear a summary of the journey and see a high level overview of the solution.
Track:
Gloo Edge and API Gateway
A
All
right,
hello,
my
name
is
jesus
mireles
and
I'm
here
to
talk
to
you
about
our
api
management
journey,
I'm
a
technical
architect
at
usaa,
where
I'm
responsible
for
the
api
infrastructure
domain.
Lately,
my
focus
has
been
around
maturing
our
api
management
platform,
which
we'll
talk
about
in
this
presentation.
A
Usaa,
you
know
we're
a
financial
services
provider
that
is
primarily
focused
on
military
members
and
their
families.
Today
we
serve
over
13
million
members
and
have
sold
over
48
million
products.
We
have
over
36
000
employees
and,
if
you're
interested
in
joining
our
team,
you
can
visit
the
link
on
this
slide.
A
A
So
to
kick
things
off,
we
need
to
talk
a
little
bit
about
api
governance
because
it
was
one
of
the
key
drivers
for
our
solution
and
api
governance
is
really
going
to
have
a
different
meaning
from
one
organization
to
another.
So
I
feel
it's
important
just
to
level
set
and
show
you
some
of
the
attributes
that
make
up
our
governance.
A
A
Next,
we
wanted
to
be
able
to
track
api
usage
by
consumer
this.
You
know
these
insights,
you
gain
from
tracking
usage
at
that
level,
is
going
to
be
great
and
you're
going
to
be
able
to
achieve
things
like
chargeback
models,
or
it
teams
can
have
some
insights
on
how
their
apis
perform
at
an
operational
level.
A
You
know
per
consumer
and
you
can
start
making
decisions
on
your
architecture
or
whatever
business
partners
can
then
use
this
data
to
prioritize
work
and
make
smarter
business
decisions
knowing
where
your
apis
are
deployed
and
how
they're
secured
at
any
given
deployment
is
important
to
us.
Usa
operates
in
a
highly
regulated
industry.
So
if
an
auditor
comes
to
us
and
asks
hey,
where
is
your
api
deployed
or
how
is
this
secured
or
who's
calling
your
api?
We
need
to
be
able
to
answer
these
types
of
questions.
A
Another
big
part
of
our
governance
is
defining
interface
standards
and
best
practices
for
developers
to
follow
when
they
create
their
apis.
So
these
things
can
be
things
like
what
http
status
code
to
use
for
certain
interactions
or
naming
conventions
or
other
best
practices
that
come
that
end
up
becoming
standards
such
as
maybe
keeping
personally
identifiable
information,
for
instance,
off
a
url.
You
know
I
asked
you
know.
I
talked
a
little
bit
about
already
how
business
can
our
business
partners
can
use
this
data?
A
This
was
a
group
of
senior
engineers
that
would
meet
once
or
twice
a
week
and
they
would
go
over
any
soap
service
that
was
getting
created
at
that
time
and
that
group
was
basically
you
know
they
would
review
your
contracts.
They
would
name
figure
out
your
naming
conventions.
Are
you
using
the
right
ones?
A
What
security
models
and
you
know,
review
if
there
was
already
another
capability
that
existed,
which
could
be
reused
instead,
so
in
2008
we
started
to
share
our
apis
a
little
bit
more
with
external
consumers
and
mainly
on
our
b2b
channels,
so
we
purchased
licensing
for
an
xml
gateway
that
was
already
you
know.
I
guess
I
would
say
it
was
very
anemic.
A
It
was
just
really
a
reverse
proxy,
with
not
a
whole
lot
of
capabilities,
but
in
2011
we
had
to
upgrade
those
proxies,
because
we
started
really
doing
a
lot
more
advanced
tasks
with
our
b2b
consumers.
Or
you
know,
our
business
processes
were
being
exposed
to
more
more
of
those
external
consumers.
So
we
started
using
our
soap
services,
even
a
lot
more
within
our
enterprise,
so
we
we
ended
up
needing
to
upgrade
those
gateways
again
well
in
2011..
A
So
all
that
was
great
in
this
land
of
soap
and
services.
Back
in
2014,
though,
things
started
to
change
a
little
bit.
I
had
just
taken
over
the
api
infrastructure
domain
and
I
was
starting
to
push
a
lot
more
for
more
restful
services
at
that
you
know
at
that
time,
and
in
that
same
year
we
started
putting
some
of
these
services
on
the
gateways.
A
You
know,
create
a
policy
for
you
and
then
promote
that
policy
to
production.
You
know
all
based
on
your
release
date,
so
a
very
painful
process,
and
in
2015
we
knew
this
was
obviously
not
going
to
work.
You
know,
because
usa
started
seeing
more
single
page
applications
all
of
a
sudden
for
our
website,
and
then
our
mobile
app
was
also
gaining
a
lot
of
popularity,
so
we
started
seeing
an
explosion
of
these
types
of
http
apis
on
these
gateways.
You
know
so
so.
The
first
thing
we
try
to
do
was
we.
A
We
try
to
scale
our
governance.
You
know
by
introducing
a
template
on
our
wikis,
that
developers
can
go
and
document
their
apis
so
that
the
governance
group
had
some
idea
of
what
you
were
bringing
to
the
meetings
before
you
actually
got
to
the
meeting,
and
hopefully
we
can
capture
some
of
the
easier
ones
you
know
and
just
knock
them
out
and
give
them
their
approval
before
they
even
came
to
the
meeting.
We
also
ramped
up
the
meetings
from
once
a
week
to
daily
just
to
try
to
keep
up
with
that
demand.
A
A
A
So
a
year
later
we
created
a
portal
to
kind
of
help
us
store
swagger
files,
then
so
now
developers
were
being
asked
to
generate
these
files
and
catalog
them,
and
the
goal
here
was
to
keep
these
files
accurate,
with
the
code
and
being
able
to
share
with
more
engineers
across
the
organization,
was
a
big
plus
to
having
a
kind
of
a
centralized
catalog,
and
these
also
gave
engineers
a
way
to
upload
their
documentation,
so
that
governance
board
now
had
a
little
something
more
accurate.
You
know
to
review.
A
A
So
some
of
the
challenges
that
we
had
you
know
so
we
saw
a
quick
timeline
just
now-
and
I
mentioned
some
of
these
challenges
already,
but
I
wanted
to
highlight
these.
The
first
major
challenge
was
the
scaling
and
the
maturing
of
our
governance.
We
wanted
to
mature
the
process
of
client
management
and
client
observability,
but
up
until
now
we
only
had
a
catalog
and
no
actual
client
management.
So
if
there
was
any
client
management,
it
was
all
done
manually
and
configured
manually,
so
developer
empowerment.
There
was
virtually
none.
A
You
know
you
had
to
still
go
to
an
ops
team
to
deploy
your
services,
so
we
knew
that
we
needed
more
automation
around
that
and
self-service
tools
where
our
portal
could
push
policy
to
these
gateways.
So
the
maintainability
of
these
gateways
was
a
huge
factor
as
well.
We
were
still
dealing
with
databases
and
and
deployment
models
that
were
just
not
really
friendly
for
scaling.
We
had
to
take
advantage
of
some
of
the
newer
technology
what
we
wanted
to
take
advantage
of
the
newer
technology,
like
maybe
looking
into
running
these
gateways
in
containerizing
containers
as
well.
A
You
know
and
being
able
to
scale
those
that
way
instead
of
scaling
hardware.
So
obviously
we
were,
you
know
there
was
lots
of
challenges
there,
but
those
three
were
probably
the
the
drivers
that
finally
tipped
the
scales
for
us.
So
we
knew
that
something
had
to
change,
so
we
wrote
down
our
requirements
and
I
would
say
that
these
are
probably
the
most
important
functional
requirements
that
that
we
we
have
in
our
list.
A
A
You
know
those
things
that
governance
cares
about
so
having
this
catalog
could
also
serve
as
an
inventory
of
all
our
apis
in
the
enterprise.
So
one
goal
was
to
catalog
all
the
apis,
and
we
do
that
virtually
now
by
having
a
script
that
scans
our
source
code
repositories,
for
you
know,
projects
that
expose
out
http
based
apis,
and
we
ask
those
teams
in
a
friendly
email.
A
You
know
to
catalog
their
apis
if
it's
not
already
cataloged,
and
so
the
next
thing
was
that
we
had
to
have
a
product
that
integrated
with
all
the
current,
with
our
current
analytics
and
traffic
monitoring
platform
we
didn't
want
to
have
engineers
have
to
correlate
data
from
the
api
management
platform
and
with
with
our
existing
platform.
So
you
know
correlating
that
data
and
triaging.
All
that,
like
we
didn't
want,
we
didn't
want
multiple
tools
for
the
job,
so
we
were
not
interested
in
buying
a
platform.
A
You
know
that
came
with
us
with
its
own
analytics
and
and
logging
platform,
because
we
we
wanted
to
use
our
existing
one
operational
integrity.
Of
course
you
know
big
deal.
We
wanted
it
to
be
scalable
under
load.
We
wanted
it
to
be
performant,
so
we
were
looking
for
something
that
can
keep
up
with
our
demand
api
orchestration.
A
A
So
next
we
wanted
to
also
we
already
had
a
security
model
that
I
mentioned
before.
So
that
was
not
something
that
we
could
replace.
Most
products
on
the
market
offer
a
security
solution
and
a
lot
now
actually
do
allow
you
to
integrate
with
external
vendor
products
or
vendor
solutions
for
security,
but
sometimes
these
are
either
out
of
the
box
integrations
and
sometimes
they're.
Not
so
you
know
it's
kind
of
hit
or
miss
there
for
us.
A
We
had
this
as
a
hard
requirement,
so
we
at
the
time
there
was
nothing
that
was
out
of
the
box
that
could
integrate
with
our
current
security
platform,
so
we
we
had
to
basically
do
it
ourselves.
So
that
meant
that
if
you
had
an
oauth
client,
for
instance,
that
you
were
creating
or
anything
like
that,
you
would
have
to
create
that
oauth
client
in
in
the
security
platform.
A
Somehow
so
something
had
to
integrate
that
together,
and
so
our
api
lifecycle
was
something
that
we
looked
at
as
well,
because
we
felt
that
retiring
retiring
apis,
which
really
doesn't
happen
all
that
often
but
versioning
apis
was
also
not
happening
enough
and
because
there
was
a
lot
of
challenges
there.
You
know
you,
we
didn't
have
proper
client
management.
A
A
So
these
were
some
of
the
types
of
capabilities
that
that
we
were
looking
for
and
then.
Lastly,
we
wanted
to
have
an
easy
experience
for
engineers.
Our
goal
was
not
to
require
you
to
have
special
training
or
to
have
to
go
to
you
know,
pages
and
pages
of
documentation
to
use
our
platform.
We
one
our
goal
that
we
set
up
for
was:
let's
make
this
as
easy
and
comprehensible
as
possible.
A
So,
as
I
mentioned
before,
you
know
that
our
first
solution
was
to
build
something
temporary.
While
we
found
a
vendor
solution
that
worked
for
us,
this
became
very
challenging,
though,
because
most
of
the
api
management
products
on
the
market
seem
to
work
very
well
for
sharing
apis
outside
the
organization
to
like
third-party
developers
or
b2b
consumers.
A
But
you
know
most
most
of
these
didn't
work
well
for
internal
api
management,
some
of
the
biggest
challenges
that
we
had
with
that
maybe
were
around
governance.
You
know
the
governance
board
capabilities
were
not
available,
which
comes
to
no
surprise.
I
mean
I
mentioned
earlier.
Api
governance
is
going
to
have
a
different
meaning
to
everyone,
so
you
know
it's
going
to
be
impossible
for
these
vendors
to
meet
everyone's
different
requirements.
A
If
you
will
you
know
so
that
that
was
not
very
surprising,
but
we
still
had
these
requirements,
so
we
had
other
types
of
requirements
as
well,
though
things
like
you
cannot
release
a
gateway
policy
into
production
unless
there
is
a
valid
release,
management
approved
change,
request.
You
know.
So
if
we
wanted
to
have
an
experience
for
for
our
service
governance
board
to
approve
apis,
we
had
to
build
our
own
portal.
That
was
another
thing
right,
so
I
talked
earlier
about
how
governance
board
members
going
to
prove
an
api.
A
A
So
therefore,
you're
gonna
have
to
kind
of
create
your
own
api
or
your
your
own
ui,
but
here's
some
apis
that
you
can
use.
So
if
you
recall,
I
already
mentioned
that
we
had
to
use
our
own
metrics
and
analytics
platform
and
our
existing
security
platform.
So
now
I'm
having
to
integrate
all
these
different
platforms
and
then
build
my
own
ui
on
top
of
that.
So
now
it's
like
okay.
Well,
what
exactly
am
I
paying
for
again?
You
know
I
come.
A
I
came
to
the
conclusion,
basically
that
we'd
be
paying
for
a
very
expensive
proxy,
because
all
that
we
were
really
leveraging
you
know
was
the
proxy
itself
because
on
you
know,
on
top
of
that,
I
had
to
have
this
huge
engineering
team
to
create
this
custom
ui
and
then
integrate
all
these
different
platforms.
My
analytics
platform,
my
security
platform,
my
cms,
perhaps
you
know
for
pipeline
and
then
my
release
management
system.
A
So
you
know
we
go
back
to
the
drawing
board
and
we're
like
okay,
let's
look
at
what
what
it
would
take.
You
know
to
just
replace
our
gateway
set
with
a
different
product
and
here's
what
we
looked
at.
You
know
many
options
in
the
market
and
ultimately,
we
decided
to
go
with
glue.
This
was
the
most
cost
effective
for
us
because
we
already
had
most
of
these
pieces
already
kind
of
done,
but
we
were
kind
of
missing
some
of
the
capabilities
that
glue
has
to
offer.
A
So,
unfortunately,
I'm
unable
to
show
you
a
demo
of
our
portal,
even
though
I
would
have
loved
to,
as
you
know,
I'm
actually
very
proud
of
all
the
work
that
our
team
has
done
with
it.
But
I
can
talk
to
you
about
some
of
our
the
major
capabilities
that
our
portal
has.
So,
first
of
all,
our
assets
are
owned
by
teams,
so
we
didn't
want
to-
or
we
didn't
want
to
have
individuals
owning
assets,
because
many
of
us
change
teams
or
companies-
and
we
didn't
want
to
have
a
complex
transitioning
process
between
these
assets.
A
So
teams
are
built
off
ad
groups
and
we
manage
them
that
way.
So
we
have
a
robust
catalog
that
has
a
snappy
search
engine
behind
it.
We're
able
to
catalog
swagger
files
and
whistle
files,
our
search
engine
can
search
these
artifacts
and
then
we
also
have
the
capability
to
tag
things
so
you're
also
able
to
search
for
tags.
Engineers
have
self-service
tools
to
help
them
deploy
their
apis.
A
We
have
a
pretty
nice
wizard
that
a
lot
that
asks
you.
You
know
to
choose
what
zone
you're
going
to
what
environment
you're
going
to
do
you
want
you
know.
Where
do
you
want
to
deploy
this
to,
and
then
it
has
a
step-by-step
ui
wizard?
I
would
call
it
that
helps
you
create
your
upstreams
and
then
your
policy
creation.
So
some
of
these
policies
are
automatically
added
for
you,
based
on
the
zone
and
the
environment
that
you
choose,
and
then
there
are
some
that
are
configurable.
A
So
all
this
is
integrated
with
our
release
management
system
so
pushes
to
prod
verify.
You
know
before
you
actually
push
it
around
that
there
is
a
valid
change
request
that
is
scheduled
on
that
date
and
time
and
all
that
so
api
consumers
have
an
experience
to
request
access
to
an
api.
You
know
so
things
like
you
know.
You
have
to
provide
your
business
case,
so
I
go
and
search
and
make
I
go
into
the
catalog
I
search
for
an
api.
A
I
find
one
that
I
like
and
then
I
have
to
I
request
access
and
I
provide
a
business
case.
So
if
the
owner
decided
to
allow
anyone
to
consume
it,
though,
then
I'm
auto
approved.
But
if
not,
then
someone
from
that
team
that
owns
that
api
approves
my
request
and
then
my
api
key
gets
approved
to
consume
that
api
and
the
portal
kind
of
orchestrates
sending
that
api
key
to
the
proper.
You
know
glue
instance:
that's
gonna!
That's
gonna
enforce
that
api
key,
so
api
owners
can
also
manage
their
clients.
A
So
if
there's
like
a
bad
actor
or
or
something,
you
know
any
any
reason
that
they
want
to
revoke
access,
they
can
do
that
from
the
portal
then.
Lastly,
we
we
have
an
analytics
and
reports
embedded
in
our
tool
to
view
the
usage
error
rates
and
and
whatnot
so
and
then,
whatever
other
you
know
kinds
of
reports
that
we
have
to
offer.
So
we
also
have
apis
that
you
know
things
like
pipelines.
Can
leverage
for
integrations
or
whatever
internal
employee
tools
we
may
have
that
that
require
our
apis?
A
Maybe
on
your
on-prem,
you
know
in
this
case,
for
us
we
do
have
services
that
are
deployed
to
some
application,
servers
or
mainframes,
and-
and
so
these
apis
can
be,
you
know,
sitting
in
our
data
center
and
and
our
edge
proxy
will
will
full
request
onto
that.
So,
but
you
could
even
have
a
you
know,
container
orchestration
platform,
something
like
kubernetes
or
openshift
most
of
these
platforms.
You
know
they
already
have
a
proxy,
at
least
in
our
case.
We
chose
to
replace
our
default
proxy
with
glue.
A
So
now
our
edge
proxy
is
glue
edge
and
then
our
ingress
proxy
to
our
container
orchestration
platforms
is
also
blue.
We
did
this
because
we
wanted
to
be
able
to
manage
clients
that
call
into
these
platforms.
So
you
know
we
have
multiple
platforms
and
legacy
servers,
and
so
we
felt
that
we
needed
to
be
able
to
track
the
usage
of
clients.
A
You
know
between
these
platforms,
so
we
wanted
a
more
sophisticated
proxy
to
ingress
into
these
container
orchestration
platforms,
to
enforce
things
like
api
key
and
and
use
these
keys
to
basically
create
the
proper.
I
guess
logs
and
analytics
that
we
would
need
so
then
you
know
you
also
might
have,
at
least
in
our
case.
A
We
do
also
have
cloud
public
cloud
apis
running
you
know,
and
you
might
have
edge
route
to
these
as
well,
and
you
know
to
work
into
a
cloud
workload
such
as
maybe
lambda
or
eks
or
kubernetes
or
whatever
you
have
running
in
cloud.
So
the
nice
thing
for
us
is
that
developers
use
a
single
tool
and
in
this
case
our
api
portal
can
handle
lots
of
these
all
these
configurations.
A
A
You
know
the
engineers
will
have
glue
configurations
in
their
projects
that
manage
that
blue
ingress
proxy
and
while
the
api
portal
mainly
manages
the
api
keys
for
that
for
that
cluster,
and
so
all
this
you
know
it's
all
available
via
self-service
tools
and
some
of
the
automation
that
have
made
our
platform
a
little
bit
better
through
pipelines
or
whatnot.
And
so
this
is
a
very
high
level,
but
I
hope
you
get
the
idea
of
what
we
were
trying
to
improve
or
how
we
improved
our.