►
Description
Don’t miss out! Join us at our upcoming hybrid event: KubeCon + CloudNativeCon North America 2022 from October 24-28 in Detroit (and online!). 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.
The Power of Cloud Native in Financial Institutions - Mateusz Pruchniak, mBank SA
Cloud Native architecture and public clouds have become the standard solution for modern IT for fast innovation, delivering more value to their customers, with dramatically less effort. This is a big challenge, especially for regulated financial sectors such as banking due to the complexity of their legacy systems, and compliance challenges including concerns raised by European regulators. For authorities (EBA, EIOPA, ESMA) having a flexible multicloud strategy and solid foundations for portability and interoperability has never been more relevant. In this session, Mateusz will present a good practice guide offering practical tips and tricks for designing and deploying Cloud Native business-critical systems in Financial Institutions fulfilling the assumption of having an easily portable architecture, with an easily tested Exit Plan and finally minimizing cloud concentration risk. Presented practical ideas can be used for designing from scratch and during migration to Cloud Native.
A
A
This
is
our
my
agenda
today
I
speed
a
speed.
Our
my
talk
to
two
parts.
The
first
part
is
about
the.
I
will
introduce
you
to
the
world
of
the
regulated
environment
and
we
talk
about
the
definition
to
be
on
the
same
page
during
this
conversation,
and
the
second
part
will
be
about
the
use
case
of
cloud
native
and
in
the
financial
institution
in
banking.
Insurance
is
the
same
almost
the
same
stuff,
all
right.
A
I
think
it's
good
to
start
from
to
reference
the
definition
of
cloud
native,
because
it's
the
first
first
talk
on
kubecon
today
after
the
keynotes
the
first
day,
so
to
be
on
the
same
page,
what
is
mean
the
cloud
native
and
I
will-
and
I
will
explain-
I
will
commence
the
definition-
the
cloud
native
tag
native
from
financial
institution
perspective
from
the
bank
perspective
from
company
who
has
people
money
savings
mortgage.
So
it's
very
high
responsibility.
A
We
have
in
iit
department
to
keep
everything
secure
and
to
secure
and
secure
using
the
public
cloud
we're
talking
about
almost
public
cloud,
all
right,
the
first
paragraph,
the
cloud
native
technologies
empower
organization
to
build
and
run
scalable
application
in
modern,
dynamic
environments
such
as
public
private
hybrid.
It
means
that
it
means
that
the
cloud
native
technology
is
universal
for
public
private
hybrid
cloud,
for
us
for
for
banking
industry
for
insurance
is
very
interesting
because,
thanks
to
it,
we
have
independent
from
the
type
of
the
client
thanks
to
this
technology.
A
A
Systems
that
are
resilient,
manageable
and
observable
it's
about
the
micro
services.
For
me,
the
last
paragraph
is
about
the
cloud
native
computing
foundation.
Seek
to
drive
adoption
of
this
paradigm
by
fostering
and
sustaining
ecosystem
open
source
in
vendor
neutral,
open
source
is
the
nature
of
the
independent
you
can
for
the
code.
Of
course
it
depends
on
the
license,
but
you
can
form
the
code.
You
can
extend
this
the
code,
you
can
use
this
code,
library
tools
and
so
on
and
vendor
neutral
projects.
A
So
it's
vendor-neutralized,
so
we
like
them
to
be
vendor
neutral
without
the
vendor,
locking
it
was
cloud
native
definition.
Now
is
cloud
agnostic.
What
is
agnostic,
agnostic,
I.t?
It
means
interoperability.
So
it's
mean
that
cloud.
Agnostic
system,
service
tools
are
independent
from
kind
of
the
kind
of
the
cloud
is
dependent
on
private,
hybrid,
independent
from
cloud
provider,
aws
gcp
azure.
So
we
build
to
run
system
and
we
can
run
in
every
cloud
what
we
want
in
every
cloud.
What
we
want
some
say.
A
A
Everything
is
for
me,
everything
is
true,
you
can
use
simultaneously
or
you
can
migrate
from
one
cloud
to
another
crowd,
but
this
is
from
my
perspective.
This
is
very
expensive
to
build
cloud
agnostic
tools
and
we
we
lost
opportunity
to
use
interesting,
but
specific
cloud
features
what
we
have
in
the
public
cloud.
Some
features
of
from
the
aws
features
from
gcp,
which
are
specific
and
we
lose
because
we
need
to
be
cloud
agnostic.
I
think
not
always.
We
need
to
be
cloud
agnosis.
A
A
And
this
is
the
this.
Is
the
this
slide
when
I
would
like
to
introduce
to
a
financial
world
irregular
world
in
european
union,
of
course,
european
union.
We
have
three
authorities,
we
have
aba
aba
for
banking
sector,
iopa
for
insurance
sector
and
asthma
for
rest
of
the
financial
institution.
Of
course,
every
every
country
the
european
european
union
can
have
has
their
own
local
national
authorities
like
in
the
poland,
we
have
the
polish
financial,
financial
supervision
authority
and
all
of
the
authorities.
A
A
What
we
have
here,
what
we
have
in
this
guidelines.
We
have
five
five
key
areas.
First,
is
data
and
system
security,
data
and
system
security?
In
this
guidance,
you
can
find
that
the
the
most
important
things
that
you
we
need
to
ensure
shared
responsibility
between
us
and
cloud
provider
where's
the
border
ways
the
border,
especially
including
relation
to
threat
detection
incident
management.
Patch
management-
where
is
the
responsibility
between
our
the
client
and
provide
the
cloud
provider,
especially
sometimes
it
should
be
on
the
contract,
should
be
right
in
the
contract.
A
We
always
need
to
encrypt
all
data,
always
always
in
transit
address.
We
need
to
encrypt
all
data
by
default,
using
cloud
provider
keys,
but
if
we
will
keep
the
legally
protected
data,
for
example,
personal
data
account
details,
transaction
transaction
details.
We
need
to
use
customer
manage
keys,
we
need
to
use
own
keys
which
we
are
owner.
A
We
need
to
use
our
keys
and
we
need
to
and
in
the
guidelines
you
can
find
the
requirements
where,
where
we
should
keep
this,
where
we
have
to
keep
this
to
take
ease,
it
need
to
be
hardware
protector
keys
hardware
protector
in
hsn,
so,
for
example,
in
azure,
is
quite
easy
to
achieve,
because
we
have
other
key
vault.
We
need
to
choose
the
premium
and
create
a
key
key
in
hsm
hardware
protector
key,
which
you
will
be
using
for
to
encrypt
encryption
of
our
data
at
rest.
A
A
I
never
leave
this
this.
This
officer,
this
area,
sorry
this
area
and
the
third
one
is
risk
assessment.
I
think
it's
the
most
time
consuming
part
of
everything
we
need
to
analyze.
We
need
to
make.
We
need
to
make
risk
assessment
risk
analysis
from
several
perspectives
from
security,
business,
business
continuity,
legal
compliance,
operating
operational
risk
and
concentration.
Risk
concentration
risk
is
the
high
level
risk.
A
A
Access
and
audit
rights,
financial
institution
should
have
rights
to
access
and
right
right
audit.
There's
nothing
interesting
here,
the
last
one
exit
strategies
we
need
to
have
exit
plan,
it's
important
to
not
confuse
business
continuity
management
with
exit
strategies,
because
bcm
is
not
the
same.
So
what
is
exit
strategy?
This
exit
strategy
is
long-term
process
long-term
ex
to
execute
we
need
to.
A
A
As
you
can
see
here,
we
have
information
that,
in
case
of
outsourcing
of
critical
important
functions,
film
should
ensure
that
it
is
able
to
exit
cloud
outsourcing
revenue
without
and
you
disruption
with
business,
so
only
for
critical
important
functions.
This
is
quite
important
and
there
is
information
that
you
need
to
be
still
compliant
with
obligation
and
still
be
secure
and
and
so
on
so
on.
But
there
is
information
for
critical
important
functions.
This
is
some
hot
hatch
height,
which
we
need.
A
We
use
on
this
talk
and
this
exit
plan
should
be
comprehensive,
documented
and
sufficiently
tested
and
updated
during
the
leaving
of
our
system
in
the
public
cloud.
This
is
additional
cost
which
we
need
to
additional,
maintain,
maintain,
maintain
maintenance
accord
which
need
to
be
which
we
have,
because
we
need
to
have
exit
plan
and
we
need
to
once
a
while
test
the
plan,
for
example,
once
a
year.
We
need
to
test
this
plan.
A
A
And
additional
things
in
exit
strategy,
we
have
three
main
exit
plans.
First,
exit
plan
is
shut
down
the
system,
but
if
you,
if
you
have
the
important
input
in
critical
assistive
process
functionality,
we
can
shut
down,
but
the
second
main
strategy
is
to
migrate
from
one
cloud
provider
to
the
cloud
provider.
A
It's
okay
and
the
third
one
is
migrate
from
cloud
provider
to
on-premise
to
private
cloud.
That's
why
most
of
the
mostly
of
the
banks.
They
use
the
multi-cloud
approach,
so
they
want
to
have
more
than
one
cloud
provider
and
build
cloud
private
cloud
because
we
need
to
know
we
need
to.
We
need
to
have
tools
where
we
can
migrate
our
system
from
this
cloud
provider
all
right.
This
is
the
first
part
of
my
talk
about
it's
more
about
theoretical
and
introduction
to
this.
A
Of
course,
we
should
start
from
governance.
We
should
have
some
governance.
We
maybe
we
should
create
some
team,
for
example,
cloud
center
of
excellence,
which
the
team
provides
the
private
best
practices
they
they
share
the
knowledge
they
they
promote.
The
op
using
the
open
source,
promoting
the
using
vendor
neutral
tools,
and
the
team
will
help
during
the
risk
assessment
we
have
during
creating
exit
plan.
This
is
not
tool
and
sorry
the
team.
Of
course
the
team
will
help
during
the
creating
a
risk,
analysis
and
exit
plan.
A
In
couple
of
next
slide,
I
will
talk
about
reference
architecture.
What
I
imagine
of
the
cloud
native
and
how
I
prom
I
promote.
I
will
focus
only
on
design
and
development,
not
only
from
design
development
perspective,
but
only
but
on
operation,
infrastructure,
provisioning
as
well,
but
we'll
start
from
the
design
of
the
system.
A
Cloud
native
architecture
is
micro,
service
architecture,
in
short,
words,
yeah,
clean
good
micro
service
architecture,
according
to
best
practices,
12
factor
books,
some
human
swim
bugs
some
human
books,
blog
martin,
fowler
and
so
on,
and
this
architecture
is
built
from
distributed
as
from
distributed
set
of
small
services
independent
and
the
most
important
loosely
coupled
services,
which
will
this
these
characters.
This
characteristic
will
use
on
the
we'll
use
on
the
next
slide.
A
Normally,
when
we
design
the
architecture
of
the
new
system,
we
need
to
design
a
new
system
where
we
need
to
design
immigration
to
the
public
to
the
public
cloud
we
need
to
use.
We
we
have
thousands
of
thousands
of
requirements,
non-functional
functional
requirements
in
case
of
regulated
environment,
financial
institution,
european
union.
We
have
additional
sources
of
requirements
from
the
guidelines
from
the
authorities.
A
The
first
is
risk
analysis
risk
assessment.
As
the
output
of
risk
assessment,
we
we
got
risk
which
we
need
to
mitigate
by
proper
design
by
proper
design
of
application,
proper
design
of
infrastructure
risk
analysis.
Let's
imagine
this
is
a
very
big
excel
with
a
lot
of
rows
and
every
row
is
connected
with,
for
example,
with
with
some
risk,
with
some
character
characteristic
with
of
of
the
system.
For
example,
thanks
to
this
risk
assessment,
we
know
that
the
system
will
process
legally
protected
data.
A
So
to
simplify
thanks
to
it.
We
know
which
part
of
the
system
we
need
to
have
exit
plan,
because
we
need
to
have
this
one.
Only
for
important,
critical
function
and
exit
must
be,
of
course,
easy
to
carry
out
because
it
will
be
repeated
once
a
while
and
it
is
additional
cost
for
us
for
for
id
company
for
itit
department.
A
And
the
characteristic
of
micro
services
are
very
helpful
to
achieving
this
plan
because
we
we,
we
know
that
for
this
system
we
we
need
to
have
exit
plan,
but
not
for
everything,
not
every
part
of
the
system
microservices
bit
from
the
set
from
the
domains
from
this
boundary
context
from
the
set
of
the
if
you're,
using
the
domain
driven
design.
Of
course
pattern.
You
have
set
of
a
set
of
concept
of
microservices
and
we
split
the
problem
of
having
exit
plan
to
to
domain
level,
and
next
we
can
split
this
problem
on
micro
service
level.
A
A
So
to
you
to
to
or
to
I
like,
simplifying
things
so
to
under,
simplify,
let's
say
for
micro
services
that
implements
critical
functionality.
Thanks
to
that,
we
have
domain
driven
design.
We
have
the
boundary
context
we
can
find,
which
micro
service,
which
we,
which
collection
of
micro
service,
are
important
for
us
for,
is
critical,
so
for
for
this
micro
service,
this
micro
service
should
be
cloud
agnostic.
A
That's
it
for
rest
of
them.
We
can
think
about
if
we
need
it
or
we
don't
need
it
in
the
after,
we
execute
the
exit
plan.
That's
why
I
recommend
to
use
feature
toggles
pattern
to
to
to
switch
off
functionality
which
are
not
important
and
we
don't
have
expand
for
them.
Thanks
to
we
can't
in
control
way
we
can
switch
off
this
functionality
and
migrate
the
system
to
migrate
the
system
to
another
cloud
provider
or
migrate
to
the
on-premise.
A
Another
pattern
which
can
use
is
circuit
breaker.
Thanks
to
it,
we
improve
the
resiliency
of
the
whole
system
of
from
the
individual
failures
of
the
service
microservice
in
nature
micro
service
architecture.
Is
that
one
if
one
service
go
down,
the
system
should
work,
but
without
some
part
of
the
system
the
system
should
work
properly
in
general
way,
but
before
without
some
some
part
of
the
system
without
some
functionality.
So
this
is
let's
imagine
that
this
is
the
this
the
exit
plan.
We
switch
off
part
of
the
system
because
we
can,
because
it's
micro
services.
A
This
is
the
same,
the
same.
What
cows
monkeys
does
cows
monkey
switch
terminates
some
pots
terminates
services
and
they
check
that
if
the
system
goes
down
or
not
whole
system.
So
I
think
this.
These
three
patterns
cause
monkey
secret,
breaker
and
future
toggles
is
very
useful
for,
for
this
case,
for
cloud
native
for
some
for
using
in
financial
institution
when
we
have
to
exit
plan
which
are
cheap,
we
are
easy
to
execute,
and
another
advantage
of
this
is
that
you
can
use
cloud
specific
features.
A
Thanks
to
thanks
to
it,
you
can
use
this
cloud
specific
features
ready
to
use
services.
You
can
decrease
the
time
to
market,
you
can
improve
quality
of
services,
but
if
you,
of
course,
you
need
to
you
need
to
verify
this
idea
with
the
business
owners,
which
is
important,
which
function
is
important
or
which
not
is
which
isn't
important
all
right.
A
Now
we
should
some
somewhere
built
infrastructure.
We
need
to
build
built
infrastructure
when
we,
where
we
run
this
application
for
us,
it's
important
to
use
one
common
way
to
build
infrastructure
in
different
clouds
and
the
most
important
things
is
to
use
declarative
and
immutable
way
of
building
infrastructure,
so
using
infrastructure
infrastructure
as
a
code
is
the
key.
I
think
we
have
here,
because,
thanks
to
thanks
to
this,
that
we
we
have
the
infrastructure
of
the
code,
we
can
we
can
basing
on
this
we
can
create.
A
A
A
A
A
A
A
And
but
there
is
something
we
need
to
to
check,
because
not
every
distribution
of
kubernetes
are
the
same.
So
we
need
to
check
if
this
distribution
is,
distribution
is
certified.
So
cncf
is
another
place
where
cncf
help
us
is
they
certified
distribution
of
kubernetes?
Currently
we
have
more
than
90
1935
distribution
of
kubernetes,
which
we
can
use
thanks
to
it,
we
can
use
almost
in
the
same
in
the
same
way
across
the
providers
across
the
providers.
A
Observability
we
cannot
forget
about
observability.
Observability
is
the
base
fundament
of
running
microservice
in
running
microservice
and
in
the
cloud
native
when
we
think
about
the
multi-cloud
approach
and
thinking
about
the
exit
plan
and
thinking
about
regulated
environments,
we
should
find
the
common
set
of
tools
of
observability
which
can
use
independent
on
the
places.
So
we
are
recommended
to
use
the
promotions
victoria
messages
when
the
and
thanks
to
it
our
monitoring
teams,
they
can
use
the
same
tools.
They
can
use
the
same
alerts
across
the
providers
across
the
cloud.
A
Another
part
is
provisioning
of
application,
provisional
application,
provisioning
configuration
to
the
cluster
to
the
kubernetes
cluster.
We
have,
we
have
two
good
tools,
we
have
flux
and
argo
cd,
you
can
use
and
thanks
to
these
tools,
the
declarative
tools
according
which
are
compliant
with
open
git,
tops
principles.
We
can
easy
to.
You
can
easily
deploy
to
one
cloud,
another
cloud
and
executing
the
exit
plan,
because
the
process
of
provisioning
will
be
the
same.
So
the
execution
of
the
exit
plan
will
be
standard.
Standard
deployment
as
standard
deployment
will
be
standard
deployment.
A
B
Mic
check
one
two,
one:
two
hi,
everyone,
sorry
yeah.
My
question
was
the
yeah,
so
I
work
also
at
a
bank
and
we
do
very
similar
stuff
so
and
we
find
it
really
good,
but
we
don't
do
multi-cloud.
So
I'm
interested
into
the
advantages
that
you
found
of
multi-cloud
stuff
and
how
easy
you
found
working
with
like
a
lot
of
the
terraform
infrastructure
and
things
trying
to
build
with
multi-cloud,
essentially
over
just
dealing
with
a
single
provider.
A
Mm-Hmm,
oh
okay,
yeah
interesting
question.
I
think
the
the
biggest
advantage
is
that
if
we
have
the
multi-cloud,
we
can
use
specific
features
of
the
cloud.
What
is
the
best
on
the
public
cloud
in
gcp?
We
have,
for
example,
speech
for
text
is
the
best.
Maybe
I
don't
know
in
idbos
we
have
serverless
in
azure.
A
C
B
C
What
are
your
thoughts
around
the
scroll
of
tool
sets
that
were
seen
within
financial
customers?
So
if
you
just
think
about
the
kind
of
basic
automation
like
you've
got
ansbole
chef,
terraform
salt-
that's
how
it's
there
then
you
start
to
lay
on
you
said:
choose
your
own
like
kind
of
observability
tools,
there's
lots
of
them
out
there
and
each
kind
of
silo
team
starts
to
bring
their
own
and
the
apis,
make
it
easy
for
them
to
integrate
their
own,
but
everyone's
creating
their
own
mini
snowflakes.
C
A
Ansible
is
is
all
right,
but
it's
cast.
This
is
configuration
management
system.
I
I
don't
like
it
because
it's
not
declarative,
it's
not
immutable.
So
we
try
to
not
using
something
like
that,
because,
because
this
is
mutable
and
it's
not
the
criteria
to
switch
to
another
cloud,
you
need
to
rewrite
every
every
all
the
processing
I
see
playbooks
and
so
on.
A
But
I
think
we'll
really
have
this
in
the
future,
because
it's
very
good
tools,
but
we
try
to
not
using
these
tools
because
we
need
to
be,
as
as
we
can
to
be
agnostic
and
keep
everything
in
the
code
and
automation
is
the
like
in
the
development
we
have
api
first
approach
here.
We
should
have
automation,
first
approach
and
declarative
according
to
open
github's
principle,.
D
A
D
A
E
The
the
question
I
had
was
for
risk
assessment.
The
risk
assessments
that
you
do
is
do
you
keep
that?
Do
you
do
them
with
a
specific
compliance
framework
in
mind
and
then
question
number
two:
how
do
you
do
the
risk
assessment?
Just
do
you
have
a
risk
registry
that
you
maintain
you
know
throughout
the
bank
and
then
is
that
is
that
expressed
in
some
sort
of
machine,
readable
format
like
oscal.
A
About
the
risk
assessment
we
have,
we
do
it,
we
done
it
together,
we
done
according
to
eso
something
I
don't
I'm
not
the
expert
in
this,
but,
according
some
framework
to
risk
assessment,
we
have
the.
Of
course
we
have
the
teams,
compliance
teams
which
and
security
team
they
provide
for
us
this
assessment.
We,
this
is
quite
complex
things
because
we
need
to.
D
F
You
I
have
a
question:
what
is
your
cloud
maturity
and
how
much
do
you
have
your
products
in
the
cloud
in
this
multi-cloud
system
and
how
many
like?
What
is
your
development
team
and
operations,
team
or
cloud
teams?
There
are
what
is
a
team
size
and
the
last
question.
Sorry
there
are
so
many
last
question
is
there
must
be
also
a
lot
of
these
cloud,
specific
infrastructure
resources
that
are
maybe
not
so
easy
to
manage,
with
your
terraform
scripts
and
so
on.
How
do
you
do
that.
A
Currently
in
mbank,
we
are
building
landings
only
in
two
cloud
providers
and
we
have
several
applications
in
the
one
cloud
and
we
have
several
applications
in
the
cloud
private
cloud
and
we
try
to
and
we
are
building
applications
in
agnostic
way
that
we
can
deploy
application
to
the
public
cloud
and
the
private
cloud
on
using
the
same
tools
we're
using
the
same.
The
same
way.
That's
why
using
the
observability
is
the
same.
The
same.
We
are
using
the
same
tools.
A
I
don't
know
how
many
developers
we
have,
but
I
think
it's
600
600
600
developers,
it's
quite
a
big
company
and
my
previous
I
work
before
bank.
I
work
for
insurance
companies,
the
same
regulation
we
have
and
we
have
application
in
the
multi-cloud
in
gcp
and
azure,
and
we
set
up
everything
from
terraform,
but.
A
But
terraform
is
different,
the
script
is
different,
and
so
there
is
not.
This
only
tool
is
the
same
about
the
cloud
center
of
excellence.
The
team
has
77
person
is
cross-disciplined
person
because
the
supreme
members
and
we
have
dedicated
team
for
compliance
team
which
they
handle
the
contract,
things
risk
assessment,
subjects
and
so
on.
These
are,
I
think,
maybe
20
person
is
involved
in
this.
G
A
It's
we
are
using
a
lot
of
policy
how
this
work.
This
works
a
lot
of
policy,
for
example
in
azure
policy.
We
have
policy
that
we
need
to
we
ab.
We
can
set
up
the
resources
only
in
two
regions
for
the
north,
europe
and
west
europe.
That's
why
we
we.
We
are
sure
that
we're
using
only
this
region
in
the
in
the
cloud
by
policy.
H
A
The
next
next,
the
next
subject,
the
next
phase
of
our
development,
will
be
using
this
of
open
service
mesh,
because,
thanks
to
it,
we
can,
we
will
have
always
we
have
encryption
in
transit,
always
because
without
open
service
mesh
is
hard
to
to
achieve
in
the
cluster.
With
in
the
encryption
encryption
traffic
between
the
bots,
so
we
will
implement
this
phase.
The
next
one
with
compressors.