►
From YouTube: KBE Insider Amsterdam - Sebastian Kister, Audi AG
Description
KBE Insider interviews Sebastian Kister who leads the Container Competence Center at Audi AG in the Audi RS e-tron GT he let us borrow while at KubeCon Europe! Sebastian shares his involvement within the CNCF community. We also dive into his experience with cloud native transformation and why he takes a people-first approach to scale enterprise-level transformation at Audi. Sebastian highlights why enablement is also important with transformation as it compliments his people-first approach in their cloud native transformation journey at Audi.
A
Hey
Sebastian,
you
know
thanks
so
much
for
joining
us
in
the
car
ride.
You
know
you've
already
been
in
the
car
a
bit
yourself
but
yeah.
We
but
we'll
do
our
little
tour
and
it'll
be
it'll,
be
fun.
You
can,
you
know,
do
the
Ride
Along,
but
do
you
want
to
introduce
yourself
tell
us
a
little
bit
about
who
you
are
and
and
what
you
do,
yeah.
B
Sure,
I'm
I'm
Sebastian
I
lead
the
kubernetes
competence
Center.
We
renamed
it
actually
to
contain
a
competence
and
platforms
and
I'm.
Also
today
in
the
CTO
Summit
with
the
other
end,
user,
Enterprises
and
I
do
a
transformation
evangelism,
you
could
say
so.
I
have
many
many
ideas
and
Publications
and
I
do
like
20
to
25
Keynotes
a
year
about
Enterprise
transformation
on
basically
on
people
first
processes
and
on
how
to
create
a
lasting
transformational
Force.
Rather
than
doing
some
adjustments
in
your
mailbox
signs.
A
B
Yeah
we've
been
pretty
effective.
Actually,
we've
created
the
competence
Center
four
years
ago.
We
started
out
just
three
of
us
two
engineers
and
me
they
already
built
a
proprietary
kubernetes
control,
plane,
okay
for
two
years
at
Audi,
and
you
remember
the
2019
Market.
It
was
like
super
control,
plane
hobby
with
startups,
doing
their
own
control
players
managing
kubernetes
itself
so
or
doing
an
abstraction
layer
above
cloud
provider
yeah
anyway,
this
you've
seen
it
back.
Then
the
focus
is
completely
different.
Now
control
planes
are
commodity.
B
A
Me
ask
you
a
background
question
like
like:
why
like
what?
What
was
the
driver
to
create
this
team
in
the
first
place
like
what
was
the
you
know,
what
was
the
goal?
Did
somebody
just
wake
up
one
day
and
be
like
we
need
to
modernize
somehow
or
or
was
there
like
some
business
goal
or
like
what
was
the
driver
that
started
that
transformational
event.
A
B
A
B
We
are
Consulting
other
Platforms
in
their
how
they
want
to
build
things,
how
they
want
to
create
things
what
Focus
they're
on,
if
they
run
infrastructure
platform,
or
rather
abstraction
layer,
above
it
a
business
integration
layer
with
serving
a
couple
of
managed
services
to
a
homogeneous
group
of
workloads.
For
example.
Okay,.
A
B
The
first
and
foremost
thing
of
them
all
is
a
platform
to
deploy
workloads.
Okay,
so
there's
a
focus
on
two
things:
it's
secure
runtime
that
sums
it
up
perfectly
just
security
and
runtime.
We
focus
on-
and
you
have
these-
let's
say
normal
workloads
that
don't
have
too
many
special
requests
and
they
can
all
deploy
very
easy
form
and
run
your
workloads
to
cic
data,
and
it
just
makes
sense
for
for
the
biggest
amount
of
applications
in
the
organization.
B
And
then
you
have
some
applications.
Obviously
that
have
a
very
special
use
case,
like
machine
learning,
AI
use
case
of
tremendous
amount
of
workload
Peaks
and
you
want
a
different
consumption
model
in
scalability.
Obviously,
and
maybe
they
need
a
couple
of
minutes
Services
right,
then
we
create
something
like
a
business
integration,
layer,
business
domain
services
and
we
consult
these
people
that
want
to
own
the
business
integration
layer
on
how
to
do
that
and
how
to
consume
the
infrastructure
layer.
A
I
gotcha,
okay,
so
let
me
and
I'm
not
sure,
like
I'm,
not
sure
if
you
can
entirely
get
into
this.
But
so
when
you
are
talking
about
these,
you
know
kind
of
software
teams
and
development
teams.
Are
they
mostly
like
the
stuff
that
kind
of
runs
Audi
or
is
it
the
stuff
that
actually
like
runs
in
the
cars
or
both
or
you
know,
or
is
there?
How
is
that
how's
that
division
done?
Is
it
different
kinds
of
engineering?
You
know
yeah.
B
B
Right,
yeah
yeah,
we
have
Audi,
it
has
6600
applications,
it's
quite
a
number
yeah
and
obviously
there
is
on-prem.
There
is
public
Cloud.
There
is
all
the
flavors
that
you
can
think
of
right
and
all
the
needs
all
the
requirements
that
you
can
think
of
in
any
organization
we
have
them.
We
find
them
yeah
yeah,
which
doesn't
make
our
job
easier.
A
B
B
A
A
B
We're
it's
not
kubernetes
is
not
always
the
answer,
nor
is
a
public
Cloud,
always
the
the
right
answer.
So
we
are
very
very
early
in
the
in
the
Consulting
process
for
a
project,
and
then
we
can
advise
them
on
pursue
path
on
being
successful
and
they're
actually
in
the
world.
Yet
they
want
to
create
because
the
compute
for
them
usually
is
like
they're
not
very
motivated
in
this
topic,
because
it's
just
annoying
for
them.
A
Right,
yeah,
no
I
totally
understand
so
so
you
know
you
said:
there's
six
thousand
something
plus
projects
right
yeah.
So
how
do
you?
How
do
you
do
that
transformation
like?
How
do
you
scale
your
team
of
what'd?
You
say
less
15,
something
like
that
like
to
get
to
support
that
many
different
teams.
Yeah
actually.
B
With
me,
it's
15.,
okay
yeah,
so
the
the
way
to
do
it
is
like
not
investing
too
much
energy
in
fighting
The
Silo
as
they
put
it.
It's
a
it's
a
mind-boggling
and
useless
fight.
You
can
invest
at
80
of
your
energy,
your
political
energy,
but
also
your
an
entire
day
of
work
into
talking
to
people
and
fighting
the
silos.
So
to
say
it's.
It
makes
more
sense
to
respect
yourself,
because
it's
the
way
to
organize
big
organizations
like
Enterprises.
B
We
have
87
000
people
at
Audi,
440
000
people
at
BW
group,
so
it
just
makes
real
sense
to
not
invest
too
much
energy
into
that,
rather
than
asking
why
you
would,
even
if
I
decided,
what's
the
business
value
you
want
to
take
out
of
this,
and
you
can
Define
that
quite
easily.
If
you
ask
a
couple
of
times
why
you're
doing
that
anyway,
why
is
devops
a
thing?
My
stuff,
SEC
obser
thing,
this
end-to-end
responsibility
obviously
makes
sense
in
a
wider
sense,
and
you
can
create
that
through
the
silos.
B
For
example,
transformation
usually
happens
that
people
Define
a
process
they
get
attacked
for
it.
They
decide
upon
the
tools
and
then
they
tell
the
people
what
to
do,
or
they
Define
roles,
yeah
that
fill
out
this
organizational
structure
and
then
the
higher
for
the
roads,
and
that
is
so
not
people-centric.
And
what
happens
then,
is
that
the
people
satisfy
the
process
rather
than
solve
the
problem,
because
they
don't
even
know
what
the
problem
was
right.
A
B
They
want
to
get
done
actually
right.
They
are
really
like,
maybe
passionate
about
and
their
field
of
work
in
there.
So
what
we
do
is
we
look
at
the
people
first
and
I.
Ask
my
team
always
what
you're
passionate
about
we
have
this
stuff
on
the
plate.
Pick
one
be
good
at
it
right.
I
know.
If
you're
passionate
about
it,
you
will
be
just
nailing
it.
You
will
be
really
good
at
it.
B
Usually
bleeding
edge
is
the
thing
in
our
competence,
Center,
okay
and
and
then
automated
right,
because
we're
not
too
many
people
right
right.
We
need
to
automate
stuff
to
make
it
work
and
scalable.
But
what
happened
if
you,
automated
the
tech
through
passionate
people,
is
you
you
receive
a
process,
it's
a
natural
yeah
process
that
evolves
through
the
automation
of
what
you
did
before
yeah
and
then
you
can
processualize
the
process
and
make
it
a
thing
in
your
organization
like
a
rule
right,
right
so
to
say
a
rule
to
follow.
B
B
A
Actually,
at
the
end
of
the
round,
you
know
at
a
much
smaller
scale.
You
know
it's
kind
of
what
we're
doing
like,
even
within
our
like
this
spark
program
that
we
do
all
these
software
projects
for
third
parties
is
we,
you
know
we
want
all
the
teams
to
use
GitHub,
okay,
so
the
first
thing
we
do
is
we
start
establishing
repos
for
the
students
and
when
they're
doing
the
student
teams
or
whatever
and
then
the
next
thing
we
do
is
okay.
A
B
It's
what
happens
often
is
that
people
decide
upon
a
tool
and
it
has
zero
adaption
because
nobody's
motivated
to
use
it.
But
if
you
let
the
passionate
people
like
this
10
to
20
in
every
company
that
really
are
super,
passionate
and
and
hardworking
about
solving
the
issues.
If
you
let
them
like
work
with
everybody
else
on
the
right
tools
to
solve
the
problem,
you
will
have
adaption
while
choosing
it
even
right
right.
Even
the
POC
becomes
very
quickly
adopted
and
adopted.
A
B
For
example,
my
team
is
definitely
a
silo
as
well,
because
we
are
just
responsible
for
our
infrastructure.
There
is
no
end-to-end
responsibility
towards
the
developer
and
has
problems
so
the
developer
sometimes
even
is
an
external
company.
And
then
you
have
internally
a
service
owner
service,
responsible
guy
product
owner
platform
owner
whatever
yeah.
So
you
have
a
limited
number
of
people
that
own
the
thing
and
a
completely
different
department
or
even
company.
That
creates
the
thing
and
we
have
users
as
well.
B
And
and
there's
the
infrastructure,
there's
the
the
people
that
run
stuff
infrastructure
or
that
run
applications,
and
these
are
completely
different
responsibilities
and
the
you
can
cut
responsibilities
through
creating
a
set
of
contracts
like
terms
and
conditions,
service,
level,
agreements
and
stuff.
That
is
necessary
from
a
legal
point
of
view.
We
also
do
that.
We
have
a
clear
responsibility
border
where
we
say
this
is
nothing
we
are
like.
B
B
Exactly
yeah,
and
if
you
have
these
friction
walls,
that
between
user
and
developer
between
the
orchestrator,
which
is
the
process
guide,
product
owner
and
the
infrastructure
Department,
you
have
a
couple
of
friction
boards
that
you
can
automate
through
just
automate
through
it,
I
mean
requirement.
Engineering
between
users
and
product
owner
doesn't
make
sense
and
that's
a
different
different
path,
but
from
developer
to
process
owner
or
Finance
guy
and
infrastructure.
B
That's
two
very,
very
strong
friction
walls
in
a
in
a
unilateral
way,
often,
and
then
it
arrives
at
infrastructure,
and
we
have
to
send
it
all
the
way
back
and
say
no.
We
can't
accept
this
because
of
this.
You
didn't
meet
the
requirements
of
running
something
in
a
kubernetes
cluster.
Your
container
has
root.
This
is
not
allowed
in
our
infrastructure
and
stuff.
B
Like
this,
you
know,
and
if
we,
if
we
just
enable
the
people,
the
development
teams
in
the
first
place,
if
you
just
really
take
their
hand
and
show
them
everything,
they
need
to
know
to
work
with
our
platform
with
kubernetes
itself,
with
Cloud
native
with
a
vertical
of
cloud
provider
native
services
like
here's,
your
AWS
account,
for
example,
or
here's
your
Azure
account.
You
can
connect
that
your
own
account
and
that
service,
like
an
RDS
with
your
container.
A
B
B
So
the
having
having
these
these
verticals
of
cloud
native
services
that
you
can
connect
to
your
container
and
having
the
infrastructure
really
just
focusing
on
something
that
everybody
needs
the
common
denominator
and
infrastructure
security
and
runtime.
That's
it
period,
everything
else
kind
of
qualifies
the
special
needs
that
not
everybody
has
like
the
hundred
percent
right.
You
have
many
80
20
use
cases
there,
but
it's
not
100
100
of
security
in
runtime,
and
that's
that
you
have
a
set
of
projects.
B
That,
if
you
enable
them
enough
in
using
the
cloud
native
Technologies,
they
can
help
themselves.
First
of
all,
which
reduces
support
tremendously
like
day
two
support
yeah
and
they
Don't
Ride
10
tickets
each
day
because
they
have
a
question.
They
know
how
to
run
the
stuff
on
the
phone
so
right,
first
enablement
or
the
enablement
in
general
to
be
on
the
platform,
the
educational
layers,
our
utmost
focus
when
onboarding
people.
B
We
need
to
learn
using
these
Technologies
very
well
to
work
with
us
to
be
on
our
platform,
and
then
we
help
them
automate
that
stuff
right
once
once
it's
automated
they
just
automate
through
the
silos
right.
You
get
all
the
devs
agops
benefits,
yeah
all
the
business
value
out
of
it
and
you
respect
the
silos
interesting.
A
B
B
A
Yeah
yeah,
it's
a
very
small
kind
of
set
of
projects.
I
think
that
lift
and
shift
is
probably
a
good
idea
if
you're
going
to
Cloud
native,
because
you
really
should
it's
really.
If
you,
if
you
re
the
only
way
you
can
really
take
advantage
of
that
new
architectural
environment
is
by
re-architecting
it,
and
it's
not
just
like
you-
know:
you're,
not
just
kind
of
rewriting
code
you're,
actually
improving
the
capability
of
the
system,
which
you
know,
that's
often
not
something.
That
is
necessarily
obvious,
with
the
kind
of
lift
and
shifts
scenario.
B
A
Right
well,
the
the
one
kind
of
scenario
where
it's
kind
of,
like
you
know:
I,
like
the
the
lift
and
shift
model
which
is
really
like
we're
just
taking
this,
this
old
golden
image
VM
and
now
we're
managing
it
in
kubernetes
through
like
Cooper
or
whatever,
and
it's
like
that
kind
of
level
of
lift
and
I
think
makes
a
lot
of
sense
because
you
can
kind
of
get
to
that
single
pane
of
glass
stuff.
You
know
and
all
that
jazz,
but
you're
not
actually
changing
much
about
the
application
itself
right.
A
B
A
Right
well
and
but
I
think
that
also
gives
you
an
advantage
in
your
how
you're
working
with
those
teams
right,
because
those
teams
are
expecting
to
be
building
new
and
therefore
learning
new
and
they're,
probably
really
excited
about
building
new
and
so
I.
Think
that
also
helps
your
kind
of
adoption
connections
too
right.
Yes,
exactly
yeah.
B
Exactly
when
it
comes
to
the
different
business
domains
of
an
Enterprise
like
an
oem,
you
have
software
systems,
obviously,
and
you
have
a
lot
of
Legacy
systems,
there's
modernization
going
on
in
all
the
places.
So
it's
not
only
about
software,
creating
software
creating
Digital
Services.
Sometimes
it's
also
about
migrating,
an
entire
Factory
to
a
new
system
and
managing
iot
devices.
So
the
use
cases
are
very,
very
diverse
and
in
this
kind
of
field,
we're
more
in
a
in
a
Consulting
role.
We
don't
do
these
kind
of
platforms
ourselves.
B
We
don't
manage
them
ourselves.
We
focus
really
on
the
multi-cloud
multi-10
public
Cloud
multi-tenancy,
you
guys
with
our
own
platform,
but
as
a
component
Center,
we
consult
other
Platforms
in
their
emerging
state
or
in
their
planning
phase.
We
are
supporting
Enterprise
architecture
management,
we're
supporting
portfolio
management
like
everything,
an
Enterprise
needs
needs
in
terms
of
know-how,
about
infrastructure
and
kubernetes
and
Cloud
native
Technologies
yeah.
A
Yeah
yeah
yeah,
yeah
I,
was
going
to
kind
of
ask
you
I
wanted
to
do
a
quick
shout
out
for
the
car,
though,
like
I,
am
so
impressed
the
sight
lines
on
this
car,
because
you
know
it's
like
when
I'm
trying
to
take
a
there's.
One
of
these
turns
that
I
take
where
there's
basically
a
bike.
Lane
right
next
to
me
and
like
I,
can
actually
see
in
the
mirror
yeah
clearly
where
their
bikes
are
and
I
you
know,
I
just
the
design
is,
is
amazing,
isn't
it
yeah?
It's
really
it's
really
nice.
A
A
A
B
A
B
This
is
super
important
actually
because
we
need
to
find
out
why
they're
doing
stuff
in
the
first
place
and
then
what
happens
most
of
the
time
when
I'm,
really
honest
here
is
that
I
tell
you.
We
already
got
that
talk
to
him,
yeah
yeah
yeah.
The
many
initiatives
exist
because
the
company
is
so
big
and
we
didn't
know
we
already
have
it
right
yep,
and
there
needs
to
be
that
couple
of
guys
that
just
know
the
people
and
just
pinpoint
you
to
it.
A
Yep
yeah
yeah
I
totally
hear
that
it's
at
the
the
you
know
the
the
client
that
already
or
the
person
who
already
knows
the
requirements-
and
you
know
knows
exactly
the
answer
and
then
is
completely
on
the
wrong
path.
You
know,
like
I've,
mentioned
many
many
times
before.
I
spent
a
long
time
in
Consulting
yeah
and
getting
you
know
getting
the
customer
or
whoever
to
stop
giving
you
the
solution
and
instead
tell
you
the
problem.
Yeah.
You
know
a
huge
part
of
the
the
conversation
and.