►
Description
Christoph Eberle - a Red Hat solution architect that works with Swiss Railways demonstrates how they use OpenShift and DevOps to transform their organization and accelerate application delivery.
Don't forget to check our blog, https://blog.openshift.com/, to find more content that will help you ramp up your DevOps knowledge.
A
As
joe
already
announced,
I'm
not
baltisor
oswald,
but
chris
eberle.
I
don't
work
for
sbb,
but
I'm
a
red
hatter,
but
our
colleague
had
to
fly
home
yesterday
to
switzerland
and
I'm
working
actually
with
sbb
for
quite
a
long
time
now
on
openshift
and
other
topics.
So
for
more
than
a
year.
So
I
said,
no
worries
I
will
step
in
and
I
will
take
the
session
here.
A
So,
first
of
all,
who
is
swiss
railways
clear
swiss?
They
are
in
switzerland
and
they
do
rail
business,
so
they're
on
trains
for
goods
as
well
as
persons,
and
actually
they
are
plus
minus
the
only
rail
company.
You
could
say
they
have
a
monopoly
there
in
switzerland
and
we
are
working
with
them
on
openshift
for
quite
a
while.
Now-
and
I
actually
I
want
to
talk-
is
about
how
they
went
to
openshift
or
why
they
were
thinking
about
openshift
and
what
were
the
steps
which
led
them
there
about
tourist
railways
itself.
A
A
What
I
want
to
start
with
is
actually
a
talk
about
devops
in
combination
with
provider
management,
so
what
sbb
actually
did
or
how
they
started
a
couple
of
years
ago
is
that
they
introduced.
I
think
it
was
around
10
years
ago
or
something
where
they
started
to
introduce
so-called
shared
platforms
where
multiple
applications
and
products
could
or
projects
could
put
their
applications
on
shared
platforms
for
ibm
websphere,
for
example,
shared
platforms
for
databases
and
so
on
and
so
on.
A
So
they
build
up
these
big
shared
platforms
so
that
all
the
the
projects
in
sbb
could
put
their
applications
there.
There
was
one
problem
with
these
shared
platforms,
which
is
the
isolation
between
the
applications.
So
it's
really.
It
was
a
technical
limitation
which
they
could
not
really
resolve
network-wise
cpu-wise
that
they
could
not
really
isolate
the
stuff
from
each
other
and
what
they
did
then,
as
a
consequence,
is
to
introduce
processes
to
mitigate
these
risks.
A
So
you
have
big
change
management
processes.
You
have
word
templates,
which
are
used
for
the
handover
from
artifacts
from
from
different
stages
to
each
other,
so
they
really
introduced
a
big
process
machinery.
You
could
say
for
change
management
and
to
mitigate
these
risks
of
applications
affecting
each
other,
and
this,
as
a
consequence,
certainly
broke
up
development
and
operations
into
different
silos,
because
in
the
middle
you
have
this
big
heavyweight
processes
which
just
separate
the
two
of
them
as
well.
A
You
had
the
interface
between
dev
and
tops,
was
very
technology
specific,
so
for
every
technology
you
had
own
dev
and
ops
teams.
You
had
an
ops
team
for
web
sphere,
one
for
database,
one
for
every
technology
and
what
spp
did
then
is
they
said:
okay,
we
are
going
to
outsource
some
of
the
operations,
so
the
infrastructure
operations,
for
example,
is
outsourced.
A
The
platform
operations
is
outsourced
to
to
any
provider,
and
the
impact
of
this
is
certainly
that
the
gap
between
dev
and
ops
even
gets
bit
bigger,
because
it's
two
different
companies,
probably
two
different
or
I
mean
we
have.
We
talks
with
german
in
switzerland.
Nobody
else
does
nobody
else
understands
us.
If
we
have
to
talk
english,
it's
getting
a
bit
tricky.
So
if
all
these
things
are
coming
as
well
into
play,
if
you
outsource
things
to
a
provider
and
what
they
did,
then,
because
the
gap
was
so
big,
they
said.
A
Okay,
we
need
to
have
an
ops
team
as
well
in
sbb
itself,
so
they
call
it
operations
management
and
what
does
operations
management?
Do
they
sit
between
the
provider,
ops
and
the
development
and
coordinate
activities
there?
This
is
what
what
these
guys
do.
So
you
have
another
hop
or
another
ops
which
which
you're
adding
to
the
game
here-
and
this
is
not
enough-
certainly
because,
usually
you
have
a
multi-provider
strategies,
so
you
have
multiple
provider
providing
different
pieces
or
operations
for
different
pieces
of
your
infrastructure,
and
so
this
is
what
happened
as
well.
A
You
had
they
had
to
manage
different
providers
for
each
technology.
Still,
you
have
an
operations
team,
so
it's
not
only
the
different
companies.
You
have
to
manage
the
different
providers,
but
as
well
per
technology.
You
have
such
operations
teams
and
I
mean
if
they
wanted
to
introduce
a
change
which
affected
some
backend
systems
and
some
front-end
systems
they
had
to
orchestrate
these
changes
across
multiple
different
operations.
A
A
A
The
results,
of
course,
or
with
red
hat,
is
to
introduce
openshift
and
they
introduced
openshift
for,
on
the
one
hand,
side,
development
of
applications
and,
on
the
other
hand,
for
operations
of
applications
as
well,
so
openshift
provides,
on
the
one
hand,
side
the
isolation
of
applications
from
each
other,
which
allows
them
to
remove
these
heavyweight
processes
around
and
build
so-called
devops
teams.
The
devops
teams.
They
are
responsible
for
an
application
end-to-end
so
from
the
development
into
over
the
whole
staging
into
production
and
maintenance
of
the
application.
A
A
Sbb
itself
is
responsible
for
the
application
and
its
operations
and
the
providers
are
responsible
for
operating
the
base
platform.
So
openshift,
you
can
still
have
strategies,
so
you
can
still
have
multiple
providers
providing
you
an
openshift
platform
which
you
can
use
as
well.
Certainly,
openshift
brings
a
lot
of
benefits
in
automation
after
of
operational
tasks,
so
operations
is
getting
smaller
and
smaller.
A
That's
the
plan
actually
and
one
other
big
thing
is
that
you
do
not
have
to
have
multiple
different
teams
anymore
for
the
different
technologies,
because
the
the
interface
between
devops
and
openshift
ops
is
not
about
technology,
not
it's
not
about.
I
want
to
host
a
jee
server.
I
want
to
host
an
ojs.
A
This
is
not
important
anymore,
because
it's
all
containerized
and
it
doesn't
really
the
technology
itself-
doesn't
really
matter
anymore,
so
the
interface
is
much
more
simplified.
So
what
sbb
has
right
now?
They
run
stuff
on
premise:
they
run
stuff
in
public
cloud
as
well
on
openshift,
and
this
brings
me
to
the
use
cases.
Kind
of
so
one
use
case
we
are
currently
working
on
is
the
sbb
mobile
app?
Actually
it's
one
of
the
most
popular
apps
in
in
switzerland.
A
It's
always
under
the
top
five
ranked
apps
in
switzerland.
There
is
around,
I
think,
a
million
downloads
or
something
and
the
back
end
of
this
app.
This
is
probably
the
first
use
case
is
running
on
on
aws,
so
everything
customer
facing
will
be
running
on
aws
and
other
systems
like
backend
systems,
are
running
on
the
internal
cluster.
A
This
is
one
of
the
use
cases
we
are
currently
implementing.
Then
the
web
shop
is
the
next
project
which
is
coming.
Actually,
we
have
identified
around
15
projects
which
we
are
going
to
put
to
openshift
by
by
the
end
of
the
year.
That's
the
plan
and
also
they
are
currently
defining
their
future
technology
stack,
so
they
call
it
their
cloud.
Technology
stack
consisting
of
spring
boots,
then
redis
database
and
so
on.
So
they
really
define
a
set
of
technologies.