►
From YouTube: Customer Case Study: The OpenShift Journey - Satish Puranam (Ford) OpenShift Commons 2022 Detroit
Description
Customer Case Study: The OpenShift Journey at Ford Motor Company
Red Hat OpenShift Commons 2022 @ Kubecon/NA
Detroit, Michigan
October 25, 2022
Speakers:
Satish Puranam (Ford Motor Company)
https://commons.openshift.org/gatherings/kubecon-22-oct-25/
A
A
Motor
company-
and
we
are
new
data-
is
the
king
for
what
we
do.
Technology
rules
everything
and
governs
everything
that
we
do
day
in
and
day
out,
all
the
commercial
vehicles
we
produce
Entertainment
Systems
software
updates
that
happens
to
for
all
to
to
the
fleet,
all
is
driven
through
technology.
So
it's
completely
disrupting
our
industry.
It's
completely
disrupting
how
we
do
business
where
we
do
business
and
how
we
engage
with
our
end
users
and
customers
right.
A
A
Problem
is
humongous.
We
can
talk
about
kubernetes
all
day
long
guess.
We
will
find
a
different
alternate
location
to
talk
about
this
thing,
maybe
outside,
but
all
I'm
going
to
talk
about
is
like
how?
Where
did
we
start
this
journey?
Why
did
we
embark
on
this
journey
and
few
Lessons
Learned
along
the
way?
A
the
biggest
thing
that
when
Ford
announced
everybody
had
an
app
right,
we
have
to
also
have
an
app
right,
so
we
have
an
app
called
as
Fort
pass
that
actually
allows
you
to
interact
with
the
cars
and
do
several
interesting
things
with
it.
Go
find
a
gas
station
things
like
that.
At
the
same
time,
we
also
started
Journey
around
Cloud
Foundry,
because
that's
where
we
started
saying
hey
12,
Factor
apps,
it
was
in
Vogue
and
everything.
So
we
got
to
do
something
about
it.
A
So
to
streamline
and
fasten
the
speed
of
at
which
we
develop
applications,
Cloud
Foundry
was
rolled
out.
I
think
quickly
realized
that
well,
there's
a
thing
called
a
stall
Factor,
but
there
is
always
a
state
somewhere
can't
avoid
it.
So
what
do
you
do
with
the
stateful
things?
So
that's
when
we
started
headlong
with
kubernetes
believe
it
is
not.
A
We've
been
told
that
we're
one
of
the
few
people
who
started
kubernetes
explicitly
for
State
Global
workloads
and
we
still
run
predominantly
stateful
workloads
in
our
kubernetes
environments,
but
then
we're
still
pre-cloud
errors
at
least
Cloud
major
Cloud
adoption
areas.
We
still
built
two
data
centers
here
in
Michigan
and
spent
good
chunk
of
next
two
years.
Moving
applications
to
these
data
centers
then
came
the
horrid
covet
and
we
have
to
change
adapt
really
really
fast.
With
that
came,
SAS
Services
drafted
a
lot
of
services.
A
Sure,
last
year
we
hope
we
announced
a
huge
rollout
in
gcp
and
that's
what
we've
been
working
towards
this
year
as
well.
Major
deployments
have
been
completed
and
accomplished,
but
the
challenges
remained
biggest
challenge.
How
do
you
get
started?
Where
do
you
get
started?
When
do
you
get
started
right?
So
question
is
like
what
are
some
of
our
guiding
North
Star
items
that
we
talked
around
all
of
this
stuff
right.
A
So
what
we
say
and
what
we've
been
saying
along
this
journey
is
like
we
want
to
be
Cloud
first,
we
want
to
make
it
as
dumb,
simple,
stupid,
easy
for
people
to
get
started
and,
most
importantly,
how
fast
can
you
get
started?
We
don't
want
to
introduce
whole
bunch
of
red
tape
just
because
we
can
or
we
should
the
question
becomes.
Is
that
is
it
really
needed
if
it
is
not
needed?
We
need
to
question
why
we
are
doing
some
things
so
with
that
I
think
the
biggest
challenges
that
we
see.
A
Some
of
these
things
will
clearly
resonate
with
many
of
you.
I
hope.
So
is
what
is
important
at
that
given
point
in
time,
because
most
of
our
devs
may
not
be
Cloud.
Experts
may
not
be
kubernetes
experts,
they
are
not.
You
know,
yaml
ninjas,
but
what
is
more
important
to
them?
Can
we
focus
on
those
important
aspects?
A
A
So
what
is
the
goal?
The
goal
is
we
want
to
reduce
the
entire
entry
point,
make
it
as
that
simple,
provide
opinionated
Stacks.
The
important
thing
is
that
if
we
do
not
provide
those
opinionated
Stacks
who
provides
them
because
everybody
has
been
going
to
be
experimenting
on
their
own,
we
don't
want
that.
We
want
to
have
some
opinions,
which
is
great
so
that
way
we
can
reduce
the
snowflakes
and
then,
if
somebody
calls
me
and
says
that
I
need
help.
At
least
I
have
a
place
to
start
with.
A
Otherwise,
if
everybody
is
unique,
then
I
need
to
have
one-on-one
time
with
those
guys
right.
So
the
guide
I
think
the
goal
is
increased.
Consistency,
reduce
barriers,
make
up
all
those
things
available,
truly
as
if
it
is
present
in
Cloud.
Indeed,
we
are
in
Cloud.
The
question
becomes:
is
that
what
do
we
do
so?
What
did
we
do
is
that
the
biggest
thing
is
that
we
establish
communities
started
in
since
increasingly
intensifying
incentivizing.
Sorry,
learning
right
so
reduce
where
possible,
reduce
you
know,
manual
efforts.
Can
we
automate
it
away?
Can
we
hide
things
away?
A
A
We
do
have
like
a
lot
of
other
getting
started
guides
for
everything
from
kubernetes
to
storage,
to
network
security
policies,
and
everything
in
between
the
idea
is
that
there
are
reference
examples
that
you
can
get
started
with,
and
we
only
want
to
fall
back
to
dojos
or
office
office
hours
if
we
have
to
because
dojos
and
office
hours
does
not
scale
if
you
cannot
engage
10
people
for
an
hour
long
session
and
then
rinse
and
repeat
it
for
five
thousand
developers.
It's
almost
an
untenable
task
and
you'll
always
be
trying
to
find
it.
A
The
important
thing,
hence
is:
how
can
we
actually
get
you
going
now,
rather
than
two
hours
from
now
or
two
days
from
now,
so
most
of
the
work
that
we
have
done
so
far
focused
on
the
Outer
Loop
of
the
development.
So-Called
you
know,
Dev
sends
out
a
PR
could
be
terraform
could
be
Java
code
or
what
have
you
but
we're
going
to
have
a
set
of
Pipelines.
That's
going
to
meet
you
in
your
git
repository.
A
All
the
feedback
will
be
provided
at
the
git
repository
itself,
so
that
you
don't
have
to
jump
through
whole
bunch
of
Hoops
to
see
what
happened
to
your
PR
the
same
time.
We
also
started
with
what
we've
been
calling
as
the
inner
loop,
so
which
is
basically
a
local
Dev,
so
lots
and
lots
of
hours
are
spent
configuring.
Your
laptop
I
have
a
Mac,
somebody
has
an
x86
or
the
7m1.
A
Somebody
has
Windows,
10
terraform
doesn't
work
here
or
what,
if
somebody
doesn't
have
an
admin
access?
So
those
are
the
important
challenges
that
we
have
been
dealing
with.
How
do
you
simplify
that
right?
So
with
that
one
of
the
things
as
I
said
earlier,
Cloud
native
CI,
CD,
tooling,
that
we
adopted
at
large
to
devil
to
drive
some
of
these
Cloud
adoptions
is
tacton.
Why
techton?
Why
not
I'm
like
it's
kubernetes
native
number,
one
best
part
it
scales,
serverless
right
and
it
doesn't
give
you
any
opinions
about
it.
A
You
can
be
Java
developer
can
be
a
Powershell
developer.
You
can
write
your
task,
the
important
thing
it
gives
you
a
reusable
building
blocks,
rather
than
trying
to
reinvent
the
same
bill
over
and
over
again.
If
you
want
to
send
a
mail
sending
a
mail
sending
a
mail
is
the
same
thing.
It
doesn't
matter
if
it
is
the
Java
project
or
a
python
project,
so
to
speak
right.
A
The
idea
is
that
a
pipeline,
along
with
the
terraform,
is
all
provided
to
you
out
of
the
box,
and
you
don't
have
to
engineer
it,
but
you
can,
if
you
want
to
nothing,
is
preventing
that.
The
other
aspect
is
like
one
of
the
things
that
we've
been
focusing
a
lot
and
last
quarter
or
so
is
like.
How
can
we
simplify
that
inner
loop
there's
a
lot
of
devs?
All
the
development
happens
in
a
laptop
everybody,
most
of
us
at
least
at
four.
We
are
all
remote
these
days.
A
How
do
you
make
sure
that
we
got
all
the
right
set
of
tools
we're
also
moving
fast
I'm
like
today
we
are
using
X
version
of
kubernetes
tomorrow
we
will
be
using
Y
version
of
it.
So
how
do
you
make
sure
that
the
right
set
of
tooling
is
prevent?
How
do
you
make
sure
the
identities
are
propagated?
We
don't
want
to
give
out
passwords.
A
We
don't
want
to
give
out
things
like
hey
service
account
keys
if
you're
in
gcp.
What
we
want
to
do
is
that
we
want
to
use
this
Cloud
correctly,
won't
give
you
a
place
where
things
are
secured
correctly
now
produce
the
blast
radius.
The
goal
is
that:
can
we
bring
those
tooling
that
we
can
package
and
iterate
on
it
host
it
in
a
central
environments,
so
so
that
so
what
we
are
trying
right
now
is:
can
we
move
those
Dev
environments
to
Cloud?
A
Can
we
put
it
in
kubernetes,
like
some
of
the
Technologies
out
there
like
Eclipse,
Shea
I,
think
openshift
provides
a
solution
called
as
openshift
Dev
spaces
is
a
great
example
of
that.
Google
has
something
called
as
Google
workspaces,
but
the
same
idea.
The
idea
is
that,
can
we
move,
you
know
inner
loop
work
that
happens
on
your
laptop
to
a
cluster
so
that
you
all
you
have
to
bring,
is
a
browser
to
the
table.
A
So
that's
some
of
the
goals.
What
we
want
to
do
there,
but
the
important
thing
is
that
keep
it
easy
make
it
dead,
simple,
easy,
so
that
we
can
iterate
on
it
really
really
fast,
so
some
of
the
Lessons
Learned
around
the
way
right.
So
the
important
thing
is
like
there's
a
lot
of
Open
Source
that
we've
been
using.
A
The
important
thing
is
that
it's
a
two-way
street.
You
have
to
participate,
you
have
to
participate
and
you
have
to
contribute.
That's
the
only
way
we
can
make
this
thing
better
because
open
source
rules,
most
of
us,
are
here
in
this
conference,
primarily
because
we're
talking
about
celebrating
the
successes,
some
failures
as
well.
Nothing
is
perfect.
The
important
thing
is
like
takes
to
two
to
tango,
in
other
words,
contribute.
A
Don't
shy
away
from
upgrading,
don't
remain
in
Old
School.
Thinking,
saying
that
we
have
to
actually
remain
in
this
version
of
X
for
10
years.
That
will
not
help
we've
been
through
it.
It
is
tough
to
operate
update,
so
don't
do
it
at
the
same
time.
I
won't
say
that
be
at
the
trunk
at
the
tip
of
the
trunk
right,
bad
idea,
n
minus
1,
n
minus
2
is
a
great
place
to
be
it
start.
Small
engage
people
make
them
successful
at
what
they
do
before.