►
From YouTube: An Introduction to the Financial Services User Group - Scott Surovich, HSBC & Michael Lieberman
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon North America 2021 in Los Angeles, CA from October 12-15. 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.
An Introduction to the Financial Services User Group - Scott Surovich, HSBC & Michael Lieberman
The Financial Services User Group is looking to increase collaboration with the technology community. Whether you are working in FinServ, a vendor or just interested in learning more about how financial institutions approach cloud native, come join us to find out more about the FSUG, what our goals are and how we plan to achieve them. Find out about the often unique challenges financial services organizations face in the cloud native space and how we are beginning to collaborate with the broader community including open source projects, vendors and our peers. We want to help solve the shared technology problems of financial services. FinServ has a reputation of not being open in the tech community. We hope through this introduction and the broader work of the FSUG to change that.
A
A
I
hope,
too,
by
the
end
of
this
short
presentation,
to
answer
the
following
questions:
what
are
some
of
the
challenges
financial
services
has
in
adopting
cloud
native?
Why
do
we
need
a
financial
services
user
group?
How
does
the
financial
services
user
group
differ
from
other
tech
focused
special
interest
groups?
A
A
A
A
We
also
need
to
understand
our
obligations
to
those
we
have
contracts
with,
as
well
as
the
countries
and
regions
we
operate
in.
Fincerf
organizations
also
worry
about
risk
to
the
reputation
we
have
with
vendors
and
other
partners,
because
finserv
has
many
of
these
customers.
Sorry
many
of
these
companies
as
customers.
A
There
are
also
additional
other
third
party
risks,
which
I
won't
get
into
detail
here,
given
that
many
of
our
organizations
are
large
enterprises
with
thousands,
if
not
tens
of
thousands,
if
not
hundreds
of
thousands
of
employees,
it
can
get
complicated
navigated.
Navigating
the
myriad
obligations
we
have.
A
A
This
leads
to
challenges
around
how
the
organization
defined
its
business
in
the
past
and
whether
that
is
compatible
with
how
we
adopt
cloud
native.
This
isn't
to
say,
we
won't
adopt
cloud
native
if
it
isn't
compatible
with
a
decision
we
made
in
the
past.
This
just
highlights
how
we
need
to
be
cognizant
of
these
challenges
and
also
in
how
we
might
need
to
not
just
transform
technology
in
terms
of
software
and
servers,
but
our
organizations
themselves
in
order
to
adopt
these
new
patterns
of
operating
technology.
A
Along
with
our
complex
enterprise
environments,
financial
services
companies
often
have
enormous
amounts
of
legacy
technology.
It
is
not
something
that
will
go
away
overnight
and
inevitably
our
cloud
native
footprint
will
have
to
live
alongside
our
legacy
footprint
for
a
very
long
time.
We
are
not
saying
there
should
be
an
expectation
that
will
be
that
we'll
deploy
monolith
as
containers
and
call
it
a
day.
A
It
means
that
our
cloud
native
applications
and
microservices
will
need
to
operate
and
integrate
with
our
monoliths.
Our
new
and
transform
software
will
need
to
live
alongside
these
legacy.
I.T
systems
that
have
a
long
history,
potentially
going
back
decades,
think
mainframes.
That,
though,
might
have
been
patched
and
updated
still
have
a
legacy
dating
back
40
or
50
years.
A
Financial
services
companies
have
a
lot
in
common
with
each
other
in
terms
of
many
of
the
aforementioned
challenges.
With
that
said,
our
various
organizations
have
approached
these
problems
differently
from
each
other.
In
the
past,
we
will
most
likely
continue
to
approach
these
problems
somewhat
differently
due
to
the
history
and
legacy
of
our
organizations.
A
A
I
will
now
talk
to
some
of
the
examples
of
the
challenges
from
the
previous
slide
that
highlight
why
we
need
a
financial
services
user
group.
I
can't
talk
about
some
specifics
due
to
the
both
sensitive
nature
of
some
of
the
topics,
as
well
as
individual
organizations
approaching
the
challenges
their
own
way,
data
segregation
and
security
is
a
huge
challenge
for
financial
services
organizations,
whether
it's
gdpr
or
other
laws
or
regulations.
A
Customer
data
security
is
paramount.
When
approaching
the
use
of
kubernetes
and
other
cloud
native
technologies.
We
often
approach
it
thinking
about
data
security.
First,
our
approach
to
data
security
inevitably
constrains
how
we
use
cloud-native
technologies,
given
the
enormous
footprints
many
of
our
institutions.
A
A
We
need
to
figure
out
ways
where
we
can
prove
those
best
practices
align
with
our
compliance
requirements.
It
doesn't
matter
if
we
have
fancy
automation
that
provides
policies,
code
and
layer,
7im
controls
around
access.
If
we
haven't
transformed
our
own
internal
rules
around
one-to-one,
firewall
policies
and
other
layer,
three
requirements.
A
A
similar
challenge
is
around
separation
or
segregation
of
duties
and
concerns.
This
challenge
has
multiple
parts
due
to
the
wording
and
interpretation
of
regulations,
it
leads
to
confusion
about
what
counts
as
segregation
of
duties.
A
simple
example
of
this
is
the
person
who
writes
software
can't
be
the
same
person
who
deploys
the
software
depending
on
who
you
talk
to,
that
might
need
to
be
literally
different
people
on
different
teams
or
just
different
roles.
A
A
These
bureaucracies
historically
have
involved
a
lot
of
manual
paperwork
for
everything,
from
from
procurement
of
a
physical
server
to
the
application
of
a
patch.
These
bureaucracies
need
to
be
transformed.
Cloud
native
adoption
loses
a
lot
of
its
benefits.
If
you
end
up
having
to
fill
out
a
ticket
each
time,
you
need
to
scale
up
a
kubernetes
pod,
as
cloud
native
pushes
for
the
adoption
of
newer,
architectures
and
patterns
like
microservices.
A
It
also
forces
financial
services
to
rethink
the
interface
between
business
and
technology
when
it
comes
to
compliance
and
audit
the
scope
by
which
we
define
what
a
service
an
application
is,
is
usually
too
broad
when
adopting
cloud
native
often
our
systems
are
defined
not
as
microservices
but
as
monoliths
as
mentioned
earlier.
Some
of
our
systems
are
still
in
mainframes.
A
An
application
can
be
defined
by
its
ip
address,
its
database
and
other
infrastructure
components,
whereas
with
a
microservice,
you
would
expect
it
to
be
defined
more
in
terms
of
functionality
in
adopting
patterns
like
microservices.
We
also
need
to
transform
the
processes
and
tools
by
which
we
define
what
our
systems
and
applications
are
in
the
first
place.
A
Those
of
us
in
the
financial
services
user
group
are
not
the
only
ones
who
run
into
challenges
and
adopting
the
new
technologies
and
modes
of
operating.
There
are
vendors.
We
have
years
of
history
with
that
struggle.
There
are
partners
we
integrate
technologies
with
that
are
also
behind.
In
addition,
some
of
our
fellow
financial
services
organizations,
not
just
the
ones
who
are
part
of
the
finserv
group,
are
behind
or
haven't
even
started
their
cloud
native
journey
at
all.
A
We
also
need
to
show
to
vendors
and
others
that
cloud
native
is
being
adopted
so
that
we
can
provide
incentive
for
others
who
haven't
begun
their
adoption.
Yet
none
of
the
challenges,
as
I
mentioned,
are
considered
in
a
vacuum.
We
recognize
that
kubernetes
and
other
cloud
native
tools
provide
some
primitives
for
securing
systems
and
data.
However,
the
issue
isn't
in
building
secure
apps.
A
That
leads
us
to
the
goal
of
the
financial
services
user
group.
Even
though
we
have
a
ton
of
challenges
and
specific
problems
that
exacerbate
even
our
collaboration,
we
still
are
driving
towards
reaching
our
goal
of
solving
the
shared
challenges.
Financial
services
has
in
the
adoption,
implementation
and
use
of
cloud
native
tools
and
technologies.
A
A
A
So
we
look
to
achieve
that
primary
goal
from
the
previous
slide.
Through
a
few
different
ways:
financial
services,
user
group
members
are
able
to
talk
freely
about
the
challenges
we
have
at
least
generally.
This
allows
us
to
help
each
other,
navigate
the
cncf
landscape
and
learn
about
tools,
technologies
and
approaches.
Other
members
might
not
have
considered.
A
A
Werner
vogels
from
amazon
coined
the
term
undifferentiated
heavy
lifting,
which
I
think
is
an
apt
metaphor
for
the
shared
challenges.
Many
of
us
in
finserv
have,
though
many
of
us
are
bound
to
different
compliance
requirements
from
a
regulatory
body.
There
are
still
a
lot
of
common
problems
that
are
shared
even
just
coming
together
to
collaborate
on
general
approaches
is
a
huge
help
for
us.
A
A
A
A
A
A
This
makes
it
hard
for
us
to
not
not
just
to
collaborate
with
fellow
financial
services,
user
group
members,
but
the
cncf
and
tech
community
at
large
due
to
legal
risks
and
obligations.
It
makes
it
difficult
for
many
of
us
to
take
official
stances
on
the
tools,
technologies
and
architectures
in
cloud
native.
As
mentioned
earlier.
Some
of
our
enterprises
are
enormous,
and
none
of
us
want
to
inadvertently
misrepresent
a
relationship
with
a
project
to
render
the
previously
mentioned
challenges
also
make
recording
of
the
majority
of
our
meetings
a
no-go.
A
Here
are
some
examples.
Sorry
some
example
topics
that
we've
had
roundtable
discussions,
demos
or
talks
on
kubernetes
and
other
cloud
native
tool-based.
Multi-Tenancy
is
a
huge
issue
for
financial
services,
as
our
regulatory
and
legal
requirements
mean.
We
need
to
be
careful
in
how
we
implement
data
segregation.
A
A
A
We
are
looking
at
some
projects
out
there
like
the
open
application
model
for
those
who
don't
know
what
what
the
oam
is.
It's
a
project
that
seeks
to
provide
a
platform
agnostic
specification
for
defining
what
a
cloud
native
application
is.
This
fits
in
with
our
need
to
define
a
business
level
abstraction
that
can
be
easy
that
can
easily
translate
into
cloud
native
configuration
as
code.
A
We
also
regularly
discuss
cloud
native
security
in
general
and
topics
like
supply
chain
supply
chain
security,
specifically,
as
you
can
imagine,
given
our
need
to
keep
customer
data,
and
our
intellectual
property
safe
and
secure
security
is
a
common
topic
for
us
in
our
meetings.
Supply
chain
security
is
a
good
example,
as
mentioned
earlier,
one
of
our
challenges
not
just
in
securing
our
software
and
systems,
but
in
ensuring
we
can
audit
and
prove
that
it's
secure
as
well.
A
A
We
have
multiple
potential
topics,
but
most
likely
it
will
be
focused
on
the
challenges
and
approaches
financial
services
take
in
implementing
cloud
native.
This
will
help
inform
project,
maintainers
and
vendors
on
our
high
level
requirements.
This
will
help
groups
that
haven't
worked
on
financial
services,
use
cases
or
requirements
in
the
past.
This
will
also
help
fellow
finserve
companies
that
aren't
part
of
the
fsug
or
cncf
at
all
the
more
we
communicate
our
requirements,
use
cases
and
challenges
the
more
aligned
we
will
be
to
adopting
cloud
native
and
helping
shape
the
projects
to
fit
our
needs.
A
This
includes
working
with
finos
and
potentially
government
entities
like
nist
in
maybe
setting
some
best
practices
around
adopting
already
clearly
defined
standards
like
nist,
853
and
800
190..
Doing
this
helps
our
internal
stakeholders
align
to
industry
standards
over
developing
custom
rules
for
the
next
kubecon
or
cloud
native
conference.
We
want
to
show
off
our
work
on
the
things
I
just
mentioned.
A
Obviously
we're
looking
for
other
financial
services
companies
to
join
our
meetings,
but
also
we're
looking
for
vendors
and
project
maintainers,
who
are
interested
in
you
know,
on
better
understanding
financial
services
use
cases,
so
the
meetings
happen.
The
third
tuesday
of
every
month
at
2,
30
gmt,
feel
free
to
reach
out.
If
you
want
an
invite
to
the
group,
even
though
we
still
are
looking
for
new
tools
to
help
us
collaborate,
we
currently
still
are
using
slack
github
in
google
docs.