►
From YouTube: Building an Agile Platform in a Highly Regulated Industry - Fredrik Klingenberg & Jonas Samuelson
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.
Building an Agile Platform in a Highly Regulated Industry - Fredrik Klingenberg, Aurum AS & Jonas Samuelson, If Insurance
During this talk, Jonas Samuelson, Platform Engineer at If-Insurance, and Fredrik Klingenberg, Principal Software Engineer at Aurum AS, will share how If-Insurance — the leading property and casualty insurer in the Nordics — built an agile platform based on Kubernetes, Linkerd, and GitOps within the constraints of a highly regulated industry. How does a large enterprise like If-Insurance balance rapid innovation to compete with disruptive newcomers while adhering to strict security and regulatory requirements? Jonas and Fredrik will discuss If-Insurance's GitOps-based platform and application deployment engine and their tools and techniques to remake the way If-Insurance runs and manages software. This talk will cover how If's immutable platform allows them to train for disaster recovery constantly, how their entire platform was built using GitOps, and how they onboarded teams shifting from a deployment mindset to a GitOps one.
A
A
A
B
B
A
We
have
an
agenda
as
well,
we'll
kick
things
off
with
looking
at,
if,
if
insurance
very
brief
introduction
so
to
set
the
context
a
little
bit,
there
are
constraints
in
the
insurance
company
and
that
if,
of
course,
and
we'll
look
at
those
had
a
starting
point,
there
were
some
clusters
already
in
place.
If
the
insurance
company
will
look
at
what
those
starting
points
were,
and
then
we
introduced
some
principles
to
help
us
to
to
guide
us
when
building
building
a
platform.
A
B
We
give
people
the
confidence
today
to
shape
our
tomorrow.
That's
our
purpose,
but
enough
of
some
of
the
boring
figures
and
key
stats.
Let's
move
over
to
the
more
interesting
story
of
shaping
ifs
tomorrow,
so
we
face
an
ever-evolving
market
technology,
landscape
and
new
competition.
Coming
all
the
time
from
pure
tech
companies
with
little
or
no
legacy.
B
A
There
are
regulatory
requirements
that,
if
takes
obviously
very
seriously
and
that
that
sets
the
constraints
of
the
company
and
the
tech
and
how
we
move
go
about
doing
things
and
they're
the
their
other
newcomers.
Maybe
don't
have
that
legacy
applications
and
networking
requirements
that
that
it
has.
How
do
you
move
fast
to
compete
in
the
marketplace
against
those
without
losing
the
trust
that
you
have
built
up
over
several
years
with
your
customers.
B
B
B
So
the
starting
point
was
to
question
many
of
the
so-called
truth
we
have
in
the
company
today
basing
from
the
legacy
trying
to
find
new
solutions
to
to
the
some
of
the
old
issues.
Just
like
the
balancing
act
shown
in
the
previous
slide.
We
have
a
bit
of
a
balancing
act
in
implementing
the
right
level
of
security
and
finding
common
ground.
B
A
A
We
started
interviewing
the
teams
with
the
predefined
template,
systematically
gathering
data
and
and
seeing
where,
where
we
were
at
managing
some
of
the
things
that
came
out
of
those
questionnaires
was
that
managing
kubernetes
takes
a
lot
of
works.
Obviously
just
find
new
kubernetes
doesn't
cut
it
at
least
not
for
us.
Although
we
use
the
managed
kubernetes
offering
from
microsoft
called
aks,
it
takes
a
lot
of
work,
moving
from
a
aks
to
a
platform
and
that's
the
whole
point
of
kubernetes
as
well.
A
These
are
some
of
the
questions
that
we
we
asked
the
different
teams
and
it's
not
the
exhaustive
list,
but
maybe
some
of
the
more
important
ones
on-prem
connectivity
do
you
need
to
communicate
with
those
legacy
applications.
It
has
a
lot
of
not
mainframes,
maybe
but
large
applications
on-prem
that
are
very,
very
secure.
A
How
many
environments
do
you
have
we'll
come
back
to
that?
One
on
the
next
slide
and
the
number
of
environments
varied
greatly
authentication
authorization?
How
do
you
go
about
doing
that?
Monitoring,
a
big
topic,
and
the
focus
that
we
saw
quite
early
on
was
a
very
focused
on
logs,
which
is
good.
We
tried
to
push
them
gently
towards
thinking
more
about
metrics
and
scaling
on
those
going
from
event
alarm:
instant
handling
escalation
policies.
A
A
lot
of
these
concerns
were
maybe
not
that
present
in
the
current
platforms
that
already
in,
if
scaling,
if,
if
there's
natural
disasters
and
and
the
the
calls
come
flowing
in
no
pun
intended,
how
do
you
go
about
making
making
sure
that
your
application
scales,
instead
of
going
and
clicking
and
scaling
up
manually
again
security?
Paramount
for
if
it
goes
through
all
of
the
layers,
if
the
customers
can't
be
trusting,
if
in
regulators
you're
out
of
luck,
I
mentioned
the
number
of
environments.
A
You
have
staging
you
have
this
batch
way
of
thinking
that
that
you
have
qas
and
then
qas
of
the
qas
before
going
out
to
production,
we,
we
post
a
friendly
challenge,
we're
not
trying
to
to
put
down
the
teams,
we're
trying
to
help
them
to
create
the
platinum
that
they
can
use
so
right
off
the
bat
we
said,
we'll
give
you
a
dev
test
and
production
environment,
and
obviously
you
get
your
own
name
space
in
those
and
try
to
think
more
in
terms
of
trunk
based
deployment.
Get
things
out
quickly.
A
A
We
got
some
a
lot
of
data
bouncing
act
between
creating
something
super
custom
for
each
individual
teams.
They
need
to
meet
us
halfway,
but
we
introduced
some
some
principles
to
help
us
to
build
the
platform
as
well.
You
go
to
the
cncf
homepage
and
you're
presented
with
with
this
low
resolution
image.
I'm
sure
you've
seen
it
before
you
heard
all
the
jokes
really
difficult
to
choose
the
correct
subset
of
the
cncf
tools.
A
This
is
not
an
exhaustive
list
of
the
principles,
but
they
were
going
through
like
a
red
thread
on
on
the
building.
On
the
time
we
want
to
have
that
guar
rails,
aka
aspect
oriented
model
where,
even
though,
if
the
team
made
the
mistakes,
they
will
gently
be
nudged
in
the
the
right
right
correction
direction
and
and
the
biggest
cost
in
application
or
system
lifetime
is
the
maintenance
part,
even
though
one
technology
would
be
easy
to
get
going
with.
A
You
look
at
this
language,
a
big
one
talking
to
the
teams.
They
could
see
things
from
different
viewpoints.
What
do
you
actually
mean
when
you
say
application?
What
do
you
mean
by
system?
We
tried
to
be
very
specific
what
our
viewpoints
were
without
letting
other
people
feel
bad
about
that,
but
be
clear
that
this
is
how
we
talk
about
these
terms.
On
a
platform
everything
has
code
goes
about
saying.
A
Okay
on
to
the
building
of
the
platform.
Obviously
I
can't
go
into
every
detail
about
building
a
platform.
We
don't
have
time
for
that,
but
one
of
the
things
we
would
start
out
with
from
the
get
go
was
to
try
to
do
git.
Ups,
everything
on
the
previous
project
that
I
worked
on.
I
had
used
git
ops
for
the
platform,
but
not
for
the
teams.
A
We
thought
it
would
be
a
good
idea
to
see.
If
could
we
do
get
ups?
Everything
have
all
of
the
state
already
try
to
build,
rebuild
the
clusters
and
we'll
go
into
the
details
on
on
orchestrating
that
this.
There
are
other
talks
that
does
the
git
ups
topic
more
service
than
I
can
do,
but
sufficient
to
say
it's
an
operating
model
that
that
we
chose
for
the
platform,
but
also
for
the
teams
that
meant
that
the
teams
needed
to
to
learn
a
new
way
of
doing
the
cd
part
of
of
delivering
software.
A
There's
a
sharp
separation
with
the
contents
integration
contents
deployment.
This
was
good
for
the
teams.
We
could
say
that
do
ca
exactly
like
you
do
it
now
only
just
push
an
image
and
we'll
do
some
small
changes
to
the
continuous
deployment
and
working
with
them,
and
then
there's
the
question
of:
where
does
the
infrastructure's
code
start
and
end?
And
where
is
the
configuration
with
git
ops
start
and
end?
A
A
We
used
the
vietnamese
sales
secret
to
seal
the
secrets.
So
now
we
can
have
all
of
the
state
inside
of
the
git
repos
and
during
the
lifetime
of
the
project,
we're
turning
into
big
customized
fans.
We're
posting
a
friendly
challenge
to
the
teams
that
were
very
held,
focused,
not
opposed
to
home,
but
some
of
the
things
that
I
see
people
introducing
helmet
you
can
actually
solve
with
customize
kind
of
hidden
gem
in
the
cncf
landscape.
I
think-
and
it's
all
over
the
part
of
we
already
have
it
so.
A
A
This
was
the
critical
part
where
you
need
that
private
key
install
it
be
sure
to
keep
that
safe,
install
the
flux
component,
and
then
we
kick
things
off
by
start
syncing
in
specific
branch
and
a
path
on
that
one
for
that
cluster
that
you're
building
again.
This
is
not
a
github
stock
but
sufficient
to
say
that
there
are
some
crds
in
the
githubs
flux
version
two.
A
So
in
this
one
we
are
syncing
in
from
a
specific
repo
and
applying
the
customize
onto
that
one,
and
we
had
the
platform
repo
consisting
of
this
and
a
lot
of
other
things
as
well.
You
have
the
the
prometheus,
you
have
the
grafana
and
other
tools,
and
then
you
have
system
syncs
as
well.
The
reason
why
we
chose
to
separate
those
were
that
we
as
a
platform
team,
can
introduce
new
technology
different
with
a
different
cadence
and
don't
messing
things
up
with
introducing
new
systems
and
the
the
system.
A
Part
here
is
where
we
introduce
the
teams
so
system,
aka,
team,
aka,
namespace,
it's
the
same
thing
and
we
can
now
onboard
those
and
do
that
with
us
again
with
the
different
cadence
that
the
other
ones
a
lot
of
cool
things
with
flux
that
made
our
life
easier.
One
of
the
things
were
the
cluster
role
that
you
see
on
the
on
the
left-hand
side
there,
the
customization
could
can
run
as
an
essay
bound
to
that
cluster
role.
Obviously,
that's
something
that
we
in
the
platform
team
control.
A
A
We
use
the
notification
controller.
This
was
a
bit
of
a
challenge
to
get
the
teams
to
embrace
the
eventual
consistency
of
kubernetes
and
and
the
notification
channel
they
could
drop
down
the
ammo.
You
could
potentially
get
some
notifications
in
a
small
amount
of
time
saying
that
hey
you
had
some
something
breaking
here.
Something
is
not
correct
and
we
have
the
the
teams
channel
for
for
each
of
the
teams
getting
that
feedback
as
quickly
as
possible.
A
Automatic
image
updates,
like
I
mentioned,
teams
channel
for
each
of
them
and
customized
dependencies,
not
to
spoil
what
I'm
going
to
talk
about
on
the
next
couple
of
slides,
but
you
sometimes
want
to
make
sure
that
that
some
components
are
already
running
in
the
cluster.
Before
you
run
everything
else,
and
with
this
customized
dependency,
you
can
say
that
these
health
checks
needs
to
be
good.
Before
you
start
applying
and
employing
other
things
for
the
teams,
they
would
have
an
application.
A
Sorry,
the
teams
would
have
many
applications.
They
would
be
in
more
of
a
microservice
architecture.
Obviously,
everybody's
doing
that.
Now
what
we
said
to
them
was
to
rip
out
all
of
that
yammel
put
that
in
that
repo,
that
we
give
you
and
we
start
sinking
in
and
we'll
be
working
with
them
closely
on
the
branching
strategy
and
the
trunk
based
model
and
and
have
everything
there.
A
This
is
quite
good
because
previously,
when
you
have
all
of
that
yaml
in
the
different
applications
repos,
whenever
you
want
to
do
some
changes
to
your
system
configuration
let's
say
you
want
to
have
some
more
cpu
memory
or
the
scaling
or
the
delta
between
application.
A
and
b
you
would
potentially
go
through
the
whole
ci
part
again
and
build
a
new
image,
whereas
here
you
can
do
those
changes
independently
of
your
application.
A
A
We
spent
quite
a
bit
of
time
on
the
branches
strategy
for
the
platform
as
well.
It's
very
important
to
emphasize
that
the
branches
were
not.
There
were
no
commits
in
test
branch,
for
example
that
were
not
in
dev
branch,
so
we
didn't
use
the
branches
to
hold
state.
In
that
sense,
we
only
use
the
branches
to
to
be
able
to
roll
things
from
dev
to
test
and
test
the
production
with
having
it.
A
A
A
A
A
We
we
we
trained
for
the
software,
for
let's
say
we
want
to
do
the
upgrade
to
new
kubernetes
version
downgrading
coming
out.
This
version
in
in
the
cloud
provider
is,
I
think,
it's
actually
impossible
if
you're
not
very
happy,
but
whereas
in
this
way
we
will
just
rebuild
the
cluster
and
train
for
that
disaster.
Recovery
from
the
start
and
we're
actually
down
to
20
minutes
or
something
like
that,
and
that's
only
due
to
the
pulling
of
the
images
and
getting
the
notes
up
and
running.
A
Obviously,
we
used
node
pools
priority
classes
to
make
sure
that
the
most
critical
applications
were
running
they're,
all
a
lot
of
all
the
tricks
as
well,
and
they
play
their
what-if.
No
pun
intended
here
as
well
to
use
separate
null
pools.
There
are
some
applications
very
memory.
Intensive
per
meters,
for
example,
keep
those
in
different
node
pools,
use
the
taint
acceleration,
keep
things
separated
think
about
these
things.
From
from
the
start,.
A
We
like
the
gatekeeper
project
and
we're
looking
forward
to
the
pod
security
standard
as
well
coming
out
shortly,
and
we
use
the
azure
policy
for
that.
But
we
wanted
to.
This
is
something
that
we
are
currently
working
on,
extending
that
even
further
to
use
those
public
pulses,
yeah
the
policies
make
sure
that
you
have
pre-ordered
the
glasses
set
and
all
of
those
things.
A
A
Okay,
that
was
already
in
place,
but
we
hear
this
question
with
different
customers
working
with
as
well
service
mesh
come
on.
Do
you
actually
need
that?
Kubernetes
has
a
lot
of
components,
it's
complex,
complex
enough
and
turns
out
that
you
probably
do
need
it.
There
are
some
questions
asked
that
some
questions
that
you
maybe
didn't
know
that
you
should
be
asking,
and
this
is
where
the
search
must
come
into
place.
A
We
had
the
the
the
two
main
questions
that
we
wanted
to
solve.
This
is
something
that
we
see
a
lot
of
people
having
you
moving
things
into
kubernetes,
where
all
that
all
of
that
communication
is
unencrypted,
we
want
to
have
it
encrypted,
and
we
also
want
that
insight.
You
want
to
get
the
insights
to
the
sockets
to
network
traffic
who's.
Talking
to
you
in
terms
of
applications,
I
gave
it
the
I
gave
it
away
a
little
bit
earlier
because
you
saw
linkedin
on
one
of
those
systems.
A
We
chose
linkedin,
it's
already
chosen.
I've
used
linkedin
other
ones
as
well:
full
disclaimer,
my
linkedin
ambassador,
so
totally
unbiased,
of
course,
but
nikkili
has
its
own
proxy
really
efficient.
I
doubt
that
istio
console
the
other
ones
would
have
been
the
issue
performance
wise,
but
we
take
everything
all
the
performance
gains
we
can
get.
A
A
The
main
thing,
although
the
encryption
is
important,
the
main
thing
that
we
got
from
from
linkedin
service
mesh
is
that
network
insight.
You
have
it
already
in
other
applications,
but
in
kubernetes
you
are
somewhat
in
the
blind
here.
We
could
see
sockets
if
the
application
should
be
are
doing
that
correctly,
reusing
those
sockets.
A
There
are
a
lot
of
other
cncf
tools
that
we
used.
I
like
to
highlight
the
thanos
project.
We
used
prometheus
operator
scraped
the
prometheus
methodics
that
we
got
from
linkid
and
and
stored
those
in
an
azure
blob.
The
idea
is
that
a
couple
of
years
from
now
we
can
see
trends
going
back
and
see.
Where
are
the
most
calls
coming
in?
A
What
kind
of
application
is
having
the
most
trouble,
and
we
also
have
kira
in
place
that
could
take
in
those
prometheus
metrics
coming
from
linkedin,
for
example,
and
do
the
automatic
scaling
again
trying
to
be
more
cloud
native,
something
that
we
saw
from
the
teens?
That
scaling
was
not
really
something
that
they
were
thinking
so
much
about,
but
we
tried
to
help
them
in
that
as
well.
B
Yeah
so
final
section
about
team
onboarding,
we
have
to
spend
time
on
onboarding
teams
in
the
company
to
introduce
some
of
the
key
concepts
around
githubs.
Of
course,
there
is
initial
thresholds
to
get
over
when
moving
from
the
push
to
pull
based
approach,
and
we
also
have
to
do
practical
setups,
sometimes
together,
like
frederick,
show,
setting
up
the
repos
and
everything
also
there's,
sometimes
a
need
to
get
used
to
get
ways
of
working,
even
with
pull
request,
reviews
and
quality
assurance,
tooling
and
stuff.
B
A
And
we've
tried
to
explain
and
pretty
much
saying
how
we
would
solve
their
concern
like
a
lot
of
times,
you're
hearing.
No,
no,
you
need
this
subnet
here.
We
need
to
separate
traffic
here
and
we
should
do
this
and
that
we
said
okay,
but
what
you're
actually
trying
to
solve
is
to
be
able
to
encrypt
traffic,
not
having
anybody,
seeing
it
trying
to
go
to
the
underlying
problem
that
they're
trying
to
solve
and
tell
them.
We
are
solving
it
as
well,
but
with
more
cloud
native
tools.
That's
that's
one
way
of
doing
it.
A
D
A
A
The
github
port,
for
example,
being
able
to
to
control
the
applications
and
scaling
automatically
was
a
pain
point
that
a
lot
of
teams
had
yeah.
The
short
answer
is
try
to
solve
the
problem
that
they
have.
Then
they
would
go
over
and
a
lot
of
teams
spent
too
much
time
on
managing
the
kubernetes
and
the
platform
part
it's
a
lot
of
tools
and
technology
to
get
into.
A
We
and
we
said
that
how
about
we
do
that
for
you
and
you
meet
us
on
halfway
embrace
the
in
this
case
the
get-off
part
and
you'll
get
automatic
encryption.
You
get
scaling,
you
get,
alarms
that
we
set
up
for
you
and
then
they're,
probably
on
board,
but
yeah
thinking
more
in
a
historic
role
with
something
a
problem.
Awesome.
E
B
F
B
A
Yeah
there
were
already
a
lot
of
security
and
firewalls
and
palo
alto
and
a5.
Everything
is
placed.
We
spent
quite
a
bit
of
time
figuring
out.
Okay,
where
can
we
put
our
kubernetes
cluster
to
still
use
the
functionality
of
those
keep
the
network
in
point
at
ease,
f5,
palo,
alto,
firewall,
awesome
products
we
didn't
want
to
replace
all
of
those,
but
finding
that
sweet
spot
is
certainly
quite
a
bit
of
time,
but.
F
A
We're
onboarding
the
team
now
units
has
more
knowledge
from
that
recently,
but
that's
that's
a
big
topic
as
well
trying
to
embrace
the
cloud
native.
Obviously,
if
you
go
for
something
that
you
have
on-prem,
one
big
monolithic,
stateful
application,
moving
out
to
a
cloud
native
landscape,
very
important,
and
you
have
to
know
more
on
system
development
as
well.
That's
something
we
try
to
to
work
with
in
the
platform
team
that
we
shouldn't
only
be
concerning
platform
inclinator
tools.
You
should
also
have
people
that
have
been
building
system
and
being
the
application
developer.
B
But
good
good
question
and
we
will
be
in
part
dependent
on
another
team,
as
you
say,
and
we're
trying
to
solve
that
in
different
ways.
And
one
of
the
ways
is
like
us,
owning
maybe
the
certificates
and
and
and
the
entries
so
that
we
can
easily
onboard
teams
and
add
them
as
entries
to
in
a
more
so
that
we
still
can
move
fast.
G
Do
your
applications,
does
the
platform
also
hold
the
data,
and
you
didn't
talk
about
stateful
cells
and
how
you
can
do
disaster
recovery
with
the
github
approach
when
you
have
drives,
and
also
how
do
people
create
databases?
Is
it
part
of
the
of
your
platform
or
they
have
to
order
them
or
offline
and
then
just
connect
them
good
question.
B
A
It
wasn't
part
of
that
yeah.
How
do
you
manage
the
data
and
especially
in
the
south
recovery
place?
Is
that
a
correct
one?
A
little
bit
of
a
cop-out?
I
would
say,
because
we
we
kept
the
state
and
the
databases
outside
once
you
introduce
all
of
that
databases
in
the
platform
stripping.
Those
doing
snapshots
of
those
more
difficult
of
sure
one
part
is
the
prometheus,
for
example,
that
has
this
this
persistent
volume
and
we
made
a
conscious
decision.
A
H
I
That's
a
cure
for
him
for
asking
questions
yeah.
I
wanted
to
ask
you
about
audits.
Do
you
have
external
audits
of
for
security
compliance
and
how
do
you
pass
them
because,
from
my
experience,
auditors,
when
they
see
this
added
complexity
of
kubernetes,
they
just
can
not
always
follow
up
all
this
complexity.
B
We
have
audits
as
an
insurance
company
and
we
yeah,
of
course
we
do
and
what
we're
going
to
show
them
if,
if
it
comes
to
it
like
who
implemented
what
changed
at
what
time?
It's
you
know
the
the
git
manifest
and
they
get
history
right.
So
we
all
have
it
there
and
that's
the
that's
the
cool
part
here
that
we
we
sort
of
have
a
tracking
backlog
of
all
the
changes
that
are
occurred
towards
the
environment,
both
from
a
system
perspective
but
and
a
platform
exp
perspective.
A
B
So,
to
mention
one
yeah
you're
totally
correct
to
start
with,
we
have
legacy
teams
and
what
we
have
also
had
legacy
java
applications
and
they
have
actually
been
the
first
movers
now
moving
from
the
java,
on-prem
sort
of
vast
environment
and
it's
been
starting
to
spin
it
up
in
containers
and
getting
the
you
know,
know-how
and
knowledge
around
that.
So
that's
actually
the
first
use
cases
we've
had
so
far
and
there
to
mention
the
amount,
I
would
say
we're
right
now,
currently
having
around
10
10
to
15
different
teams
onboarding.