►
From YouTube: How ABN AMRO Switched Cloud Providers Without Anyone Noticing - Mike Ryan & Laura Rehorst
Description
Don’t miss out! Join us at our upcoming events: EnvoyCon Virtual on October 15 and KubeCon + CloudNativeCon North America 2020 Virtual from November 17-20. Learn more at https://kubecon.io. The conferences feature presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
How ABN AMRO Switched Cloud Providers Without Anyone Noticing - Mike Ryan, backtothelab.io & Laura Rehorst, ABN AMRO
People often talk about being cloud agnostic, but what actually happens when an enterprise with 3000 developers decides to switch cloud providers? In this session Laura Rehorst (Product Owner, Stratus, ABN AMRO) and Mike Ryan (DevOps Consultant) will share the story of how ABN AMRO leveraged the power of Kubernetes to facilitate the transition between cloud providers, and explore the strategic benefits of adopting a cloud native posture at all levels of the organisation. Laura and Mike will also delve into the practical side to demonstrate how tools such as Helm, OPA, and custom operators allowed the platform team to abstract away the differences between cloud providers, and the “compliant by default” approach that keeps their security and compliance teams smiling.
https://www.abnamro.com/
http://backtothelab.io/
https://sched.co/Zetm
A
Hi
all
welcome
to
our
talk.
We
are
happy
to
well
I've
presented
last
year
about
how
we
moved
with
ap
number
bank
towards
clouds
by
using
containers
and
this
year
we're
happy
that
we
can
present
again
at
this
awesome
event,
and
we
would
like
to
share
a
story
about
how
abby
and
aerobank
switch
cloud
providers
without
anyone
noticing.
A
So,
in
the
background
of
my
slide,
you
see
a
beautiful
landscape
with
clouds
and
a
reflection
and
looks
all
very
peaceful,
and
this
is
actually
what
you
hope
for
when
you're
about
to
switch
clouds,
that
the
one
cloud
and
the
reflective
cloud
look
more
or
less
the
same.
So
at
abn
amro
bank
we
switched
from
aws
towards
azure
as
a
target
platform
and
well
we
can
say
that
in
practice
the
reflection
might
look
a
little
bit
different
than
the
original
pager.
A
Before
we
dive
into
details
of
switching
clouds,
I
think
it's
important
that
you
know
some
background
of
what
a
b
number
bank
is.
We
are
the
third
largest
bank
in
the
netherlands
and
we
are
active
in
the
financial
sector
and
when
you're
active
in
a
financial
sector,
you're
active
in
a
highly
regulated
sector.
So
there
are
a
lot
of
restrictions
you
have
to
deal
with.
You
have
to
deal
with
auditors.
A
A
Another
challenge
that
we
have
is
that
we
have
twenty
thousand
three
plus
employees,
so
we
are
quite
a
big
organization
and
well
as
a
bank,
we
already
exist
for
a
couple
of
hundred
years
and
we
started
well,
of
course,
not
started,
but
we
are
right
now.
A
lot
of
our
applications
are
on
on-prem
on
physical
data
centers
and
at
a
certain
point
in
time,
the
bank
made
the
decision
to
move
towards
cloud
full
of
cloud-first
strategy,
where
you
can
imagine
that
that
has
a
big
impact
not
only
on
the
application
but
also
the
teams.
A
A
Why
would
you
actually
have
a
dedicated
team,
so
I
will
explain
to
you
the
vision
and
division,
let's
say
slides
okay,
so
we
are
building
a
solid
container
platform.
Why
would
the
team
not
do
it
himself?
Well,
if
you
have
about
600
teams
that
want
to
use
containers
and
everyone
would
need
to
build
their
own
mini
container
platform,
it
would
become
unmanageable
as
a
company.
A
You
cannot
control
it
and
there
will
be
a
lot
of
reinventing
the
wheel
and
that's
something
you
don't
want,
because
then
teams
are
wasting
the
time
the
valuable
time.
So
therefore,
that
would
be
good
if
one
team
would
build
a
strong
foundation
where
the
other
teams
can
build.
On
top
of
that
also,
we
are
responsible
for
lifecycle
management,
so
the
container
platform
I
just
mentioned
exists
of
a
lot
of
components
and
they
need
to
be
upgraded
and
patched
so
that
we
take
care
of.
A
A
A
A
So
this
is
the
component
overview
I
mentioned.
So
when
we
started,
we
first
went
to
the
drawing
table
and
created
the
capability
overview.
So
what
capabilities
were
needed
by
teams
is
to
start
using
containers,
so
we
used
the
cncf
landscape
as
the
model,
and
then
we
started
filling
in
the
tools
to
fit
this
capabilities,
and
there
we
made
a
decision
that
our
approach
would
be
to
be
as
cloud
agnostic
as
possible,
because
what
that
would
help
us
if
we
need
to
build
it
from
both
clouds.
A
A
You
need
to
do
proof
of
concepts,
make
a
decision
and
implement
it
and
yeah.
We
did
not
have
five
years
for
building
this
platform
now
it
should
be
done
in
one
year,
so
we
needed
to
be
a
bit
more
pragmatic
and
therefore
we
decided
to
also
look
into
the
cloud
native
services
just
to
see
where
we
can
speed
up
and
see
if
the
solution
would
be
good
enough.
So
there
you
see
also
some
examples
in
this
picture
quickly
going
through
it
on
the
left,
you
see
helm.
A
A
We
use
kubernetes
as
an
engine
of
the
platform
and
there
we
use
the
managed
services,
the
native
services,
eks
and
a-gas
on
aws
and
azure.
We
use
nginx
as
an
ingress
controller
for
layer,
4
and
layer.
7..
Persistent
storage
is
being
filled
with
native
services,
azure
file,
storage
and
elastic
file,
storage,
container
runtime.
We
use
at
the
moment
docker,
but
yeah.
We
use
the
standards
so
that
can
easily
be
replaced
by,
for
example,
container
d.
A
We
use
for
networking
the
cloud
native
services
called
cni.
Theraform
is
used
for
infrastructure
as
code
for
artifact
registry.
We
use
the
native
services
acr
and
ecr
to
capture
our
helm,
charts
and
our
docker
images,
but
on
the
background
nexus
is
running
and
that
is
actually
our
golden
source.
So
both
other
registries
are
connected
to
that
golden
source.
A
Then,
on
the
right,
we
have
a
lot
of
security
features,
so
prismacloud
compute,
previously
known
as
twist
stock.
We
use
for
scanning
our
containers
both
on
build
and
runtime.
We
use
oppa
open
policy
agent
to
implement
and
enforce
policies
on
clusters.
We
use
harshikorp
fold
for
sequence
management
and
on
the
right
for
logging
and
monitoring.
We
also
use
the
native
services
so
and
then
a
company
makes
a
decision
to
move
from
one
cloud
to
the
other.
A
So
if
you
then
introduce
a
new
platform
azure,
then
you
either
have
to
tell
them
to
stop
working
on
what
they're
now
doing,
because
otherwise
they
will
need
to
rebuild
a
lot
later
on
and
yeah.
That
would,
of
course,
be
a
lot
of
extra
wasted
time,
but
in
real
life
you
cannot
tell
teams
to
just
stop
doing
what
they're
doing
and
let
them
wait
until
you
finish
the
platform.
A
A
B
Hello,
virtual
coupon
people.
I
hope
you
liked
our
very
smooth
social
distancing,
presentation,
handover
yeah,
so
I'm
one
of
the
engineers
in
the
stratos
team
helping
to
build
out
the
cloud
native
platform.
Now
this
is
a
very
high
level
overview
of
one
of
our
deployment
pipelines.
Please
don't
worry
about
looking
at
the
details.
The
idea
is
that
this
is
a
10
000
feet
overview.
B
This
is
the
pipeline
we
created
for
delivering
helm-based
applications
on
aws,
our
customer
teams
use
helm
for
delivering
their
applications
and
stratus
uses
helm
internally
for
delivering
the
components
of
the
platform.
So
this
pipeline
represents
us
building
a
helm,
chart
delivering
it
to
a
kubernetes
cluster
in
a
development
environment,
performing
some
integration
tests,
promoting
it
to
an
acceptance
environment
performing
some.
B
Then
finally,
releasing
a
final
version
of
the
helm
chart.
We
when
we
started
building
this,
we
knew
we
would
first
target
aws,
but
multi-cloud
was
always
in
our
strategy,
so
we
knew
we
would
have
to
go
to
azure.
At
some
point
we
just
decided
to
do
aws
first,
because
we
had
this
mentality
from
the
beginning.
We
were
thinking
very
high
level
components
of
what
we
are.
B
Thinking
about
specific
cloud
provider
tools
and
how
to
use
them.
So
we
came
up
with
this
very
high
level
design
and
we're
now
going
to
play
a
game
and
spot
the
difference
and
look
at
our
same
pipeline
on
azure
just
go
back
and
let
everyone
have
a
chance
to
see
the
differences
here,
yeah
so
you've
probably
noticed
they
are
actually
the
same
image,
and
that
was
a
conscious
design
decision
we
made
from
the
beginning
by
thinking.
B
In
these
terms
of
high
level
functions,
we
we
could
compose
them
together
in
a
way
that
would
work
across
both
clouds.
So
when
it
came
time
to
implement
this
delivery
pipeline
on
azure,
we
were
using
azure
devops
instead
of
code
build
or
code
commit,
and
we
were
using,
we
were
delivering
to
an
aks
cluster
rather
than
to
an
eks
cluster.
But
fundamentally
the
pipeline's
purpose
and
consumption
remains
the
same.
So
for
our
developers
we
could
give
them
the
same
pipeline,
whether
they're
on
aws
or
azure,
and
things
pretty
much
work
exactly
the
same.
A
B
Places
where
we
didn't
necessarily
follow
that
and
why
so
here
is
an
example
of
one
of
the
an
excerpt
from
one
of
the
pipelines
we
use
when
we
deliver
an
application
to
a
kubernetes
cluster,
we
apply
some
oppa
policies
and
opa
is
running
inside
our
kubernetes
cluster.
The
pipeline
will
reach
out
to
the
target
cluster
oppa
will
validate
what
is
about
to
be
deployed,
and
then
it
will
either
be
accepted,
or
if
it
breaks
compliance
rules,
it
will
be
rejected.
A
B
Look
at
the
same
side
on
azure,
you
see
conceptually
it's
exactly
the
same.
We
have
oppa
running
inside
our
kubernetes
cluster.
The
pipeline
calls
out
to
oprah
and
everything
continues
working
the
same.
So
from
the
perspective
of
our
compliance
team.
It
doesn't
really
matter
what
cloud
they're
on.
We
know
that
this
rule
set
will
be
applied
by
pipeline.
B
Look
at
the
actual
rules,
so
this
is
an
example
of
the
rule.
We
apply
for
checking
load,
balance
policies
on
aws
as
a
bank.
We
do
not
want
developers
creating
internet
facing
load
balances
for
pretty
obvious
reasons.
So
one
of
the
things
we
do
is
block
the
creation
of
public-facing
internet
load
balancers.
B
This
error
message
you
see
here
refers
to
a
specific
control
which
has
meaning
within
abn
amro.
So
if
somebody
sees
this
error
message,
they
can
go
into
a
central
information
repository
and
look
up.
What
does
this
rule
code
actually
mean?
How
do
I
mitigate
it?
Why
is
it
here
and
so
on?
So
if
the
developer
tries
to
deploy
something
that
is
non-compliant,
we
will
fail
the
deployment
and
give
them
a
very
descriptive
error
message
of
why
we've
blocked
it,
so
they
can
go
and
figure
out
how
to
get
themselves
unblocked.
B
B
B
So
we
are
able
to
take
the
same
compliance
checking
approach
on
either
cloud
and
the
only
difference
is
the
annotation
that
we're
checking.
So
this
lets
us
use
the
same
compliance
code
base
across
both
clouds,
which
obviously
keeps
the
security
teams
very
happy.
We
could
even
take
this
further.
The
open
language
rego
is
very
powerful,
so
we
could
modulate
modularize
this
further,
such
that
we
have
one
policy
and
the
policy
engine
knows
which
cloud
it's
on
and
then
checks
for
the
right
tag.
A
B
This
mounts
a
container
mounts
a
volume
into
their
container,
and
then
they
can
just
access
it
from
their
application,
as
if
it
were
local
storage
and
now,
on
the
azure
side,
we
have
something
slightly
different,
which
is
the
azure
file
system
controller,
the
provision,
sorry
from
an
application
perspective.
These
are
the
same.
You
have
a
mounted
volume
which
your
container
can
access
application
can
go
to
its
thing,
everyone's
happy
when
it
comes
to
deploying
this.
There
are
some
slight
differences.
B
B
We
decided
to
stick
with
the
cloud
specific
solutions,
rather
than
picking
up
a
cloud
agnostic,
storage
solution.
It
had
been
on
our
roadmap
to
evaluate
cloud
agnostic,
storage
solutions,
but
as
the
organization
took,
the
decision
that
all
new
workloads
and
the
majority
of
existing
workloads
would
be
shifted
to
azure,
it
was
suddenly
less
important
for
us
to
have
a
cloud
agnostic
solution.
B
The
first
one
is
no
matter
how
wonderful
kubernetes
is,
and
it
is
very,
very
wonderful.
It
is
not
magical.
You
will
need
to
do
some
work
to
get
things
working
across
cloud.
You
won't
be
able
to
just
lift
and
shift
something
from
azure
to
aws,
or
vice
versa,
without
spending
a
ridiculous
amount
of
time
in
building
your
own
abstraction
layers,
which
is
not
really
a
good
return
on
investment
for
us.
B
In
the
cloud
native
landscape,
many
of
them
all
perform
their
goal,
and
some
people
have
different
opinions
about
others.
We
needed
to
really
just
be
pragmatic
and
think
what
do
our
teams
need?
What
is
the
best
way?
Most
sustainable,
maintainable
scalable
way
for
us
to
meet
those
goals
without
getting
hung
up
on
technology
choices.
B
The
final
lesson
is
one
I
believe
we
mentioned
in
our
last
one,
but
it's
worth
repeating
ultimate
from
the
start.
We
did
a
lot
of
automation
from
the
beginning,
but
not
100
percent,
aiming
for
100
automation.
It's
like
aiming
for
100
coverage
on
your
test
results,
it's
a
a
laudable
goal,
but
you
get
diminishing
returns
as
you
get
there.
B
However,
we
did
realize
that
we
may
be
a
little
bit
too
far
on
the
side
of
manual
things.
Despite
having
lots
of
automation,
we
still
had
a
few
things
around
testing,
which
were
manual
and
over
time.
The
cost
of
doing
those
manually
started
to
add
up.
So
with
hindsight
we
could
have.
We
could
have
better
automated
those,
but
that's
always
going
to
be
a
balance
when
doing
something
like
this.
B
B
B
And
so
one
of
the
questions
that
came
through
I'll
answer,
this
verbally
is:
how
did
we
decide
to
move
to
azure
and
do
we
have
any
guarantees
about
where
data
is
stored?
The
decision
to
move
to
azure
was
a
strategic
decision
taken
the
higher
levels
of
the
company
and
we
have
data
storage,
we'll
all
be
within
the
eu.
So
we're
not
sending
data
to
the
us.
B
B
Why
did
you
choose
azure
for
your
go-to
cloud
provider
and
not
staying
with
aws
or
migrating
to
gce?
Azure
and
aws
were
already
always
target
platforms.
Gce
hadn't
really
been
on
the
radar,
so
it
wasn't
really
a
potential
contender
when
we
were
deciding
to
switch,
and
as
mentioned
this
was
a
management
decision
to
go
towards
azure,
so
yeah
it
sort
of
came
down,
then
we
needed
to
implement
it
the
best
way
we.
B
A
B
Okay-
and
the
next
question
is
using
your
container
platform:
are
you
still
able
to
leverage
cloud
specific
sas
offerings
or
are
you
building
everything
on
top
of
is
vms,
perhaps
aks
eks?
We
try
and
be
pragmatic
here.
If
the
cloud
provider
offers
a
service
that
does
what
we
need,
then
we
do
not
want
to
rebuild
that.
The
whole
purpose
of
our
team
is
to
prevent
other
teams
from
reinventing
wheels.
So
if
we
are
then
going
to
go
and
invent
our
own
wheels,
it's
pretty
hypocritical
and
undoes
the
benefits.
B
So
we
make
great
use
of
the
cloud
provider
services
so,
for
example,
the
basic
ones
being
storage.
We
use
a
lot
of
that
where
we
just
plug
into
dom
storage,
but
also
sas
application
level
things
if
they
do
the
job
well,
if
they
fit
our
needs,
then
we're
not
going
to
build
something
and
run
it
ourselves,
just
to
say
that
we
have.
B
Okay,
the
next
question
is:
did
the
teams
have
to
migrate
from
aws
to
azure,
or
did
you
just
do
that
transparently
aka?
How
did
they
know
about
it,
or
is
it
all
abstracted
away?
So
last
year
we
gave
a
talk
called
from
cobalt
to
kubernetes
kubernetes,
and
we
had
a
complaint
that
there
was
no
cobalt
code
examples
and
I
have
to
confess
we
told
a
little
lie
in
our
presentation
title.
Some
people
noticed
that
we
switched
file
providers
and
yeah.
We
practice
a
setup
of
devops
teams.
B
So
it's
up
to
the
devops
team
to
migrate
to
the
new
cloud.
Our
job
was
to
facilitate
that
as
much
as
possible
and
to
make
sure
that
the
environment
they
were
landing
on
in
azure
was
as
similar
as
possible
to
the
environment
they
left
on
aws
and
to
try
and
do
as
many
things
we
could
to
ease
that
journey
so,
for
example,
providing
the
same
compliance,
tooling
file,
storage
connections
and
so
on
that
they
were
used
to
on
aws.
B
So
there
was
still
some
work
involved
for
the
teams
and
especially
if
they
were
using
cloud
provider
services.
So
if
they
were
using
s3
on
aws,
they
had
to
rework
their
applications
to
get
it
working
on
azure.
But
if
they
were
just
using
dumb
storage
attached
to
the
container,
then
there
was
no
rework
required,
so
it
really
varied
on
a
case-by-case
basis.
B
A
B
B
When
people
are
building
on
containers
and
vms,
they
tend
to
deploy
more
frequently
more
quickly
and
less
painfully,
and
we
see
the
industry
moving
towards
containers
rather
than
vms,
so
we
don't
really
want
to
be
stuck
in
vm
land.
When
everyone
has
moved
to
containers,
we
also
find
them.
Frankly,
speaking
for
myself
personally
here,
I
find
vms
quite
a
pain
to
use,
sometimes
when
I'm
doing
development
of
infrastructural
things,
because
there's
lots
of
waiting
time
with
containers,
I
can
spin
up
and
scale
up
a
lot
more
quickly.