►
From YouTube: Building a Scalable, Compliant, Multi-Cloud Bank with a Service Mesh - Kasper Nissen, Lunar
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2023 in Amsterdam, The Netherlands from April 17-21. Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Building a Scalable, Compliant, Multi-Cloud Bank with a Service Mesh - Kasper Nissen, Lunar
Kasper Nissen, Lead Platform Architect at Lunar, will share how Lunar built a scalable, multi-cloud bank with cloud native tech, allowing for rapid product iteration while simplifying compliance with strict regulatory requirements. The flexible technical setup also allows them to rapidly absorb newly acquired startups, ensuring they start generating value for the bank quickly. Lunar started by centralizing its log and release management tooling in a single cluster connected to multiple Kubernetes clusters across GCP, Azure, and AWS — all connected through a service mesh. This allowed them to remove state and complexity from edge clusters and manage infra services centrally while exposing these central services to edge clusters. This transformation is part of a strategy to treat the platform as a product and provide the same set of platform features across cloud providers. Attendees will learn how Lunar implemented multi-cluster communication across clouds and how it all fits together with GitOps as a multi-cloud management layer to comply with regulations on the audit trail of all changes, following the principles of least privilege, and the ability to perform cluster failovers.
A
Hi
everyone
I'm
here
to
talk
a
little
bit
about
a
case
study
that
I
work
at
a
company
called
lunar,
and-
and
this
is
just
our
sort
of
adoption
story
of
service
mesh
in
a
financial
service
industry,
so
yeah
building
a
scalable
compliant
multi-cloud
bank
with
a
search
mesh.
Just
before
that
I'll
just
introduce
myself.
A
Just
trying
to
to
build
the
community
around
Cloud
native
in
general,
I'm,
also
a
link,
a
d
Ambassador,
so
I
guess
that's
sort
of
a
spoiler
alert
on
on
the
service
mess
that
we
chose.
Yeah
yeah.
The
last
thing
about
me.
I
was
my
way
into
this.
The
space
around
Cloud
native
was
actually
before
it
was
called
Cloud
native
I
did
a
master
thesis
in
2016
about
raspberry,
pies
and
kubernetes,
and
how
sort
of
universities
could
utilize
Raspberry
Pi's,
actually
sort
of
teach
students
about
this
new
new
way
of
doing
things?
A
A
650
employees.
Now
it's
been
growing
pretty
quickly
and
you'll
see
a
graph
in
a
second.
So
from
the
more
technical
aspects
we
deploy
around
50
changes
to
production
on
average
every
day,
so
I
think
that's
at
least
from
comparing
to
the
the
banks
and
the
nordics
at
least
that's
a
pretty
high
number
because
they
are
probably
doing
it
once
a
week
or
once
a
month
with
a
lot
of
those.
Three
we've
been
talking
to
yeah,
run
around
400
micro
Services
now
across
three
different
clouds.
A
The
scale
and
the
growth,
so,
as
you
can
see,
we,
we
sort
of
had
like
an
exponential
growth
in
from
from
2019,
both
in
terms
of
customers,
but
also
in
terms
of
employees
at
the
company.
We
went
from
I
think
around
150
employees
in
19
to
almost
700
employees.
Now,
so
it's
been
growing
pretty
quickly.
A
But
let's
talk
a
little
about
how
we
actually
sort
of
started
out
our
evaluation
story
of
a
service
mesh.
How
to
actually
did
this?
We
it's
always
been
a
complexity
compared
to
the
value
we
were
sort
of
getting
initially,
as
you
saw
on
the
graph.
We
were
we
weren't
that
many
people,
especially
not
in
sort
of
the
platform
area
of
the
of
the
company.
A
We
were
one
two
people,
so
complexity
was
really
something
that
we
we
needed
to
to
ensure
that
that
we
were
able
to
sort
of
you
know
handle
that
as
we
sort
of
grow,
so
it
took
a
while
for
this
before
the
sort
of
the
feature
set
was
was
there
for
us
and
what
really
tipped
the
scale
was.
The
multi-cluster
aspect
and
I'll
come
back
to
that
a
little
bit
later,
why
that
is,
but
we
basically
have
evaluated
servicemeness
for
three
and
a
half
years
before
we
actually
adopted
it.
One.
A
We
tried
out
the
layer,
First
Link
at
D1,
Lincoln
D1,
with
the
node
proxy
setup
name
and
set
deployments
and
everything
when
istio
came
out.
We
tried
that
out
was
a
bit
too
complex
for
us.
At
that
time,
then
LinkedIn
sort
of
changed
into
conduit
tried
that
out,
we
weren't
really
ready.
Yet
we
were
still
like
one
and
a
half
people,
as
you
can
see
at
the
bottom.
A
D2
yeah
still
not
enough
people
to
actually
handle
the
complexity
of
actually
adding
this
into
our
stack
and
bear
in
mind
these
platform
Engineers
were
focusing
on
kubernetes
observability,
all
all
the
the
stuff
that
we
have
running,
so
it
wasn't
until
the
2020
sort
of
we
we
needed
to.
We
were
in
the
process
of
actually
becoming
a
bank
at
that
point
and
there
were
some
requirements
in
actually
getting
a
banking
license,
so
we
were
starting
to
looking
looking
at
all
the
features
again
having
mtls.
A
All
these
things
were
sort
of
a
thing
that
we
now
needed
to
look
at
again,
and
also
this
multi-class
multi-cluster
sort
of
thing
was
becoming
a
sort
of
a
topic
for
us
and
I'll
show
you
that
in
a
second
so
which
one
to
choose
well
for
us,
it
was
really
about
the
the
Simplicity
of
of
the
mesh
and
and
for
us
with
the
number
of
people.
Simplicity
was
really
the
thing
and
then,
at
this
point
the
Linker
D2
proxy
at
least
had
like
a
a
lower
sort
of
resource.
A
The
reason
for
why
we
started
out
doing
multi-cluster
was
that
we
were
sort
of
having
this
set
up.
Where
we
had
like
different
environments,
we
were
replicating
our
observability
stack.
We
had
a
lot
of
you
know,
stateful
context,
services
that
are
pretty
hard
to
sort
of
run,
and
that
was
pretty
annoying
to
sort
of
have
that
replicated
setup
between
all
the
different
environments.
So
we
wanted
to
do
something
else,
and
at
this
point
we
were
also
sort
of
like
moving
towards
githubs.
A
A
So
we
were
all
we
were
constantly
taking
snapshots
of
this
EBS
volume
and
then
at
some
point
we
needed
to
restore
it
and
sort
of
hook
it
into
to
the
to
lock
management
solution
in
the
failover
cluster
and
we
were
losing
logs,
which
wasn't
really
a
good
thing
for
us,
because
all
audit
locks
everything
was
sort
of
flowing
into
the
system.
So
that
was
really
acceptable.
A
A
So
what
we
did
was
actually
starting
to
to
try
this
out
with
a
service
mesh
and
connecting
clusters
across
AWS
account
by
basically
adding
a
service
mess
trying
it
out.
We
tried
out
both
istio
and
linked
at
this
point
and
and
for
us,
it
took
like
an
hour
to
get
Link
at
the
urban
running,
which
was
pretty
amazing
for
us
to
just
see:
hey
now,
we're
able
to
to
actually
connect
clusters
across
clouds,
and
so
we
actually
just
used
that.
A
But
our
sort
of
initial
adoption
of
service
mesh
was
basically
to
to
do
this
multi-cluster
setup,
where
we
sort
of
put
fluent
bid
into
the
service
mesh
and
the
log
management
solution
into
a
to
the
service
mesh
and
from
the
point
of
fluent
bit
as
you
can
see
up
in
the
the
workload
cluster.
So
it's
basically
just
a
transparent
communication,
because
it's
just
rewriting
to
a
normal
kubernetes
service
in
in
the
setup,
and
then
it
flows
through
the
multi-cluster
control
plane
that
I'll
introduce
in
a
second.
But
it
was
pretty
nice.
A
One
thing
that
was
also
very
important
for
us.
There
is
that
we
needed
to
have
one
directional
links.
We
didn't
want
to
be
able
to
go
into
this
centralized
platform
cluster
and
be
able
to
do
requests
the
other
way
around.
So
you
can
actually
change
things
in
production
from
a
centralized
place,
so
we
wanted
to
be
only
possible
to
ship
data
in
One
Direction,
which
was
also
pretty
easy
to
do.
A
So
our
platform
mission
is
really
to
to
empower
our
developers
that
more
or
less
what's
written
here,
build
everything
in
as
much
as
possible.
We
do
that
by
we've
created
a
couple
of
tools.
Ourselves
doesn't
matter
that
much,
but
shuttle
up
here
is
is
open
source.
You
can
find
it,
but
it's
a
way
for
us
to
sort
of
deal
with
centralized
scripts
templating.
A
We
do
a
lot
of
different
stuff
that
sort
of
make
it
easy
for
developers
and
we
can
provide
yeah
compliance
basically
out
of
the
box
for
them
as
a
platform
team,
so
they
don't
have
to
to
do
that
themselves
and
I'll.
Show
you
some
examples
in
a
second.
The
other
tool
that
we
need
to
to
mention
here
is
release
manager
and,
as
a
CLI
tool,
called
hem
control.
It's
not
really
like
the
meat.
It's
the
ham
was
the
first
chimpanzee
in
space.
It
was
a
really
bad
name.
A
I
always
have
to
explain
it
when
I
talk
about
it,
so
it's
kind
of
annoying,
but
anyway
it's
called
hand
control
and
what
it
does
is
it
it's
basically
able
to
move
artifacts
from
one
place
in
a
in
a
git
repository
to
another
place
in
the
git,
repositor
and
I'll
show
you
a
short
picture
here.
We
start
with
shuttle
and
what
it
basically
does
for
us.
It's
it's.
Creating
this
abstraction
on
every
service.
A
So
that's
sort
of
something
I
just
needed
to
to
sort
of
highlight
to
in
order
to
to
understand
how
we
then
sort
of
implemented
this
with
a
service
mesh
and
how
does
that
really
help
us
as
a
bank?
Well,
right
now
we
get
mtls
out
of
the
box,
which
is
definitely
a
nice
thing
as
a
bank
to
actually
get
this
out
of
the
box
move
towards
zero
trust.
A
Networking
the
Beyond
part
by
Google
research,
so
having
that
is,
is
really
a
thing
that
was
really
good
to
to
get
another
issue
we
were
starting
to
see
at
this
point
was
the
grpc
load
balancing
internally,
if
you're?
If
you
try
to
do
a
tlpc
in
kubernetes,
you
might
know
that
once
you
sort
of
connect
to
a
pod,
all
requests
are
sort
of
pinned
to
that
part,
which
is
quite
annoying
so
having
something
in
there
that
are
sort
of
able
to
to
help
you
distribute
and
actually
do
load
balancing.
A
A
It's
basically
a
nice
way
for
our
developers
to
sort
of
specify
item,
potency,
retryable,
endpoints
and
paths
so
that
the
proxy
layout
can
do
this
for
them,
and
they
don't
have
to
do
this
in
their
services
and
they
can
do
specify
this
using
the
the
specs
they're.
Already
writing
the
sort
of
specifications
in
with
protopaths
or
open
apis
the
xmlers
here
and
just
get
the
mesh
to
actually
do
this
and
handle
this
on
the
on
the
network
layer
of
the
proxy
layer,
instead
of
them
doing
it
yeah.
A
So
it's
just
if
a
request
fails
retry
by
the
proxy
level
instead
of
doing
this
in
the
service.
That's
also
a
nice
feature
to
get
and
then
last
feature
that
we
are
really
excited
about.
Is
Linger
d212.
That's
now
this
path
based
routing
policies
that
allows
us
to,
for
example,
in
this
example,
and
say
that
Prometheus
is
only
allowed
to
scrape
the
metrics
endpoint
so
being
able
to
lock
down
and
sort
of
ensure
that
only
services
that
need
to
talk
to
each
other
actually
are
able
to
to
talk
to
each
other
cool.
A
The
first
thing
we
did
was
to
create,
like
an
alpha
feature
in
our
shuttle
setup
that
allows
developers
to
say,
hey,
I,
want
to
deploy
this
into
our
development
environment
and
see
how
it
works,
and
we
let
that
run
for
a
while
and
had
people
experiment
and
and
see
if
they
sort
of
could
find
any
errors.
And
then
we
moved
on
to
like
a
more
Global
thing
that
now
all
environments
just
are
sort
of
being
added
into
the
mesh,
and
then
lastly,
we
have
enabled
this
by
default.
A
So
now
this
is
something
you
as
a
developer
lunar
get
out
of
the
box.
You
don't
have
to
think
about
this
anymore.
It's
just
part
of
the
abstractions
and
sort
of
the
things
that
we
provide
as
a
platform
team
and
then
multi-cluster
functionality,
so
I'm
not
sure
if
you're,
that
familiar
with
how
Linker
D
works
and
and
the
multi-cluster
aspects
of
linked,
so
I
just
wanted
to
to
bring
this
in
as
well.
A
So
in
this
case
you
will
have
a
bi-directional
link
between
your
two
clusters
and
what
you
get
is
some
components
you
get
a
Gateway
and
you
get
a
service
mirror
and
have
another
example
that
sort
of
highlights
what
these
components
do.
So
the
service
mirror
basically
listens
for
the
API
server
on
the
posting
or
sorry,
the
opposite
cluster.
Listening
for
specific
annotations,
the
default
one
is
that
on
a
service
of
a
kubernetes
service
in
one
cluster,
you
can
set
The
annotation
mirror.lingerd.io
export
it
through.
A
To
basically
call
the
service
and
and
traffic
will
just
go
through,
I
haven't
created
the
Gateway
here,
but
there's
a
Gateway
in
in
the
middle
here
as
well
to
actually
sort
of
Route
the
traffic
into
to
the
service,
a
on
the
other
side,
so
that's
sort
of
how
it
works
very
simply
or
simplistically,
then
for
us.
So
we,
as
mentioned
we
were
starting
out
with
this
log
management
between
AWS
account.
But
then
it's
at
some
point.
Our
company
and
our
founder
decided
to
to
acquire
another
company.
A
They
were
also
doing
a
lot
of
things
around
creating
Azure
app
services,
so
we
needed
a
way
to
to
connect
Azure
app
services
with
stuff
running
a
kubernetes,
cluster
and
AWS
and,
at
the
same
point
we're
also
building
stuff
around
in
TCP
because
we're
moving
our
data
stack
there.
So
we
also
needed
connectivity
between
those
accounts
as
well,
and
we
thought
hey.
We
have
multi-cluster
running
already.
It
works
super
nice
we've
been
running
that
for
a
year
it's
stable.
A
A
So
how
do
we
actually
contact
an
app
service
from
a
kubernetes
service
in
AWS
through
a
kubernetes
cluster
and
then
out
to
to
the
actual
resource
in
Azure
and
the
other
way
around
as
well,
because
the
Azure
app
service
might
need
to
be
able
to
request
something
that
runs
in
a
kubernetes
cluster
in
AWS?
So
how
do
I
to
actually
handle
that
use
case?
A
We
sort
of
looked
at.
We
couldn't
really
find
a
good
solution
in
sort
of
the
open
sources,
so
we
just
built
something
ourselves
using
Envoy.
We
call
that
the
backbone
Gateway-
it's
basically
just
an
abstraction
of
over
some
configuration
of
envoy,
but
it
really
provides
us
with
a
sort
of
a
thing
we
can
deploy
in
each
cluster.
That
makes
connectivity
in
and
out
of
a
cluster
in
each
Cloud
possible,
and
then
we
build
a
nice
sort
of
abstraction
using
this
shuttle
tool.
A
So
the
use
case
basically
yeah.
My
service
needs
to
be
able
to
request
credit
scores
from
a
service
running
in
Azure,
app
Services.
How
do
I
do
that?
I
just
showed
you
that,
so
it
looks
something
like
this
super
easy
for
them.
They
just
needed
to
add
this
into
a
repository
and
then
sort
of
the
platform
took
care
of
carry
it
for
him.
A
It
was
like
60
seconds
on
average,
which
was
an
interesting
finding,
but
it's
nice
to
have
this,
and
now
we
we
sort
of
can
monitor
all
the
links.
So
we
built
that
ourselves
to
to
basically
just
do
that.
It
was
pretty
simple
and
wrapping
up
I,
think
service
mess
really
sort
of
increases,
security,
reliability
and
scalability
for
us,
but
we
needed
to
build
a
lot
of
stuff
and
sort
of
rabbit.
A
lot
of
things
around
it
because
we
also
want
to
make
this
easy.
A
We
don't
want
our
developers
to
to
do
a
lot
of
yaml
and
stuff
like
that.
We
want
to
sort
of
abstract
all
of
that
away,
and
but
now
from
the
developer
perspective,
it's
it
it's
pretty
simple
for
them.
They
don't
really
have
to
care
about.
All
of
this.
We
take
care
of
that
for
them
with
the
backbone
Gateway
that
I
talked
about
and
showed
you
before.
A
We
now
have
like
this
communication
backbone
between
basically
the
three
different
clouds
that
we
are
present
in
right
now,
and
we
can
expand
that
to
anywhere
that
where
we
can
put
a
kubernetes
cluster
and
and
add
a
link,
a
d
control
plane,
so
that's
pretty
nice
yeah
and
then
this
shuttle
tool
basically
just
allows
us
to
to
take
in
all
of
these
new
technologies.
As
a
platform
team
experiment
see
what
works,
what
doesn't
work?
A
Try
out
the
different
I,
don't
know,
service,
misses
and
and
see
what
works
and
what
doesn't
and
then
decide
and
and
have
them
adopt
it.
And
the
last
thing
that
we
sort
of
learned
in
this
and
I
haven't
talked
that
much
about
githubs.
But
the
way
we
sort
of
structured,
our
git
repository
was
that
each
environments
are
represented
by
a
directory
in
in,
like
this
conflict
repository
and
having
this
tool
that
I
talked
about
earlier.
A
The
Hem
control
tool
basically
just
allows
us
to
create
a
new
folder
for
Azure
and
Dev
or
DCP
Dev,
and
then
we
can
basically
just
use
this
tool
to
release.
So
we
get
like
a
a
uniform
way
to
basically
release
stuff
into
multiple
different
Cloud
providers,
which
is
pretty
nice.
Of
course,
there
are
some
Services
if
you're,
using
like
a
load
balancer
in
TCP
or
AWS,
or
there
are
some
differences,
probably
some
different
annotations,
based
on
what
kind
of
load
balance
they're
using.
A
B
C
What
are
your
concerns
with
intra
and
Inter
mesh
security
like
between,
like
East-West,
between
pods,
like
where
does
that
fall
into
your
guys,
like
like
design
and
thoughts
around
service
mesh?
So
can
you
repeat
again,
the
question
was
so:
what
are
your?
Do
you
guys
take
any
approaches
to
deal
with
like
layer,
7
Security
in
service
mesh,
so
like
doing
like
internal
Wharf
between
pods?
That
kind
of
thing.
A
No
not
really
so
right
now.
All
of
this
is
is
basically
done
using
you
know,
a
white
listing
of
IP
addresses
a
very
static
old
school
kind
of
way
of
doing
it,
I
guess
so.
So,
basically,
the
control
plane.
When
you
run
the
link
command,
it
generates
a
configuration.
It
generates
the
secret
and
API
token,
so
that
can
talk
to
the
API
server
of
the
other
cluster
and
then
we
just
internally
sort
of
allow
communication
across
the
different
yeah,
basically
the
different
clusters.
So
that's
that's
how
it
works
today.
So.
A
B
D
Thanks
great
talk
and
I'm,
like
really
happy
that
this
has
worked
out
so
well
for
you,
it
seems
in
production,
I'm
kind
of
curious
about
you
mentioned
at
the
very
beginning
that
scale
of
complexity
versus
features
and
so
on
and
we're
sitting
on
that
scale
at
the
moment
and
I'm
kind
of
curious
about
having
run
with
this
in
production
for
a
few
years.
You
mentioned
a
lot
of
things
about
preservability
and
that's
what
a
lot
of
people
say
around
the
service
meshes.
D
A
It
definitely
caused
some
interesting
problems:
ports
not
being
allowed,
or
some
using
some
weird
Protocols
of
some
some
sort
in
some
of
the
services
that
we
had
running.
So
we
definitely
see
some
issues,
but
for
us
it's
been
really
I
think
the
outweighs
sort
of
so
all
the
features
and
the
things
we
get
outweigh
some
of
this
complexity.
But
it's
been,
we've
been
doing
a
lot
of
stuff
around
actually
monitoring.
What
is
the
proxy
doing?
A
Controls
configuring
the
control
plane
at
some
point
when
we
added
this
to
the
entire
fleet
of
services,
we
need
to
scale
the
control
plane
a
little
bit
and
and
of
course,
had
to
to
spend
some
time
and
actually
figuring
out
what
is
going
on
now
that
we
see
this
LinkedIn
destination
thing
is
it's
just.
You
know
Crest
looping.
So
why
is
that
so
it
but
I
think
we.
A
E
Great
talk,
I
just
had
a
question
about
your
adoption
face.
You
mentioned
that
it
took
a
few
years
to
adopt
a
service
mesh.
Was
there
any
sort
of
a
notable
pointer
friction
that
prolonged
that
adoption,
and
was
it
like
the
complexity
of
the
services
measures
of
the
time
or
was
it
that
they
were
too
invasive
yeah.
A
I
think
when
we
tried
out
Linker
D1
back
in
17,
we
just
you
know
put
so
you
have
the
option
to
just
enabling
a
d
on
the
the
link
of
the
proxy
injector
on
a
namespace
level,
and
when
we
did
that
everything
just
broke,
nothing
worked.
We
needed
to
figure
out
what
what
the
hell
is
going
on
here,
so
that
sort
of
yeah
that
was
kind
of
why
we
stopped
back
then
then
I
actually
had
like
in
I
think
it
was
in
19.
When
my
colleague
tried
out
Lincoln
D2.
A
He
actually
did
a
presentation
at
a
Meetup
at
some
point
and
showing
how
easy
it
was
to
do
this
incremental
incremental
adoption
of
a
of
a
mesh.
But
we
wasn't
really
ready
at
that
point
still
to.
We
were
still
like
two
people
that
were
sort
of
handling
everything
around
platform.
So
we
didn't
really
feel
that
we,
we
would
yeah
have
enough
people
to
actually
sustain
this,
but
yeah
I
think
try
it
out.
A
F
Okay,
good
morning
in
regards
to
your
industry
being
highly
regulated
and
going
down
the
multi-cluster
routes
along
with
what
I
assume
is
sensitive
data,
did
you
have
any
frictions
or
any
restrictions
in
regards
to
auditing
or
regards
to
with
across
cross-cluster
communication
and
basically
data
where
it's
stored?
All
that
kind
of
thing.
A
As
it
is
right
now,
we
haven't
really
had
that
any
sort
of
audit
things
it's.
We
have
a
really
sort
of
progressive
CSO
that
are
very
techy
and
I.
Think
he's
really
good
at
explaining
what
is
going
on
here
in
a
language
that
they
understand
and
I
think
that's
been
very
helpful,
I'm
not
involved
in
in
that
aspect,
but
now,
if
we
haven't
really
gotten
any
anything
yet
at
least
we'll
see.
Thank.