►
Description
ParkMobile is the leading provider of parking solutions in the US with a mission to power smart mobility for every driver and vehicle, everywhere. Located in 7 cities across the country, ParkMobile helps their 16M+ customers park smarter every year.
Join the discussion with the ParkMobile team on how they are building for scale by going cloud-native with Kubernetes, Gloo, Service Mesh, GitOps and more.
This session will cover:
* Technical challenges and needs to address ParkMobile’s growth over the last decade
* The evaluation criteria, process and results leading to new platform technology
* Lessons learned (surprises too!), how they adjusted and what’s next
Learn more:
https://www.parkmobile.io
https://www.solo.io/products/gloo
https://slack.solo.io #Gloo #Gloo-Enterprise
A
Good
morning,
everyone
thanks
all
for
joining
today's
webinar.
My
name
is
Betty
jannat
VP
marketing
over
here
at
solo,
do
and
today
we're
very
lucky
to
have
the
team
from
Park
Mobile
here
to
talk
about
their
journey
in
migrating
to
kubernetes
cloud
and
glue.
These
and
user
stories
are
some
of
the
best
because
they
are
practitioners,
like
yourselves
organizations
that
are
adopting
technology
and
may
be
and
may
have
gone
through
a
lot
of
the
same
things
that
you're
looking
to
embark
on.
So
this
is
this
is
a
treat
to
have
the
whole
team
here.
A
Tell
the
story,
a
couple
of
housekeeping
items.
This
session
is
going
to
be
recorded,
and
so
it'll
be
available
for
replay
should
have
that
up
by
the
end
of
the
week.
So
you
can
share
it
with
your
colleagues.
We
will
be
taking
Q&A,
so
please
go
ahead
and
type
in
questions
into
the
Q&A
or
the
chat
window,
as
the
speakers
are
presenting.
What
we
will
do
is
address
all
the
questions
at
the
very
end,
Matt.
If
you
could
advance
the
slide,
please.
B
A
All
right,
so
this
is
everyone
you
see
here.
I
just
introduced
myself,
I'll
be
here
to
moderate
and
there's
any
technical
things
that
come
up
sound
what-have-you,
please
make
sure
to
tap
in
that
check.
Put
that
in
the
chat
and
I'll
get
that
handled
with
our
presenters.
Today.
Your
speakers
are
Matt
ball
CTO
of
park
mobile.
We
have
and
then
in
the
room
there
with
the
lovely
background
and
all
the
fun
fun
coolest
collection
of
swag
there.
A
All
of
our
friends
we've
got
Chris
Sullivan
who's,
the
director
of
software
and
reliability,
engineering,
Rafael
Ramirez
leads
sre
and
Anthony
Malaga
senior
SRE,
so
Matt's
gonna
kick
it
off
with
some
background
on
Park
mobile
as
a
company.
What
they're
doing
and
then
the
team
in
the
room.
There's
gonna
talk
in
great
detail
about
how
they're
working
with
the
various
components
of
technology
and
ready
for
all
of
your
questions
now
see
you
Matt
Betty.
You
can
hear
me
well.
I
can
hear
your
great
good.
B
What's
going
on
in
our
business
and
the
moral
of
the
story
and
I
think
you'll
see
towards
the
end,
is
we
went
to
solve
some
these
technical
challenges?
Finding
the
right
partner
and
the
right
solutions
to
help
us
solve
those
challenges
is
really
at
the
end
of
the
day.
Part
of
our
you
know
our
recipe
for
success,
so
thank
you
for
having
us
and
I
also
just
want
to
quickly
thank
my
team
for
getting
us
to
the
point
where
we
can
confidently
have
this
discussion
and
celebrate
some
of
our
successes.
So
thank
you.
B
B
We
strongly
believe
we
can
really
eliminate
friction
and
what
the
way
in
which
the
world
works
today
and
we
can
make
it
much
more
convenient
for
not
just
our
consumers
who
are
attempting
to
park,
but
the
clients
and
the
operators
who
provide
parking
inventory
to
consumers.
So
let
me
highlight
just
a
little
bit
about
the
business.
We
have
the
largest
network,
industry-leading
capabilities
when
it
comes
to
a
number
of
products
and
services.
We
have
reference
here
to
where
all
of
our
products
and
services
are
deployed
across
the
United
States.
B
Some
of
the
things
that
we
do
I'd
like
to
highlight
that
might
resonate
with
you
guys
when
we
talk
about
parking
mobility.
First
of
all,
you
know
think
about
driving
up
to
the
curb
and
parking
on
street
or
pulling
into
a
garage
whether
the
garage
has
a
gate
or
no
gate
and
the
historic
way
of
having
to
pay.
For
your
time
parking.
There
has
been
done
by
kiosks
or
meters
until
Park
Mobile
introduced
the
way
to
really
deal
with
that
through
mobile
payments.
B
We
make
it
a
lot
easier
for
consumer
to
not
only
pay
for
parking
through
any
of
the
their
desired
payment
methods,
but
we
also
allow
consumers
to
extend
their
parking
remotely
without
having
to
return
to
those
physical
meters
and
that's
really
how
we
got
our
start.
The
other
piece
I
mention
is:
we've
really
seen
us
transition
in
terms
of
products
and
services
from
on-demand
parking
into
the
business
of
reservation
parking.
B
So
there's
two
good
use
cases,
perhaps
you're
driving
down
town
you're
a
little
bit
later
than
normal,
but
your
favorite
lot
closest
to
your
work
is
where
you
would
like
to
park.
You
can
reserve
a
spot
in
that
lot
with
Park
Mobile
and
we'll
make
sure
that
that
spot
is
held
for
you
upon
arrival.
The
other
good
use
case
for
reservations
is
event
parking.
We
do
and
I'll
show
some
stats
on
this.
B
We
do
a
lot
of
work
with
event
venues,
whether
you're
talking
about
Taylor,
Swift
or
Elton
John
concerts,
two
major
sports
teams,
both
at
a
professional
and
an
amateur
level,
and
we'll
highlight
a
few
of
those
in
the
presentation.
So
that's
a
little
bit
about
Park,
Mobile
I
want
to
hit
you
guys
up
with
some
of
the
stats.
That,
quite
frankly,
were
you
know
we're
extremely
proud
of,
but
it's
these
stats
that
start
to
lead
into
the
story
about
the
challenges
you
can
imagine.
B
So
what
that
means
is
we're
actually
partnering
we're
doing
business
with
the
cities
and
the
municipalities
for
which
we
have
41
of
the
top
100
cities
or
we're
partnering
up
with
airports
or
universities
or
event
venues,
and
it's
those
clients
on
our
b2b
side
that
deploy
our
b2c
capabilities.
Our
mobile
app
and
our
web
products
to
allow
people
to
purchase
parking,
on-demand
or
through
reservations,
ranked
number
three
in
the
navigation
category
behind
ways
in
Google
Maps,
as
certainly
something
we're
proud
of,
and
that's
very,
very
hard
to
do.
B
So
you
start
to
see
these
scale
numbers
and
you
start
to
see
the
tax
that
this
probably
has
on
an
engineering
organization
to
keep
our
infrastructures
and
our
applications
in
tip-top
shape
that
we
can
grow
along
these
exponential
curved
lines.
A
lot
of
people
understand
Park
Mobile
for
the
consumer
app
and
that's
natural.
We
would
expect
that
it's,
you
know
very
centric
to
our
brand,
but
Park
Mobile
is
actually
a
platform
company
and
so
I'll
introduce.
You
know
why
that
is.
B
You
know
we
do
have
a
best-in-class
industry-leading
product
on
both
mobile
and
web,
for
which
our
consumers
integrate
with
Park
Mobile
I/o,
but
we
also
have
p.m.
360,
which
is
our
platform,
that
our
clients
use,
whether
it's
an
operator
or
a
city.
I
talked
about
our
business
model.
We
actually
partner,
whether
it's
airports,
universities
or
the
cities
themselves,
they're,
actually
using
PM
360
as
a
platform
to
have
effect
on
either
rates
policies
or
to
see
their
reporting
weather
analytics
or
financials
around.
B
What
is
going
on
in
the
consumer
experience
and
then
given
the
fact
that
our
ecosystem
is,
is
tremendous
I'm
going
to
talk
about
that
in
a
second,
we
have
a
developer
portal
which
gives
our
partners
access
to
our
API
so
that
they
can
interact
with
us
and
we
can
continue
to
extend
our
network
reach.
So
that's
pork.
Mobile
is
a
platform
in
some
statistics.
B
Let
me
transition
a
little
bit
into
the
challenge
that
comes
along
with
that
and
I
just
kind
of
mentioned:
the
developer
portal.
We
actually
are
integrated
to
over
a
hundred
different
partners
in
this
ecosystem.
It's
it
is
actually
very
fragmented
and
there's
not
a
one-size-fits-all
or
there's,
not
one
partner
that
specializes
in
the
whole
thing.
You
know
you
have
different
pockets,
whether
it's
those
enforcing
parking
on
the
streets
or
whether
it's
those
that
are
in
control
of
who
gets
in
and
out
of
garages.
B
You've
got
Evie
charging
and
meters
we're
connected
with
over
13
different
payment
processors
in
the
United
States.
There's
folks
that
tell
us
predictively
whether
or
not
there's
parking
available
in
certain
parts
of
town.
We
call
availability
and
we're
integrated
with
a
lot
of
other
folks
just
to
bring
in
data
so
there's
a
platform.
B
We
can
be
the
one
place
to
show
our
clients,
regardless
of
how
many
channels
you
actually
enable
in
a
garage
or
a
city,
everything
you
need
to
know
about
your
performance
across
those
channels
and
as
it
is
the
CTO
and
as
an
engineering
organization.
Obviously,
restful
services
across
100
plus
integrations
that
continue
to
grow
exponentially.
B
We're
adding
more
and
more
every
single
day
really
requires
us
to
position
ourselves
with
an
engineering
vision
that
will
be
secure,
safe,
reliable,
but
also
scale
with
the
growth
of
this
business,
and
so,
when
I
got
here
about
18
months
ago,
we'll
start
to
bring
the
story
back
to
our
topic
today,
Chris
that
team,
my
leadership
organization,
we
sat
down
and
we
said
given
the
context
of
Park
mobile,
where
we're
going
the
success
we're
having
as
an
organization.
What
do
we
want
to
look
like
in
our
future
state?
B
And
this
isn't
this
isn't
necessarily
anything
new?
It's
about
decomposing
monolithic
applications
into
more
fine-grained
services
gives
us
speed
the
ability
to
isolate
certain
things,
invest
more
in
scale
on
certain
services.
We
want
to
be
channel
agnostic,
we're
an
API
first
company
and
we
have
a
lot
of
folks
as
I
showed
you
coming
in
through
API.
So
how
do
we
do
that
in
a
quick,
rapid
and
secure
way?
We
also
have
to
enable
our
own
mobile
and
third-party
mobile
and
web
channels,
so
we've
we've
decided,
you
know
in
a
multi
datacenter
situation.
B
B
Us
to
take
advantage
of
scale
elasticity
things
of
that
nature.
How
do
we
start
to
break
down
those
monoliths
into
somewhat
micro
services,
but
in
some
cases,
larger
domains,
but
certainly
smaller
in
nature?
How
do
we
take
advantage
of
design
principles
that
really
take
into
account
what
things
you
need
to
concern
yourselves
with
in
the
cloud
as
well
as
take
advantage
of
things
like
automatic
elasticity
and
given
the
the
performance
of
this
business,
we
have
to
be
able
to
scale.
B
We
have
to
provide
somebody
instant
response,
and
we
have
to
be
prepared
to
do
that,
even
though
we're
acquiring
new
integrations
and
new
transactions
every
day.
So,
given
those
challenges
we
decide
as
an
organization,
we
need
to
move
forward.
We
need
to
find
strategic
partners
who
can
work
with
us
to
solve
some
of
these
problems
and
we
really
started
on
the
topic
of
an
API
gateway.
That's
really
where
it
started.
B
It
started
in
the
category
of
how
do
we
bring
together
these
this
different
data
center
architecture,
behind
a
north-south
gateway,
secure
our
api's
and
set
us
up
for
success,
long
term
and
as
our
research
into
our
options
partners?
We
started
to
really
extend
our
thought
process
about
that's
where
we
want
to
start,
but
it's
about
enabling
developers
to
be
autonomous.
B
It's
about
better
security,
it's
about
long-term,
east-west
traffic
management,
as
we
get
into
the
concepts
of
service
mesh,
and
that's
really
how
we
started
to
evolve
into
the
problem
and
I'm
going
to
bring
it
up
here
in
a
second
I'll.
Just
touch
on
this
last
point
and
I'm
going
to
let
the
team
really
talk
about
the
technical
challenges
with
our
vision
and
what
they've
been
chartered
to
solve.
The
one
thing
I
did
ask-
and
this
is
based
on
my
experience,
I
said:
look.
This
is
par
with
people
who
are
excellent
in
what
they
do.
B
I
wanted
to
make
sure
that
we
could
then
focus
on
what
we
do
well,
which
is
developing
our
products
and
services
in
this
mobility
ecosystem,
and
we
sort
of
set
out
with
five
sort
of
key
values
and
I.
Think
and
I'm
happy
to
be
here
today.
Talking
about
how
these
five
values
math
to
our
partnership
with
Seoul
Ohio
I,
wanted
something
that
is
very,
very
flexible.
That
can
evolve
with
our
architecture
and
I
know
that
becomes
common
sense.
B
But
the
truth
is
everybody
has
a
starting
point
and
everybody
has
the
North
Star
in
terms
of
their
ending
spot.
The
reality
is,
we
spend
most
of
our
career
in
tenure,
getting
from
point
A
to
point
B.
So
what
we
needed
was
an
architecture
that
could
help
us
along
that
journey,
as
opposed
to
only
really
satisfy
our
requirements
at
the
end
of
the
road
and
there's
a
big
difference
there.
So
we
wanted
flexibility
to
evolve
and
work
with
the
things
that
we
have.
We
wanted
something
modern
in
terms
of
both
innovative
and
proven.
B
We
wanted
a
company,
that's
pushing
boundaries
but
built
on
top
of
things
that
are
proven
for
which
there's
a
community
that
surrounds
just
like
ongoing.
We
wanted
something
that
could
scale
with
our
growth,
you've
seen
our
statistics
and
we
wanted
something
from
a
value
perspective
that
didn't
require
us
to
outlay
a
lot
of
cash
up
front
and
could
really
start
to
show
its
benefits
ahead
of
necessarily
the
expense
and
the
partnership.
Piece
is
critical.
B
I
want
to
be
able
to
reach
out
of
what
my
engineers
to
be
able
to
reach
out
to
somebody
and
be
able
to
have
a
conversation
about
a
road
block
almost
immediately
and
and
help
us
get
to
where
we
want
to
go,
and
we
found
those
things
in
partnering
with
Seoul
Ohio,
and
so
that
was
some
of
the
business
tenants
that
we
focused
on
in
Chris.
Why
don't
you
and
the
team
man
think
you
can
grab
the
slide
share?
B
D
There
we
go
so
alright,
so
it's
a
match
point.
So
we
did
come
across
some
challenges
and
believe
we
were
talked
about
was
touching
upon
this
early
on.
We
did
experience
some
really
really
fast
growth
in
2019
and
what
I
wanted
to
do
from
an
engineering
perspective
is
essentially
not
slow,
not
only
the
SRE
team
down,
but
the
rest
of
the
development
teams
and
really
empower
them.
So
the-
and
this
is
touching
on
bullet
one.
D
We
are
firm
believers
of
DevOps
as
more
of
a
concept
and
engineering
practice
and
not
a
team
solution.
So
we
like
the
idea
of
you,
build
it
you
own
it
you
own
it
from
soup
to
nuts
and
when
you
get
it
from
your
project
conception,
you
take
it
all
the
way
to
prod
and
it's
all
through
a
push
of
a
button
through
our
kind
of
CI
CT
process,
so
big
believers
and
empowering
the
teams
and
that's
what
kind
of
allowed
us
to
essentially
move
quick
move
fast
and
where
we
saw
glue
come
in.
D
So
we
all
kind
of
move
in
concert
together,
so
SRE
team,
coupled
with
the
dev
teams
and
we're
constantly
pushing
forward
so
there
there
is
no
bottleneck.
So
we
do
like
the
whole
concept
of
empowering.
Does
you
know
that
you
own
it
it's
a
fantastic
model
if
and
that's
kind
of
the
vision
I
had
for
the
team
and
here
in
engineering
I
just
wanted
the
guys
to
push
forward
and
just
not
slow
us
down.
So
so
that's
the
big
one
on
bullet
one.
D
When
we
moved
to
cost
drivers
and
talking
to
Matt
about,
we
did
survey
the
landscape,
and
you
know
there
are
players
out
there
that
we're
all
very
familiar
with,
but
the
fact
that
glue
was
essentially
uncoming
and
they
were
definitely
willing
to
partner
up
with
us
and
actually
just
work
with
us
through
some
of
the
challenges
that
we
kind
of
encountered
in
2019
was
something
that
really
really
attracted
us
kind
of
just
make.
That
decision
just
go
with
glue
and
the
solo
team.
D
So
we
like
that
from
a
perspective
from
kind
of
you
know,
I
got
the
cost
perspective
in
amount
of
volume
that
we
can
essentially
drive
with
our
user
base,
like
Matt,
was
saying,
I
think
we're
up
to
2.4
or
2
million
users
a
month.
So
we
needed
something
that
kind
of
would
scale
with
us,
but
you
know
would
have
heard
us
in
the
pockets
essentially
so
on
top
of.
E
That
is
the
not
just
talking
dollars,
but
we're
a
time
that
it
takes
to
pick
up
something
new
and
and
run
with
it
because
time
time
also
equals
money.
So,
instead
of
wasting
our
time
trying
to
figure
out
the
solution
and
how
we
plan
on
mapping
out
the
new
api's
of
what
past
were
routes,
they
go
to
glue.
Pretty
much
came
in
and
did
a
lot
did
a
lot
of
the
heavy
lifting
for
us
and
going
back
to
0.1
everything
being
configurable
within
their
pipelines
was
just
a
great,
very
added
benefit
with
partnering.
D
Up
the
glue
right
so
just
move
on
so
so
we
were
established
from
like
Matt
was
saying
so
we're
moving
on
on
our
API
gateway
strategy,
seeing
essentially
what
our
landscape
here
internally
to
look
like
and
actually
kind
of,
just
making
sense
of
essentially
just
north-south
traffic.
You
know
traffic
coming
in
to
the
network
and
then
traffic
within
the
network.
D
We
were
just
on
AWS,
so
moving
the
team's
along
and
just
making
everybody
aware
like
hey,
you
know
what
we
really
want
to
push
towards
that
cloud
native
vision
getting
glue
in
place
to
handle
not
only
API
traffic
but
essentially
kind
of
just
front
some
of
the
issues
we
do
have
because
we
do
have
monoliths.
So
we
we
are
still
dealing
with
decomposing
our
existing
monoliths
as
well
as
marrying
up
our
new
micro-services
architectures.
D
So
we
needed
something
that
would
play
nice
in
both
worlds
and
and
glue
absolutely
did
that
and
it's
fantastic,
it's
almost
seamless
and
moving
towards
that
whole
new
vision.
I
mean
we
are
trying
to
be
as
kubernetes
native
as
possible.
So
we
also
need
things
to
play
nice
in
the
cluster
and
glue.
Definitely
does
that,
so
we
did
that.
That's
checking
off
all
our
marks
or
little
checkboxes
on,
like
hey
who's,
just
hitting
everything,
and
it
also
marries
up
the
old
world.
So
we
were
definitely
happy
on
that
front
security
wise.
D
You
know
we
got
all
the
access
controls
that
we're
looking
for
essentially
that's
kind
of
big
on
our
side,
especially
arbok,
and
anything
like
that.
We
do
want
to
empower
our
debts,
but
we
we
want
to
be
invasive.
When
we
tackle
security
we
don't
want
to
kind
of
just
strong-armed
security,
so
we
kind
of
want
to
make
it
seamless.
So
that
was
also
nice
coming
out
of
glue
and
it
gets
empowered
us
I
guess
we'll
all
be
yeah.
Let.
E
It
let
us
be
good
at
what
we
were
actually
good
at
and
not
have
to
worry
about.
It
did
for
the
developers
to
shoot
themselves
in
the
flight,
so
right,
there's
a
lot
of
safeguards
in
place
where
we
can
lock
them,
lock
them
into
certain
namespaces
and
in
that
namespace
they
they're
managing
their
own
routes,
their
own
endpoints,
as
along
with
their
applications
right.
D
So,
let's
fantastic
again
going
back
to
the
you,
build
it
you
own
it
model
and
hold
through
DevOps,
that's
an
engineering
practice
and
not
as
a
just
a
one
team
practice,
so
very
nice
and
and
on
point
six.
We
do
have
varying
stacks
it'd,
be
nice
to
say
that
you
know
what
we've
kind
of
just
settled
on
go
and
that's
that's!
That's
our
language
where
we're
using
things
like
dynamo
or
or
things
like
that.
D
But
the
truth
of
the
matter
is
it's
we're
very
polyglot,
we'll
environment,
so
we
did
have
to
just
kind
of
just
also
look
into
that
and
make
sure
that
we
can
actually
hook
in
nicely
to
everything
that
we're
doing
for
for
the
other
teams
that
are
so
on
different
tech
stacks.
So
this
slide
kind
of
shows
us
where
we
are,
and
also
a
little
bit
on,
where
we're
kind
of
moving
towards.
So
you
can
see
from
left
to
right,
mobile
native
call
and
Swift's
moving
on
to
the
website
its
react.
Node.
D
We
think
up
next
on
the
API
front,
its
opening
API,
spec,
Yambol,
JavaScript
and
primarily
our
back-end
services.
We
do
have
primarily
Ruby
and
dotnet.
We
are
shifting
a
little
more
towards
the
building
of
micro
services.
Around
go,
we
are
heavy
fanatics
will
go
as
maybe
you
can
see
on
our
desk.
I
love
it.
D
Personally
speaking,
it
takes
me
back
to
my
college
days
when
I
first
discovered,
C
and
I
kind
of
just
fell
in
love,
so
it
feels
like
I'm
back
in
college,
just
coding
and
C,
but
we
are
using
things
like
dotnet
core,
which
is
fantastic,
which
is
just
as
fast
and
just
as
powerful.
But
again
we
do
have
a
varying
stack.
So
we
had
we
needed
something
to
play
nice
across
this
field
across
everything
that
we
currently
have
and
again,
like
I,
said
glue.
D
Just
just
it
just
checked
off
those
those
those
check
boxes
behind
the
scenes
that
you
can
see
again,
it's
it's
not
all,
but
everything
cloud
native.
We
do
have
kubernetes
we're
running
lambdas.
We
got
EC
twos,
but
again
it's
marrying
that
old
world
within
you
and
allowing
us
to
kind
of
just
seamlessly
transition
from
the
old
to
the
new
with
without
impacting
the
business
at
the
other
day.
D
So
a
lot
of
this
stuff
just
gets
off
you
skater
from
the
business
and
it's
kind
of
just
business
as
usual,
so
it's
fantastic
from
an
API
perspective
from
a
platform
perspective
glue
is
it's
just.
This
is
hitting
almost
marks
so
so
that
is
our
stack
in
a
nutshell.
So
I'm
just
gonna,
kick
it
off
to
Rafael
and
Anthony
to
talk
more
a
little
bit
about
implementations
and
how
we've
done
it
a
little
more
in
the
weeds,
so
speak
so
well.
Alright,.
E
So
the
search
of
an
API
gateway
for
for
all
our
API
was
a
very
huge
challenge
for
us,
mainly
because
we
were
we
once
we
got
everything
up
and
running
in
kubernetes
everything
was
being
deployed.
The
team
is
leveled
up
and
learned
the.
How
do
how
to
use
a
kubernetes
cluster
then
then
comes
in
where
what
the
existing
eight-pack
solution
that
already
exists
so
meaning.
E
Last
year,
we
we
mainly
saw
EK
as
a
KS
gke
started,
taking
taking
up
the
market
and
all
the
current
API
solutions
that
were
available
were
mainly
more
focused
towards
older
solutions,
so
they
were
all
very
outdated
or
they
were
trying
to
work
with
kubernetes
and
they
weren't
working
very
well.
Some
of
them.
C
There
something
yeah
like
so
a
couple
of
the
comparators
that
we
looked
at
were
not
didn't,
allow
us
to
install
anything
inside
our
own
network
or
in
our
infrastructure.
So
we
would
have
to
install
their
proprietary
programs
inside
our
cluster
to
the
able
to
reach
out
and
communicate
with
these
external
api's,
which
was
kind
of
problematic,
because,
as
we
were
talking
about
earlier
leak,
there's
they
had
a
lot
of
built
in
packages
that
had
some
outdated.
You
know
versions
of
nginx
that
we
didn't
feel
comfortable
running
in
our
environment.
C
E
That
that's
that
stems
back
from
these
other
solutions,
trying
to
make
pretty
much
fit
a
square
inside
of
a
circle
where
and
we
kind
of
turn
into
a
black
box,
and
it
it
just,
was
and
wasn't
feasible
with
what
we
were
looking
for.
And
on
top
of
that,
since
these
solutions
were
already
had
name
recognition,
getting
in
contact
with
them
and
speaking
to
our
our
current
issues
with
the
product
trying
to
make
it
work
kind
of
was
falling
on
deaf
deaf
ears.
So
we
kind
of
we.
E
B
E
Right
so
it
felt
it
felt
more
like
like
creating
a
hack
around
a
system
that
should
just
be
just
work
seamlessly,
with
our
current
current
back
and
and
obviously
when,
when
you
have
these
types
of
types
of
types
of
issues,
you
kind
of
big
silo
your
silo
yourself
from
the
rest
of
the
team.
So
not
only
now,
you
have
to
have
a
dedicated
team
managing
these
other
solutions
which,
at
the
end
of
the
day,
really
nobody
wants.
E
C
C
Then
I
kind
of
we
can
segue
there
until,
like
the
security
issue,
so
being
that
glue
runs
inside
kubernetes,
we're
able
to
use
some
of
the
existing
hard
back
that
we
already
set
up
with
developers
deploying
their
applications
inside
the
cluster
already
so
glue
allowed
us
to
restrict
developers
to
certain
namespaces.
They
can
add
parts
to
the
API
without
having
to
have
us
delegate
permissions
out
in
like
some
external
products,
so
like
not
giving
them
access
to
like
all
their
dashboards
and
stuff
like
that
yeah.
This
solution
allowed
us
to
use
our
existing
permission
structure.
E
So
reasons
why
we
chose
glue
here
at
BARC
moveable
pretty
much,
it
was
easy
and
what
I
mean
by
that
is.
As
most
of
you
know,
kubernetes
is
not
easy,
but
one
of
the
things
is
one
of
the
things
that
glue
does
very
well.
Is
it
was
built
literally
on
top
of
the
kubernetes
api,
so
once
you've
already
once
you're
actually
gone
to
this
step
and
trying
to
implement,
implement,
glue,
you've
already
done
the
hard
work
on
figuring
out,
kubernetes
already
and
then
glued
acts
like
an
extension
of
kubernetes.
E
It's
like
a
it's
a
it's
just
everything's
a
CRD.
Everything
is
its
native
name
to
kubernetes,
which
is
which
makes
it
so
easy
to
to
manage
and
actually
delegate
the
management
of
of
these
endpoints
to
the
development
teams,
because
we
grant
them
are
back
rights
to
just
their
namespace
with
it
only
where
they
should
have
access
to.
So
they
won't
stop
on
anybody
else's
production
workloads
or
any
of
that
just.
C
So,
just
touching
back
on
the
easy
part
I
mean
Lou
came
with
a
really
nice
command
line
that
allowed
us
to
basically
have
an
API
gateway
up
within
a
few
hours
of
discovery,
product
which
is
amazing
so
and
then
like
as
Rex
I
was
saying.
You
know,
we've
already
had
people
going
to
the
learning
curve
of
learning
how
kubernetes
works
once
you
know
how
kubernetes
works
pretty
much
know
how
glue
works.
It's
Louis's,
building.
On
top
of
that,
some
of
the
other
solutions
we
worked
with
was
alert
even
higher
learning
curve.
C
E
That
those
were
big,
big
reasons
why
we
ended
up
going
with
glue
and
just
the
the
slack
room
that
was
very
helpful.
The
community
is
very
helpful
when
any
type
of
situation
or
solution
that
we
might
need
or
want
they're
there
they're
engineers
react
almost
immediately.
So
there's
that-
and
it's
just
been
great
overall
experiences.
We
first
contacted
so.
C
One
of
the
other
benefits
we
really
liked
out
of
glue
is
that
it's
actually
installed
inside
of
our
kubernetes
cluster,
which
is
on
our
internal
network.
So
one
of
their
main
points
is
that
you
can
use
glue
to
mesh
together
many
different
backends,
so
we
do
have
apps
running
in
kubernetes.
That
glue
basically
connects
to
like
seamlessly,
but
we
also
have
monolithic
infrastructure
as
well
on
still
some
on-premise
data
centers,
but
since
glue
actually
runs
inside
of
our
network,
we
could
actually
set
up
streams
to
those
monolithic
servers.
C
You
know
through
eight
I
guess,
is
Direct
Connect
without
having
to
go
through
another
route.
So
we
is
from
a
security
standpoint.
We
have
all
of
our
network
going
through
our
internal
links.
We
don't
have
to
worry
about
any
risks
from
exposing
external
endpoints.
We
can
keep
everything
inside
and
we
just
really
helps
with
that,
because
it's
actually
on
the
network
that
can
talk
to
all
these
endpoints
right.
E
We
will
just
create
a
new,
a
new,
a
new
route
that,
instead
of
that
pretty
much
Forks
off
of
the
monolith
and
just
goes
to
the
new
micro
servers
that
we
stood
up,
not
not
having
to
touch
any
like
the
monolith
of
the
redeploy
anything
new
we
just
help
glue
a
instead
of
going
to
for
this
particular
API
go
here
instead,
and
it's
just
as
easy
as
that.
Preserving.
C
D
I
want
to
touch
on
the
last
point
on
the
slide
before
we
wanted
sifri
source
code.
So
just
so
everybody
on
on
the
channel
monsoon
can
understand,
but
we
are
heavy
on
the
coding
aspect
of
the
infrastructure.
So
the
majority,
if
not
all
the
interest,
is
encode
which
helps
us
in
terms
of
speed
and
deployment
and
as
well
as
embedding
that
infrastructure
code
in
pipelines,
so
not
only
our
dev
teams
on
pipelines.
So
is
this
team
right
here,
the
SRE
team,
putting
things
in
code
and
easily
deploying
out
and
running
tests
and
I?
D
Think
in
the
text
slide
that
you
all
just
saw
there
is
tear
form,
so
we
are
on
terraform
and
this
kind
of
helps
it
really
nice
to
just
pave
the
infrastructure
as
we
go
and
hook
into
the
glue
CTL
and
do
both
things
of
that
nature
to
easily
pave
the
different
environments
that
we
have
going
on.
We
are
big
proponents
of
the
whole
cattle
or
actually
it's
not
pets,
but
cattle
yeah.
D
Don't
care
and
the
fact
over
a
little
more
containerize
nowadays
just
helps
us
really
not
care
about
our
servers.
I
love
that
so
and
that's
kind
of
a
model
that
we're
moving
towards
that
it's
a
whole
cloud
activity
that
we're
kind
of
just
pushing
along
and
moving
towards,
and
with
things
like
this,
it's
like
on
this
slide.
You
see
the
get-ups,
so
just
better
get
UPS
running
things
forget
having
teams
be
empowered
to
kind
of
deploy
out
their
API
endpoints
as
needed.
No
intervention
from
the
SRE
team
is
just
go
right.
E
Because
the
way
that
glue
works
is
each
namespace
has
has
their
own
route
tables
and
we
pretty
much
the
way
glue
works
is
everything
is
a
CRD
it's
just
as
long
as
glue
is
able
to
get
into
your
namespace
and
look
at
look
at
this
route
table
it'll
bring
it
in
merge
it
in
all
from
one
and
centralize
the
whole.
The
whole
configuration
right
like
most
other
solutions.
E
What
they
do
is
does
one
configuration
file
and
only
you
can't
allow
the
whole
company
access
to
this
file,
because
you're
gonna
break
something
and
in
there
there's
just
no
no
way
around
that,
so
every
everyone
being
completely
separated
and
then
glue
having
web
hooks
whenever.
So
whenever
there
is
a
change
for
a
route
telling
developers
hey,
they
did
there's
there's
syntax
errors
here.
C
Yeah,
since
the
glue
configuration
files
are
just
additional
yeah
Mille,
that's
the
same
as
your
kubernetes
deployment
files.
It's
just
another
part
of
that
configuration.
You
don't
have
to
learn.
You
have
to
do
anything
in
XML
or
JSON.
It's
just
the
same
files
different
api
kubernetes,
but
it
all
looks
the
same
easier
to
work
with
yeah.
E
C
E
D
E
C
I
guess
one
of
the
biggest
things
now
that
we
are
trying
to
move
all
of
our
API
is
behind
glue.
There's
a
lot
of
traffic
I
mean,
as
Matt
mentioned
earlier,
at
the
17
plus
min
users
and
they're
all
hitting
these
same
api's.
We
needed
to
have
an
api
gateway
that
would
be
able
to
handle
that
traffic
without
adding
an
ID.
So
I
stuff
in
the
backend
blue
is
running
on
void
proxies.
They
are
just
fast.
You
know,
we
can't
really
say
it's.
C
Class-
and
you
can
see
on
the
slide
here-
what
we're
actually
giving
the
it's
not
really
a
matter
of
the
servers
that
were
running
it
on,
but
how
much
of
the
resources
were
actually
signing
to
these
envoy
proxies,
and
you
see
there
were
about
a
tenth
of
a
corps
and
400
megabytes
and
memories
enough
to
handle
most
of
the
traffic
that
we're
getting
right
now
over
seven
proxies
yeah.
The
nice
thing
is
that
you
know
same
thing
native
kubernetes
integration.
We
can
do
pod,
auto
scaling.
E
We
touched
early
on
this
on
security,
but
again
it's
the
native
kubernetes
are
back
tooling
available
to
us
where
we
just
locked.
Every
every
team
has
service
accounts
and
the
deployment
there's
a
service
accounts
for
their
CI
CD
processes.
So
every
everyone
is
assigned,
or
every
responsible
team
for
their
every
team
is
responsible
for
their
own
app
in
their
own
namespaces.
C
So,
like
awesome,
the
asari
team,
we
can
manage,
like
the
base
virtual
service,
that
contains
all
of
the
configurations
like
whether
we
want
to
set
certain
security
headers
or
set
global
timeouts
on
request
and
everything
like
that.
The
developers
don't
really
have
to
think
about
any
of
that
stuff,
because
all
they're
doing
or
creating
a
more
route
or
more
routes
and
then
applying
them
in
their
own
namespaces.
That
inherit
all
the
value
that
we
have
in
our
base.
Virtual
services.
D
A
E
Yeah,
where
are
we
now?
Well
now
we're
actually
at
running
seven
on
bleep
Rocky,
Mountain
production?
We
have
several
several
teams.
Several
teams
now
are
are
in.
We
have
one
team:
that's
in
has
applications
in
beta
are
in
most
of
our
internal
traffic
is
actually
being
run
by
Glu
internal
services,
so
so
we've
already
started
making
sure
the
apps
are
talking
to
each
other
internally
via
glue
and.
E
We're
just
gonna
keep
like
our
lessons
learned
where
well
it's
hard
it's
hard
to
find
a
solution
that
fits
everyone's
needs,
but
the
way
that
blue
integrates
with
kubernetes
was
I
mean
we
can't
we
can't.
We
can't
force
a
solution
to
work
with
kubernetes
and
a
solution
can't
just
you
know,
kind
of
step
their
foot
in
on
one
particular
feature
of
kubernetes
and
then
just
abandon
it.
It's
right
it
has
to
be
all
or
nothing
with
kubernetes,
and
that
was
one
of
the
things
we
struggled
with
with
trying
to
do.
E
C
Yeah
I
would
say
that
you
know
the
goal
here
as
an
organization
is
to
be
completely
containerized.
We
want
all
of
our
applications
running
in
containers
running
kubernetes,
so
it
just
makes
sense
that
the
solution
we
would
pick
to
handle
our
API
gain.
We
also
run
the
kubernetes,
so
we
want
to
treat
that
as
our
like
main
platform.
E
And
everything
being
automated
and
in
testable
was
also
very
important,
because
at
the
end
of
the
day,
we
don't
want
to
be
a
bottleneck
to
the
developers.
We
don't
want
to
stifle
innovation.
We
want
everyone
to
be
empowered
to
from
from
insects
from
from
idea
all
the
way
to
production.
A
developer
should
be
able
to
create
any
new
endpoint
in
a
new
application.
Any
new
API
without
the
need
of
going
through
a
million
teams
just
just
to
get
something
rolling,
so
we've
implemented.
C
Yeah
I'll
just
pick
up
on
there
as
well,
so
one
we
tried
using
some
of
the
cloud
native
for
API
solutions
and
while
it
made
sense
of
the
beginning,
you
know
a
lot
of
people
are
familiar
with
AWS
and
the
resources
to
creating
their.
We
were
having
a
harder
time
with
the
security
there,
because
you
need
access
to
the
API
to
be
able
to
manage
AWS
resources.
D
D
Yeah
you
end
up
growing
it
I'm
not
knocking
anything.
You
get
cloud
cloud
native
either
from
something
like
agar
or
TCP
or
AWS,
but
they
just
they
can't
be
everything
to
everyone.
Unfortunately,
and
when
you
try
to
get
stuff
like
Auerbach
or
a
little
more
security
and
not
give
you
know
your
dev
teams,
full
god
rights,
essentially
to
your
infrastructure
that
you,
this
flexibility,
use
a
lot
flexibility,
so
we
needed
something
that
would
kind
of
just
rein
that
in
a
little
bit
so
and
oh
just
checkout
off.
Oh
yes,.
C
E
This
leads
us
into
our
what's
next
for
park
mobile
and
the
one
of
them.
Actually,
we
haven't
even
talked
about
this,
but
it
glue
can
actually
manage
your
service
mess.
So
everyone
understands
how
difficult
and
even
hotter
and
how
hard
this
do
is
to
to
learn,
install,
get
it
get
working
glue,
actually
they'll.
E
You
manager
point
it
was
actually
built
for
that,
because
they
understood
that
there
are
other
services
inside
the
cluster
and
especially
when
the
cluster
gets
huge
there's.
So
many
services
and
you're
gonna
need
you're.
Gonna
need
some
service
mice
to
manage
all
of
this
glue,
thought
of
that
and
integrated
that
with
their
systems.
So.
C
E
So
you
don't
have
to
worry
about
it,
and
the
next
thing
that
they
actually
do
very
well
is
their
server
list.
They,
they
integrated
key
me
into
one
of
the
first
integrate.
They
made
sure
that
key
Needham
worked
seamlessly,
so
you
don't
have
to
be
locked
in
with
Landa's.
You
can
control
how
your
your
servers
back
in
in
in
kubernetes
on
top
of
blue,
so.
D
C
E
Obviously,
always
continuing
to
break
down
our
monolith
and
I
mean
that's
right.
Now
we
have
a
handful
of
them
that
we're
trying
to
break
up
we've
actually
already
moved
moves
functionality
away
from
the
monolith
so-
and
it's
just
been
a
blue
blues
been
great
with
that
and
the
ability
just
to
be
multi,
multi,
cluster
and
multi
region,
since
this
do
actually
does
support
multi,
multi
cloud
installations
and
glue
is
built
on
top
of
that.
E
A
Right
thanks
guys,
there
are
a
few
questions
that
have
come
in
so
I
want
to
just
I'll,
read
them
off
to
you,
and
then
we
can
leave
that
slide
up
with
some
good
links
for
people
to
get
started
and
learn
more
about
both
solo
and
park.
Mobile.
So
first
question:
here's
to
Matt
API
ice
appeared
to
be
important
for
Parker
mobile.
Have
you
considered?
You
know
things
like
rescue
l.
B
Actually,
yes,
we
have
in
fact
we've
done
some
proof
of
concepts
with
it.
Look
I'm
just
gonna
share
my
philosophy,
not
everything
that
is
brand
new,
a
good
organization
necessarily
I
just
have
an
opinion.
Graph
QL
solves
a
certain
problem
statement.
You
have
to
make
sure
you
actually
have
that
problem
statement
for
which
you're
willing
to
make
the
investment
really
with
the
people
to
understand
how
to
you
know,
work
with
graph
QL
before
you
make
that
leap
and
in
our
case
I,
would
also
tell
you
we're
the
most
advanced
in
our
industry.
B
I
believe
based
on
my
interactions,
and
you
have
to
you
think
about
that
ecosystem
of
a
hundred
plus
folks,
you
know,
there's
still
soap
service
is
out.
There
mainly
risk.
Yes,
taking
that
leap
to
graph
QL
for
our
business.
We
don't
want
to
get
too
far
ahead
of
practicality.
So
that's
that's
a
messy
Tio's
answer
to
you
know
what
we
invest
in
and
what
we
don't
even.
C
I
can
add,
I
can
add
one
point
to
that:
Matt
we
have
actually
explored.
There
is
a
side
product
of
glue
called
scoop,
which
is
actually
allows
you
to
natively,
integrate
graph,
QL
and
points
inside
glue.
We
started
off
using
a
Tobias,
app
sync,
but
we
have
been
looking
into
switching
out
to
you
glues
version
as
well.
We,
this
hasn't
been
on
the
top
of
the
priority
list
right
now,
but
has
definitely
been
something.
We've
looked
at
I.
A
Think
it's
an
interesting
point
that
you
bring
up,
that
it's
a
there's,
always
going
to
be
new
technology
and
it's
important
to
just
as
a
technology
team
to
be
aware
to
learn
it
and
understand
it.
But
it's
you
don't
always
go
from
like
the
the
new
widget
first.
You
actually
go
from
your
use
case
first
and
then
your
use
case
on
the
ecosystem
you
serve
and
then
there's
that
place
where
those
meet
in
the
middle.
A
D
D
Yet
we've
performed
test,
the
other
ones,
the
restful
ones,
but
the
gr
PC
ones
are
available
for
consumption
internally
for
our
teams
and
we're
looking
to
leverage
that
yeah
against
glue,
but
also
from
micro
service
micro
service
and
the
whole
service
measure,
so
we're
hopefully
working
towards
that
for
internal
communications.
This
year,
yeah.
C
C
A
C
A
C
Well,
we
haven't
really
had
that
much
of
a
use
case
for
chef
really
with
kubernetes,
since
everything
is
already
provisioned
with
configuration
files,
it's
kind
of
and
manages
itself
that
way.
Well,
we
have
used
terraform
2
in
both
local
provisioners
when
so
after
the
infrastructure
comes
up,
it
can
actually
go
underneath
and
create
a
lot
of
the
inside
stuff,
so
actually
is
terraformed
to
provision
the
entire
eks
cluster
and
we've
been
working
on
it
for
a
while
now
to
help
us
with
upgrades
and
all
our
stuff
yeah.
D
D
It's
quite
nice,
that's
something
that
we
I
think
is
part
of
our
journey.
We
started
looking
into
that
because
we
weren't
really
cloud
native
to
begin
with
and
we
did
have
a
lot
of
just
old-school
concepts
and
and
kind
of
your
typical
on-prem
environment.
So
we
were
like
hey.
Alright,
you
know
what
let's
look
at
ansible.
Let's
look
at
chef:
let's
see
what
we
can
accomplish
with
on-prem,
but
then
we
look
like
we
keep
saying
we
move
so
fast
here
that
I
think
we
we
did
like
a
quick
discovery.
All
yeah
ansible
looks.
E
An
image
that
literally
just
has
a
kernel
that
that's
it
and
just
to
install
whatever
our
dependencies.
We
need
the
application
needs
so
having
to
manage
individual
servers
other
than
the
the
ec2
s
that
house
the
monolith
yeah,
we
don't.
We
will
just
use
terraform
to
skip
the
infrastructure
and
then
the
developers
just
the
way
they
interact
with
the
community
closer,
is
through
helm.
So
it's.
D
Very
much
a
kind
of
a
plug-in
architecture
or
a
plugin
pattern,
essentially
for
everything.
So
it's
all
the
books
that
are
provided
along
the
way
in
the
pipeline
that
developers
hook
into
and
it
just
allows
them
to
do
it
work
again.
This
team
no
longer
is
the
bottleneck.
It's
like
the
developers
have
all
the
power
within
rails,
sir,
you
know
certain
rails,
but
they
have
all
the
power
to
do
things.
So
it's
like.
C
A
Have
personally,
as
a
solo
employee
here,
I
have
a
question
for
you
and
to
elaborate
a
little
bit
on
your
the.
When
you
were
talking
about
your
scale,
testing
and
the
environment,
you
meant
you
had
a
coming
in
there
about
how
much
resource
the
Envoy
proxies
were
using
and
the
the
other
bit
was
the
latency
that
having
the
glue
the
milliseconds
that
glue
added,
how
much
compute
and
memory
is
that
are
the
glue
components
using
on
your
existing
kubernetes
nodes,
because
it's
right,
you
can
stall
it
on
top.
C
We've
been
able
to
see
these
metrics
as
glue
comes
with
a
built-in
Prometheus
server
and
Cortana
endpoints
that
we
can
actually
see
these
requests
coming
in
and
have
a
lot
of
durability
into
that.
But
we
can
see
on
the
servers
that
when
we
were
doing
these
load
testings
with
like
100,000
requests,
they
barely,
but
they
barely
move
right.
E
A
D
E
D
A
One
I
want
to
say,
like
you,
talk
a
lot
about
security
and
kind
of
role
based
access
control,
you're
using
you're,
using
kind
of
the
native
ku
bar
back
and
then
you're
namespacing.
The
developers
did
you
have
another
weather
and
integration
also
with
kind
of
like
your
own
identity
management
system,
and
if
so,
what
do
you
use
so.
C
We're
using
as
far
as
access
to
the
AMS
environment,
we're
using
AWS,
is
SSO
product
which
connects
via
LDAP
to
our
ad
I'm
in
the
office
and
we're
actually
able
to
map
because
we're
using
eks,
which
is
you
know,
Amazon
native
we're
actually
able
to
map
these
hey.
W
souls
2
accounts
inside
kubernetes.
So
it's
authenticate
to
talk
to
our
kubernetes
cluster.
You
actually
have
to
authenticate,
via
our
ad
service,
nervous
right
and
pass
through
the
role
that
you've
assumed
to
be
able
to
talk
to
the
kubernetes
cluster.
A
That
is
it
and
we
are
actually
at
the
top
of
the
hour.
I
want
to
thank
you
all
the
whole
Park
mobile
team
for
presenting
and
answering
the
questions
and
they're
also
very
active
in
slack.
So
if
there's
folks
on
the
webinar
here,
if
you
have
questions,
you
see
our
link
to
slack
Solo
diet,
io,
you
can
find
them
in
slack
and
also
a
some
more
direct
questions
may
be
ones
that
you
know
or
you
are
you
didn't
post
here
as
you
noodle
on
this
information.
This
is
recorded
and
I'll.