►
Description
Today we continue with Veer Muchandi's series of 4 videos that will guide you through every detail you need to know to start building and running your own Microservices.
This is the second video in the series and explains how the micro services concepts are realized on OpenShift. We will look at how micro services are represented using kubernetes pods, services and sometimes routes, how they can be deployed and scaled independently.
This series of videos was created in collaboration with Chakradhar Jonagam, a Solution Architect at Red Hat.
NOTE: For the latest information on OpenShift 3.1, please visit https://enterprise.openshift.com or subscribe to the OpenShift Blog (https://blog.openshift.com).
A
The
intent
here
is
not
to
explain
what
micro
services
are
and
teach
the
advantages
of
going
for
micro
services,
and,
although
that's
that's,
not
what
I
want
to
cover
here.
There
is
lot
of
documentation
and
some
good
material
available
for
that.
This
video
is
only
about
how
micro
services
run
on
OpenShift,
so
to
quickly
define
micro
services.
A
That
means
it
exposes
specific
interfaces
so
that
the
other
services
can
depend
on
that
boundary
end
and
use
it
without
worrying
about
the
side
effects
right
and
then
every
service
can
be
written
in
its
own
programming
language,
and
we
will
see
an
example
of
that
in
the
future.
Videos
and
then
each
service
can
be
managed
by
its
own
different
team
right,
so
when
these
are,
in
general,
considered
to
be
the
features
of
micro
services.
A
So
how
do
we
realize
micro
services
using
containers
in
openshift
version
3,
I'm
again
using
the
figures
from
Marting
folders
articles
so
that
it's
easy
to
understand,
because
most
of
the
people
who
are
coming
here
would
have
already
read
it.
So
he
talks
about
how
monolithic
application
puts
all
its
functionality
into
a
single
process,
whereas
in
case
of
micro-services
architecture,
you
take
each
element
of
functionality
and
make
it
a
separate
service
right.
A
So
what
you're
seeing
here
are
each
individual
services
that
that
are
micro
services
and
these
services
run
on
a
host
where
there
are
a
bunch
of
processes
that
are
running
on
this
one
host
right
and
in
case
of
monolith,
you
have
a
host
which
is
running
a
entire
monolithic
application.
Now,
when
you
think
about
it
from
the
perspective
of
OpenShift,
the
container
host
on
which
these
services
run
is
an
open
shift
nor
and
then
the
individual
processes.
These
are
micro
services
running
in
containers
on
this
host.
A
Now
each
micro
service
itself
may
be
made
up
of
one
or
more
containers.
So
if
you
see
the
micro
service
on
the
right
side
here,
this
white
box
you
are
seeing
here
is
a
micro
service
and
it
is
made
up
of
more
than
one
container
right.
You
have
an
application
container
and
you
have
a
database
container,
and
this
whole
thing
put
together
is
a
micro
service
when
you
consider
this
from
OpenShift
perspective.
A
Each
one
of
these
is
a
kubernetes
part,
so
your
micro
service
is
made
up
of
two
kubernetes
pods
in
this
case,
and
this
particular
micro
service
is
made
up
of
a
single
kubernetes
part.
The
next
question
is:
how
do
these
parts
get
placed
on
the
nodes?
Where
do
they
run
right?
Your
application
may
be
made
up
of
X
number
of
parts,
but
are
these
parts
running
together
on
one
box?
A
So
if
you
are
running
multiple
instances
of
your
application
component,
that
means,
if
you
have
running
multiple
parts
for
the
same
application
those
fours
get
distributed
across
the
notes,
so
that
all
exam
not
in
the
same
basket
right.
That
part
is
taken
care
of
with
kubernetes
or
OpenShift
Orchestrator,
which
is
part
of
the
math
master
scheduler.
Now
another
thing
is
the
micro
services
can
scale
independently
right.
That
was
one
of
the
features
we
talked
about
think
about
this
particular
application.
A
There
are
two
instances
of
this
application:
multiple
application
parts
they
have
scaled
independently
and
they
are
talking
to
a
shade
database.
In
this
case
right.
The
next
thing
is
scaling.
Openshift
allows
you
to
scale
your
parts
up
and
down
the
specific
parts
that
you
desire
to
scale
up.
You
can
scale
them
independently
up
and
down
as
needed.
You
could
be
using
manual
scaling
or
automatic
scaling
both
are
possible.
A
The
next
thing
is
the
replication
controller
that
manages
when
the
pods
are
not
responding
or
if
the
pods
go
down.
For
some
reason,
there
is
a
automatic
check
built
into
kubernetes,
where,
if
a
part
burns
down
for
some
reason,
openshift
goes
and
finds
another
node
where
that's
what
can
spin
up?
So
your
micro
services
are
not
only
scalable,
they
are
also
you.
A
You
are
also
building
in
some
amount
of
reliability
in
it,
so
that,
if
the
number
of
instances
that
you
desire
to
run
go
down
because
the
pod
went
down,
this
automatic
feature
will
go
and
spin
up
the
number
of
instances
you
require
on
the
available
infrastructure.
So
even
that
is
built
into
openshift.
A
Now,
to
summarize,
if
you
go
back
to
our
discussion
in
the
previous
video,
where
the
applications
come
together
by
multiple
application
components
running
as
independent
pieces,
but
coming
together
or
even
different
applications
talking
to
each
other
right,
each
of
these
can
be
considered
as
by
as
a
micro
service,
and,
as
you
can
see,
each
micro
service
can
run
a
number
of
part.
That
means
it
can
scale
independently
of
each
other,
as
well
as
within
a
micro
service.
Each
can
scale
independently.
A
The
service
discovery
mechanism
is
also
built
into
OpenShift,
so
you
can
directly
talk
to
the
kubernetes
service
that
exposes
the
parts
the
different
different
micro
service
is
running
on.
A
openshift
can
talk
to
each
other
and
those
micro
services
that
you
desire
to
expose
to
the
outside
world
can
be
exposed
wire
outs,
so
the
all
the
infrastructure,
the
that
is
needed
to
scale
and
run
micro
services,
are
built
into
OpenShift
already
right.
That's
how
the
platform
supports
micro
services.
Now
now,
in
the
next
video,
we
will
look
at
some
examples
of
micro
services.