►
From YouTube: OpenShift Commons Briefing #114: Cloud Native Java Apps w/WildFly Swarm & OpenShift App Runtimes
Description
WildFly Swarm is bringing the world of microservices to Enterprise Java developers. If you have experience developing with Java EE, then WildFly Swarm will ease the transition to a microservices architecture on OpenShift. This briefing will give an overview of WildFly Swarm and how it is delivered through Red Hat OpenShift Application Runtimes. We’ll also cover some practical techniques for coding and deploying effective Java microservices on OpenShift using WildFly Swarm. By the end of this session, you will have a good understanding of how to leverage your existing Java EE skills to develop microservices and how to get started with your own project.
A
A
Hello
and
welcome
to
another
open
ship
Commons
briefing.
This
time
we
have
one
of
my
favorite
Red
Hatters
James
Faulkner
from
the
Red
Hat
metalware
team
coming.
He
is
going
to
talk
to
us
about
building
cloud
native
applications
using
some
of
the
Rourke's
work,
that's
being
done
at
Red,
Hat
and
Wildlife's
form
so
I'm,
going
to
let
James
introduce
himself.
The
format
of
this
event
is
that
we
do
the
Q&A
in
chat
and
there's
a
live
demo
and
at
the
end
of
this
whole
session,
when
he
finally
takes
a
breath,
we
will
have
live
Q&A.
A
B
Great
thanks
Diane,
so
hello,
everyone,
as
Diane
mentioned,
my
name,
is
James
Faulkner
I
am
a
technical
marketing
manager
in
the
Red
Hat
middleware
group.
Today,
we're
gonna
be
talking
about
building
cloud
native
applications
with
wild
fly,
swarm
and
roar.
I'll,
give
you
a
brief
intro
to
roar
and
wow
if
I
swarm,
but
the
most
of
the
time
we'll
spend
doing
hands-on
demo.
So
you
can
get
a
feel
of
what
this
is.
What
we're
actually
talking
about
here,
I
won't
spend
too
much
time
on
the
on
the
marketing
fluff
at
the
beginning.
B
Just
briefly,
a
couple
of
other
openshift
Commons
briefings
that
have
occurred
late
last
year,
around
roar
and
building
cloud
native
apps
with
spring
boot.
You
can
see
the
listing
here.
We
also
did
one
for
a
model
with
the
micro
services
journey
describing
how
you
can
modernize
your
existing
applications
using
roar
so
check
those
out
if
you're
interested
in
more
in
depth,
detail
around
modernization
or,
if
you're
interested
in
spring
boots
or
roar
in
general.
So
again,
I
will
give
a
brief
introduction
to
roar.
B
So
roar
stands
for
Red
Hat,
openshift
application,
runtimes,
and
what
this
is
is
a
new
product
from
Red
Hat,
it's
a
collection
of
curated
and
certified
and
unsupported
runtimes
and
frameworks
that
are
targeting
micro
service
and
cloud
native
application,
development
for
companies
who
either
have
existing
applications
that
they
want
to
modernize
or
they're.
Building
that
new
applications
native
applications.
You
can
use
the
components
within
roar
to
do
that,
so
here's
a
market
textured
diagram
of
what
it
what
roar
actually
contains.
So
at
the
top
you
see,
tested
and
verified
frameworks.
B
These
are
popular
frameworks
that
have
been
proven
to
be
very
useful
and
effective
in
building
cloud
native
applications
like
spring
boot,
there's
a
number
of
open
source
projects
from
Netflix
around
fault,
tolerance
and
other
aspects
of
micro
service
development,
and
then
underneath
we
have
the
supported
micro
service
runtimes,
which
include
JBoss
EAP,
which
is
we've
had
for
a
number
of
years.
We've
also
added
in
other
popular
runtimes,
like
Eclipse,
vertex
or
building
reactive
applications.
B
We
have
no
js'
for
building
reactive
JavaScript
applications
and
we
also
have
embedded
Tomcat
for
building
more
lightweight
and
web
applications
and
then,
lastly,
we
have
wild
fly
swarm
which
we'll
get
to
in
a
moment.
So
all
of
these
applications
are
packaged
into
a
product
from
Red,
Hat
and
supported
through
our
normal
support
channels.
We
also
have
a
launch
experience
which
I'll
get
to
in
a
moment,
but
getting
down
to
the
nuts
and
bolts.
B
So
when
we
talk
about
these
frameworks,
how
are
they
actually
delivered
to
you
as
a
customer
or
as
an
open
source
developer?
Well,
three
of
them
at
least
are
kind
of
Java
based,
and
so
you
typically
use
things
like
maven
are
great,
also
Weah,
Red
Hat
focus
on
maven,
so
we
have
artifacts
in
maven
repositories
which
deliver
these
components
to
you
for
non
Java
like
nodejs.
In
this
case,
it's
delivered
as
a
container
on
our
Red
Hat
container
catalog.
B
B
If
you
head
over
to
developers,
Red
Hat
comm,
slash
launch,
we
have
a
kind
of
a
guided
wizard-like
experience
for
generating
new
projects,
and
these
projects
exemplify
cloud
native
aspects
like
fault,
tolerance,
with
circuit
breaking
and
externalized
configuration
and
securing
while
securing
micro
services
and
so
forth.
So
we
call
these
things
boosters,
and
so
this
launch
site
will
walk
you
through
and
allow
you
to
select
the
type
of
what
we
call
a
mission
that
you
want
to
see.
B
An
example
of
you
can
also
select
which
runtime
you
want,
whether
it's
spring
boot
or
vertex,
or
swarm
or
nodejs.
You
can
deploy
it
to
your
local
OpenShift
instance
or
you
can
deploy
it
to
OpenShift
online
as
well
so
check
that
out.
If
you
want
to
get
started
without
without
too
much
fuss
and
without
having
to
download
install
too
many
things.
Ok,
so
let's
focus
on
wild
fly
swarm,
so
swarm
is
one
of
the
runtimes
in
R
or
wild
fly,
swarm
targets.
B
Java
micro
services,
it
has
a
lineage
going
back
as
you
can,
as
you
can
guess
from
the
name
goes
back
to
the
upstream
wild
fly
projects,
and
this
is
an
open
source
java.
Ee
application
server,
while
fly
swarm,
brings
in
a
number
of
components
from
wild
fly
itself
to
to
implement
a
number
of
features
that
micro
service
developers
need.
B
Also,
more
importantly,
it
brings
in
Java
EE
features
so
that,
if
you
are
a
Java,
EE,
developer
and
you're
looking
to
implement
micro
services
while
flies
swarm
is
a
great
choice,
because
it
you
can
leverage
that
existing
expertise
that
you
already
have
again.
It
brings
in
components
from
wild
fly,
but
it
also
brings
in
components
outside
of
the
wild
fly
ecosystem
for
doing
a
number
of
things
like
in
which
we'll
see
in
the
demo.
B
In
a
moment,
it
also
is
an
implementation
of
micro
profile,
which
is
a
new
specification
championed
by
a
number
of
companies,
and
we'll
have
some
more
detail
on
that
in
a
moment
so
getting
down
into
the
nuts
and
bolts
of
wild
fly
swarm.
So
what
it
is
is
a
way
to
package
just
enough
of
the
app
server
components
needed
to
run
your
application,
so
these
components
are
packaged
into
what
we
call
fractions.
So
these
are.
B
These
are
things
that
provide
a
small
amount
of
functionality
that
you
need,
and
so
the
way
you
build
your
application,
is
you
declare
the
fractions
that
you
need
you?
Let
well
flies
swarm
auto-detect,
what
you
need
based
on
your
source
code
and
then
it
packages
into
a
single
runnable
jar
file,
which
we
call
a
fat
jar
or
uber
jar.
B
We
also
have
IDE
integration,
so
with
JBoss
Forge,
which
is
a
scaffolding
project
that
in
your
IDE
you
can
click
a
few
buttons
and
it
generates
a
bunch
of
scaffolded
code
for
you
in
the
swarm
case.
It
will
also
do
the
same.
That
will
create
it'll,
generate
a
project
for
you
or
it
will.
It
will
annotate
your
existing
project
with
wild
fly,
swarm
functionality
and
gets
you
up
and
running
very
quickly,
there's
also
a
swarm
tool
which
lets
you
wrap
an
existing
war
file.
B
If
you
have
an
existing
application
and
you
can't
rebuild
it
for
whatever
reason
you
can
wrap
it
into
a
runnable
jar
file
using
swarm
tool
and
then
lastly,
there's
a
project
generator
very
similar
to
what
you
get
in
the
spring
ecosystem
with
start
spring
bio.
If
you
head
over
to
wild
fly,
swarm,
dot,
io
s
last
generator,
you
can
choose
your
dependencies
and
click
a
button
and
it
will
generate
a
project
for
you
which
you
can
download
and
then
you're
off
on
your
way
to
building
awesome
stuff
with
wildlife
swarm.
B
So
we
won't
use
the
generator
today,
but
we
will
use
maven
plug-in
and
the
JBoss
Forge
add-on.
Here's
just
a
quick
screenshot
of
the
project
generator,
as
you
can
imagine
you
just
type
in
some
identifiers.
You
choose
from
an
autocomplete
list
of
dependencies
and
then
you
click
download
and
your
when
your
click
generate
project
and
you're
off
and
running
for
building
cloud
native
applications
with
swarm.
In
particular.
B
So
the
features
you
see
listed
here
are
exposed
and
while
flies
swarm
through
various
fractions
or
functionality
within
swarm
itself
and
we'll
go
through
two
of
them
today,
there's
a
number
of
others
that
we
won't
get
to
because
of.
We
don't
have
enough
time
today
and
you'll
probably
get
bored
watching
screens
flyby
after
20
or
30
minutes.
Okay,
so
I
mentioned
micro
profile,
so
wildfly
swarm
is
an
implementation
of
micro
profile.
B
B
Swarm
is
our
implementation
of
this
specification
and
this
again
targets
java
micro
service
developers
who
might
not
need
the
complete
set
of
specifications
coming
out
of
java
ee
or
they
might
be
using
a
legacy
platform
like
WebLogic
or
websphere,
and
they
kind
of
want
to
move
off
of
that
and
get
into
a
more
micro,
smaller,
logically,
smaller
implementation,
using
a
subset
of
what
they
know.
So
you
can
see
the
list
of
specifications
that
are
included
in
the
latest
release
of
micro
profile,
which
was
version
1.3,
which
came
out
I
believe
about
a
week
ago.
B
It
has
support
for
health
checks,
for
example,
or
CDI
and
fault-tolerance
these
specifications.
Interestingly,
some
of
them
actually
started
in
the
wildfly
community
and
were
donated
to
the
micro
profile
community
as
a
specification.
Obviously
that
makes
things
easier
for
a
wildlife
swarm,
but
in
other
cases
specifications
came
from
IBM
and
and
from
the
rest
of
the
micro
profile
community
members
who
are
working
on
this
so
great
set
very
small
set
targeted
specifically
at
micro
services
and
it's
very
easy
to
use
with
swarm
and
with
any
of
the
other
implementations.
B
B
So
what
it
is,
what
we're
gonna,
what
I'm
gonna
do
is
take
an
existing
application
to
warm
a
PHY
it
and
then
we're
going
to
break
it
apart
into
micro
services
and
show
you
how
you
can
build
some
cloud
native
aspects
into
those
micro
services
using
wild
fly
swarm
and
then
we'll
tie
them
all
together.
Essentially,
what
we'll
be
doing
is
what
we
call
strangling
the
monolith.
B
This
is
a
pattern
that
was
championed
by
Martin
Fowler
a
number
of
years
ago,
where
it
allows
your
projects
to
slowly
evolve
over
time
into
a
more
modular
architecture
without
having
to
rewrite
everything
from
the
ground
up.
Okay,
so,
let's
get
out
of
slide
mode
and
head
over
to
my
trusty
developer
environment.
So
what
I
have
here
is
a
number
of
projects
and
we're
only
going
to
touch
a
couple
of
them
today.
So
the
first
one
is
this
monolithic
application.
This
is
what
I
was
talking
about.
B
This
is
a
Java
EE
application,
typical
maven
build
file.
Here
you
can
see.
I
only
have
one
dependency.
You
actually
have
two
dependencies
I
have
a
dependency
on
Java
EE
itself,
because
I've
built
this
application
over
a
number
of
years
and
I'm,
a
Java
EE
expert
I
also
have
a
dependency
on
a
database,
so
in
this
case
we're
using
an
in-memory
database
for
simplicity.
B
So
the
first
thing
I
want
to
do
as
it
as
a
swarm.
Evaluator
is
I
want
to
start
with
swarm.
So
what's
the
easiest
way
to
do
that?
Well,
I
have
a
forge
JBoss
Forge
project
has
an
integration
with
my
IDE,
so
I've
installed
it
and
now
I
have
a
nice
little
set
of
menu
items,
items
that
I
can
use
to
get
started
quickly,
so
the
first
one
is
called
set
up
so
I'm
going
to
just
click.
B
This
just
gonna
click
finish
and
now
my
project
has
been
swarming
fide,
so
you
can
see
what
it's
done.
Let
me
scroll
up
and
highlight
exactly
what
it
did
here.
So
it
added
a
new
property
to
my
project,
for
the
version
of
wild
fly
swarm
that
it's
going
to
use
it
added
a
plug-in
definition
for
the
wild
fly,
swarm
plug-in
which
integrates
with
maven,
which
I'm
using
and
then
it
also
added
a
dependency
a
set
of
dependencies
in
a
bomb
Bill
of
Materials,
which
brings
in
the
wild
flight
components
as
I
mentioned.
B
This
is
a
Java
EE
project
that
was
written.
You
know
five
years
ago
with
Java
EE
I
am
NOT
going
to
touch
the
source
code
at
all
I'm,
simply
going
to
build
and
run
it
with
wild
fly
swarm.
Now
that
I've
added
these
three
very
small
components.
So
I'm
gonna
open
up
a
menu
over
here
which
gives
me
access
to
my
my
maven
targets,
so
I'm
going
to
open
up
my
project
here.
B
B
So
very
simple:
you
can
imagine
how
that
would
integrate
with
your
existing
built
systems
and
existing
C
ICD
pipelines,
because
it
is
a
fat
jar
or
something
you
would
get
just
like
you
would
get
with
spring
boot
or
drop
wizard
or
other
projects
that
use
the
concept
of
a
fat
jar.
So
right
now
it's
building
you
can
see
up
here
somewhere
it
did
the
auto
detection
so
out
of
the
box
that
auto
detects.
B
So
it
looked
at
my
source
code
and
looked
for
annotations
or
looked
for
specimen
specific
files
and
decided
which
fractions
it
needed
to
import.
So
it
imported
a
number
of
fractions
that
I
never
even
specified
simply
by
auto
detecting
them.
So
it
installed
these
fractions
and
it
started
up
the
project
and
it
looks
like
it
should
be
up
and
running
now,
so
it's
up
and
running
you
can
see
here
and
it's
running
locally.
B
So
if
we
go
back
to
my
browser
and
open
a
new
tab
and
go
to
localhost
8080,
it
should
be
hopefully
up
and
running
it's
up
and
running.
So
here's
my
monolithic
application
didn't
touch
a
single
line
of
source
code,
I,
simply
wrapped
it
in
a
runnable
jar
file
with
wildfly
swarm
I.
Let
it
auto
detect
what
it
needed.
It
created
the
the
runnable
jar
file
and
then
ran
it.
So
I
can
do
things
here.
This
is
a
online
shopping.
Cart,
as
you
can
imagine,
as
you
can
see.
B
Actually
I
can
add
things
in
the
cart.
I
can
remove
things
and
I'm
all
happy
and
everything
looks
good.
Okay.
So
that's
pretty
fun.
Now,
let's
move
into
the
cloud
native
aspect
of
this,
so
it's
still
a
monolith,
but
now
I
want
to
move
it
into
a
cloud
orchestration
platform.
In
this
case
we're
going
to
be
using
open
shift.
B
Open
shift
is
Red,
Hat's,
container
orchestration
platform
built
on
kubernetes
and
so
to
deploy
that
I'm
going
to
use
another
plug-in
called
fabricate
so
fabricate
has
is
an
upstream
project
for
building
micro
services
with
Red,
Hat
technologies
and
other
technologies.
It
hasn't
maven
plug-in
as
well
so
I'm
going
to
go
ahead
and
turn
on
that
plug-in,
and
then
it
should
appear
in
the
menu
here.
So
it
did
so.
Here's
my
fabricate
maven
plug-in,
but
before
I
deploy
it.
B
The
first
thing
you
do
with
cloud
native
applications
is
one
of
the
first
things
you
need
to
do
you
should
do
is
is
create
a
health
check.
This
implements
a
health
check
pattern.
It
allows
container
orchestration
platforms
to
discover
whether
your
application
is
healthy
or
not,
which
is
really
important
for
avoiding
downtime
during
an
update
or
for
detecting
when
something's
gone,
wrong
and
and
and
automatically
you
know,
healing
the
application
replacing
the
broken
parts
and
bringing
up
a
new
version
of
the
application.
B
So
I
want
to
add
a
health
check,
and
it
just
so
happens
that
wild
fly,
swarm
and
micro
profile
have
a
that
notion
of
the
health
check.
So
to
use
this
in
wild
fly
swarm,
you
need
to
add
a
new
fraction,
so
I'm
going
to
use
my
my
trustees,
swarm
tool
or
my
trusty
plugin
here
I
should
before
I
do
that
when
I
stop
this
running
process
and
I'm
gonna
add
this
fraction
that
I
need
for
my
health.
B
Somebody
click
the
magic
button
again
bring
up
the
swarm
command
tool
and
say
add
fraction
so
I'm
going
to
add,
there's
a
number
of
fractions,
there's
almost
200
different
fractions.
You
can
add
to
swarm.
The
one
I
want
is
called
monitor,
and
this
is
a
fraction
that
enables
automatic
health
checking.
So
I'll
click
finish
here
and
the
only
thing
that
it
did
just
now
is
it
added
this
dependency
information
to
my
build
file.
I
could
have
done
that
manually.
B
You
probably
will
do
that
manually
once
you
once
you
become
more
familiar
with
with
swarm
and
the
fractions
it
has,
but
it
added
it
for
me
here
and
now:
I
can
go
ahead
and
and
deploy
my
application
with
a
health
check.
I
want
to
actually
add
some
logic
to
my
health
check,
so
I'm
going
to
quickly
create
a
new
class
in
my
monolith,
which
is
going
to
implement
my
health
check,
so
I'm
gonna
create
a
new
Java
class
I'll,
call
it
infra
endpoint.
A
B
So
I
need
to
add
a
path
here
of
infra
and
I'm,
going
to
create
a
simple
single
endpoint
called
check,
and
it's
going
to
return
a
health
status
which
is
another
class
with
an
off
life
swarm
so
check
and
it's
it's
gonna,
be
extremely
simple:
I'm,
just
going
to
return
healthy,
which
actually
has
value
in
itself,
because
this
won't
actually
work
until
the
application
is
up
and
running.
So
we'll
just
do
this
health
health
status,
dot
names,
we'll
call
it
up.
So
I
can
add
a
bunch
of
logic
up
here.
B
You
know,
inspect
the
database
or
do
something
else
before
I
return
up
and
I
can
return
down.
If
it's,
if
it's
down
I'm,
just
going
to
go
ahead
and
return
up,
so
I
need
to
annotate
this
with
the
with
the
restful
endpoint
annotations
of
get.
So
it's
a
get
endpoint,
meaning
HTTP
GET.
The
path
is
going
to
be
health
and
and
the
magic
Health
annotation
is
a
well
fly.
Swarm
annotation,
which
identifies
this
endpoint
as
a
health
check.
B
You
can
have
multiple
of
these
in
your
application
and
wildfly
swarm
will
aggregate
them
all
in
return
kind
of
an
aggregated
value
depending
on
all
of
those
health
checks.
As
long
as
they
all
pass,
then
swarm
will
be
happy
with
that.
Okay,
so
I've
implemented
my
sync,
my
simple
health
check.
I've
added
my
my
fraction
for
supporting
health
checks,
so
I'm
ready
to
deploy
so
before
I,
deploy
I'm
going
to
go
ahead
and
create
a
new
project
and
in
openshift
itself,
so
I'm
going
to
log
in
to
open
shifts.
I.
B
B
So
this
plug-in
will
package
the
application
with
wild
fly,
swarm
and
then
package
that
into
a
docker
container
image
builder
image
ship
that
off
to
openshift,
and
then
it
will
go
ahead
and
deploy
that
help
to
openshift
and
they
make
sure
I'm
logged
in
it
should
be
logged
in
do
open
shifts.
Yes,
I
am
okay,
so
it's
now
created
the
what
it's
doing
is
actually
building
it
in
open
shift.
So
if
I
switch
back
to
open
shift,
we
can
actually
see
that
build
in
progress.
B
So
you
can
see
that
actually
already
finished,
so
the
build
finished
and
now
what
what
fabricate
will
do
is
create
the
necessary
kubernetes
objects
to
deploy
that
and
get
that
up
and
running
in
open
shift.
Creating
the
deployment,
config
option
object,
the
service
object
and
a
route
so
looks
like
it
finished
now.
So
let's
switch
back
to
open
shift
and
you
can
see
the
application
is
now
running.
It's
actually
on
the
way
up.
While
it's
coming
up,
I
can
show
you
the
health
check.
B
So,
within
the
open
shift
web
console,
you
can
look
at
the
health
checks
and
you
can
see
this
path
to
find
here.
The
slash
health.
This
is
the
you
remember.
The
health
check
I
defined
was
on
infra,
slash
health,
and
so
this
is
the
aggregated
version
of
that
which
will
return
true,
once
it's
up
and
running
here.
Hopefully
so
it
looks
like
it's
up
and
running,
so
we
can
check
out
the
logs
here.
Make
sure
everything
looks
like
it's.
B
Ok,
oh
you
know,
I
forgot
one
thing
so
when
I,
when
I
turned
on
that
health
check
in
the
using
the
dependents
there,
wildfly
swarm
out
of
the
box
does
auto
detection,
which
you
saw
momentarily
ago
by
adding
a
specific,
explicit
declaration
of
this
of
this
fraction.
I
turnout
that
off
and
pleasantly
because
it
thinks
that
I
I
want
I,
know
what
I'm
doing
and
I'm
I
declare
all
the
dependencies
in
you,
but
I'd
actually
don't
know
what
I'm
doing
so
in
order
to
turn
the
automatic,
the
auto
detection
back
on.
B
B
So
this
because
I
again,
because
I
declared
the
monitor
fraction,
it
turned
off
its
automatic,
auto
detection
of
other
fractions
needed,
so
I
need
other
fractions,
obviously,
because
I
haven't
given
it
any
other
fractions
to
depend
on
so
I'll,
deploy
that
under
ployed
and
then
redeploy
it
and
it
should
come
back
up,
hopefully
switch
back
over
to
open
shift.
Here.
It
looks
like
that
one's
gone
and
my
project
is
empty
again
and
then
it
will
rebuild
and
then
and
then
come
back
on.
B
So
you
can
see
now
it's
it's
doing
its
detection
properly,
because
I
forced
it
to
auto
detect.
So
the
application
will
come
up
completely
so
wasteful
and
wait
for
that.
To
finish,
that
should
only
take
a
couple
of
maybe
thirty
seconds
or
so,
and
so
what's
going
to
happen,
is
it's
going
to
deploy
that
same
exact
monolith
but
to
openshift
with
a
health
check?
That's
we
haven't
talked
about
micro
services,
yet
that's
the
next
topic.
So
what
we're
going
to
do
is
with
our
monolithic
application,
which
is
a
retail
store.
B
Where
we're
we
can
remove
the
the
inventory
and
catalog
components,
because
they're
now,
independently
developed
by
our
inventory
team
at
our
company
and
the
catalog
team
at
our
company
and
are
no
longer
part
of
the
monolith.
So
that's
what's
going
to
happen
here,
so
it
looks
like
the
new
version
is
now
finally
up
and
running.
So
if
I
click
this
link
here,
I
should
get
my
monolith
now
and
I
see.
The
monolith
is
running
now
on
open
chef.
So
it's
all
well
and
good.
B
So
again,
this
is
the
this
UI
is
actually
built
from
a
number
of
different
subsystems
within
the
within
the
monolith
which
we're
now
going
to
break
out
into
micro
services,
so
we're
gonna
do
two
of
them,
one
of
them.
I've
already
done
the
inventory
service,
I've,
hired
a
bunch
of
JavaScript
developers
who
love
nodejs
and
so
they've
implemented
the
inventory
micro
service
as
a
node.js
application.
So
you
can
see
it
running
here
or
you
can
see
the
source
code
to
it
here.
It's
a
very
simple
micro
service
written
ended
in
no
js'
and
javascript.
B
I've
already
deployed
it.
So
if
I
switch
back
to
open
shift
and
go
back
to
this
other
project,
here
called
service,
you
can
see
the
inventory
is
already
up
and
running
if
I
curl
it,
which
I
could
do
I,
can
simply
go
like
this
and
curl
I
can
do
it
like
that,
so
I
curled,
a
simple
I
access,
this
nodejs
endpoint,
giving
a
product
ID
of
this
giant
number
and
it
returned
me
the
fact
that
I
have
337
of
these
products
left
in
Idaho.
B
So
it
actually
doesn't
matter
what
number
I
choose
here,
because
my
lazy
developers
just
return
whatever
I
give
them
so
product
45:45
also
happens.
They
have
337
in
Idaho.
Every
single
product
is
going
to
be
in
Idaho
and
have
337
copies
of
it.
We're
going
to
use
that
to
show
you
some
some
interesting
things
with
circuit
breaking
okay,
so
that's
my
inventory
service.
It's
up
and
running
already,
so
we'll
skip
that
one
and
move
over
to
the
catalog
service.
B
B
The
way
that
it
returns.
Products
is
very
simple,
so
it's
actually
a
dumb.
It's
called
dumb
get
quantity
and
it
calls
into
the
inventory
system
and
gets
the
inventory
of
each
product
and
then
adds
that
to
the
return
value.
So
let's
go
ahead
and
deploy
that
how
to
open
shift
as
well.
So
I
will
close
that
one
down
open
up
the
catalog
micro
service,
plugins,
fabricate
and
I'll
go
ahead
and
deploy
that
out
to
open
Jefferson.
So
again,
this
is
a
simple
catalog
endpoint
it
collects.
B
It
returns
the
the
products
in
the
catalog,
with
the
inventory
added
to
each
component
of
the
catalog.
By
calling
in
to
this
inventory
service
with
very
little
error.
Checking
in
fact,
there's
no
error
checking
because
it's
dumb
and
my
developers
are
lazy
and
I.
Guess
they
don't
pay
him
enough.
Okay,
so
that's
that's
that's
building!
Hopefully
it
should
take,
maybe
20
seconds
or
so,
to
build
and
deploy,
and
then
we're
going
to
test
it
out
and
see
what
happens
more.
B
Portly,
we're
gonna
see
what
happens
when
the
inventory
service
is
not
working
properly
and
we
should
hopefully
get
a
big
giant
failure.
Okay,
so
well,
that's
deploying
out,
let's
collapse
this
down
and
we
shall
wait
and
the
catalog
server
should
appear
here
momentarily
once
the
build
is
complete.
Just
like
we
built
a
while
flies
swarm
monolith,
we're
building
the
wild
fly,
swarm
micro-service
for
the
catalog
service,
so
it
looks
like
it's
coming
up
now.
This
has
been
deployed
and
it
will
start
to
boot
up
here
again.
B
B
B
B
Let's
see
what
happens
if
I
try
my
product
list
again
so
now
you
can
see
that
it's
sitting
there
waiting
for
a
long
time,
and
you
can
imagine
what
would
happen
if
this
was
a
real-world
product,
a
real-world
application
like
amazon.com,
and
you
went
here
to
buy
a
birthday
gift
for
your
best
friend
and
you
get
this
annoying
timeout
you're
gonna
get
head
over
to
the
competitors
website
and
purchase
from
there
instead.
So
that's
not
good.
B
That's
unacceptable,
I'm,
just
actually
going
to
time
out
after
about
30
seconds
so
what's
happening
here
is
obviously
because
I
shut
off
the
inventory
service.
The
catalog
service
is
unable
to
get
the
inventory
and
it
then
eventually
times
out.
So
let's
fix
that.
So
what
we're
going
to
do
is
we're
going
to
use
history.
So
hystrix
is
a
is
an
open
source
project
from
Netflix
it
does
circuit,
breaking
and
and
bulk
heading
and
essentially
allows
you
to
do
defensive
programming
again.
Essentially,
adding
an
error
check
right.
If
the
service
is
down,
then
do
something
else.
B
So
I've
already
got
the
code
in
here,
but
before
we
can
uncomment
this
code
out,
we
need
to
add
the
the
fraction,
the
wildfly
SCORM
fraction,
so
I
head
over
to
my
palm
that
XML
I.
Can
you
can
see
I
have
a
number
of
dependencies
already
declared
here
so
I
want
to
add
a
new
dependency
again
I'll
just
use
the
swarm
forge
tool
plug-in
in
and
in
my
IDE
here.
B
Hopefully
yes,
there,
it
is
swarm,
add
fraction
and
down
this
one
we're
going
to
use
history
so
I'll
scroll
down
this
giant
list
be
nice
to
have
autocomplete,
but
we
don't
so
I'll.
Just
click
hystrix
finish
and
what
it
will
do
is
add
that,
again
to
my
palm
that
XML
right
here
so
very
simple
again,
you
probably
don't
need
a
tool
to
do
that
for
you,
but
it's
fun
and
good
eye
candy
for
demos,
okay,
so
I've
added
that.
B
So
we
can
see
what's
happening
and
now
I'm
going
to
comment
out
my
dumb
parallel
stream
and
uncomment
or
bring
to
life
my
not
dumb
endpoint,
so
I'm
gonna,
and
so
this
is
going
to
essentially
use
a
history
command
which
essentially
wraps
that
call
to
the
inventory
service
with
a
circuit
breaker.
It
protects
it.
B
So
if
things
are
not
operating
correctly,
then
will
happen,
as
this
inventory
will
kick
in
and
hysterics
will
manage
the
checking
of
the
of
the
inventory
service,
so
the
winning
when
it
comes
back,
it
can
start
sending
traffic
to
it,
so
it
allows
it
to
essentially
recover
so
the
scenario
here
is:
you
have
a
overloaded
inventory
service
or
a
bug
in
the
code
and
it
causes
it
to
fail
and
you
need
a
backup
solution
here.
Our
backup
solution
is
a
very
simple
hard-coded
value.
You
would
normally
do
something
like
check.
B
A
cache
or
go
to
an
alternate
system
or
what
you
would
have
is
multiple
instances
of
the
inventory
system
up
and
running
so
that,
if
one
fails,
it
doesn't
bring
the
whole
system
down
and
it
can.
The
load.
Balancer
can
read
and
send
traffic
to
the
to
the
healthy
versions
of
the
inventory
service.
But
for
now
we're
just
going
to
use
this
simple
workaround
here.
So
okay,
so
I've
got
my
code.
B
I'm
gonna
go
ahead
and
deploy
that
out
again
so
I'm
going
to
undo
play
the
old
one
and
redeploy
the
new
one
that
shouldn't
take
too
long
and
then
we'll
see
what
happens
when
when
the
system
is,
is
a
healthy
and
unhealthy?
Okay,
so
done
deployed
the
old
one
and
I'm
gonna
go
ahead
and
deploy
the
new
one.
Now
let
me
clean
it
first
to
make
sure
I
get
to
make
sure
it
recompiles
and
does
all
the
new
stuff
that
I
want
it
to
do.
B
Okay
and
I'll
go
ahead
and
deploy
if
I'm
in
the
right
project
here,
yep
I
am
deploy
and
then,
while
that's
going,
I'm
gonna
bring
the
inventory
servers
back
online.
Just
so,
we
can
demonstrate
the
the
failure
scenario
here:
okay,
so
it's
coming
back,
the
image
storage
service
is
coming
back
and
the
new
catalog
service
is
being
deployed
at
the
moment,
actually
actually
I
think
it's
building
at
the
moment,
so
switch
back
and
just
have
a
look
at
that.
B
B
Obviously,
with
the
inventory
service
running,
everything
will
look,
good,
will
shut
off
the
inventory
service
and
then
get
to
see
what
happens
with
the
with
hysterics
and
allowing
hysterics
to
manage
the
the
fallback
when
things
are
not
healthy
and
to
manage
the
revival
of
the
inventory
service
once
it
comes
back
online
and
then
the
last
thing
we'll
do
is
tie
all
this
in
to
our
existing
monolith,
which
we
already
have
running
to
kind
of
demonstrate.
The
the
final
strangulation
process,
which
is
turns
out
to
be
extremely
easy.
B
B
Go
back
here
me
yep,
okay,
so
it
looks
like
it's
been
deployed
now.
So
I'll
just
collapse
these
two
and
let's
go
test
our
new
circuit
breaker.
So
let's
hit
it
again.
Okay,
everything
looks
good.
Let
me
pipe
that
to
a
pretty
print
thing
looks
like
everything's
good.
You
just
hit
this
as
many
times
as
I
want
and
looks
good
everything's
good.
So
now,
let's
shut
off
the
inventory
service
and
see
what
happens,
go
ahead
and
turn
this
guy
off.
B
Okay.
Now,
let's
set
it
again.
So
remember
the
last
time
we
did
this
it
timed
out
after
30
seconds
this
one
took
there
was
a.
There
was
a
brief
hiccup
there,
where
it's
it.
If
the
the
call
from
the
catalog
to
the
inventory
timed
out
or
failed
and
then
hystrix
decided
that
the
circuit
needed
to
be
opened
because
because
the
inventory
system
is
unhealthy,
so
we
get
these
negative
ones
here,
and
this
is
what
we
expect
if
we
were
to
tie
this
into
the
UI,
which
we'll
do
you'll
see
the
effect
of
this.
B
So
let's
just
bring
the
inventory
service
back
online
and
hopefully
it
should
recover
here
right
now.
It's
probably
still
kind
of
debating
whether
the
source
and
the
service
is
back
up
and
running
again,
so
we'll
just
hit
it
a
couple
more
times,
and
it
should
once
it
wants
to
decides
that
that
the
service
is
healthy
again,
we
should
start
getting
3:37
again,
which
indeed
we
do
here,
okay,
so
that
that
is
the
circuit
breaker
in
action.
B
In
fact,
if
you
look
at
the
log
file
for
the
catalog,
which
is
where
the
circuit
breaker
is
defined,
you
can
see
there.
The
circuit
breaker
is
here:
there's
fallback
success
short-circuited.
This
was
at
the
time
when
the
when
the,
when
the
inventory
system
was
down,
it
was
short-circuiting
and
then
ultimately,
when
it
came
back
it
finally
then
returned
success.
B
So
the
final
step
here
is
we're
going
to
tie
this
into
the
UI
and,
as
I
mentioned,
it
turns
out
to
be
extremely
easy
because
we,
so
we
have
these
two
services
catalog
in
inventory,
but
our
model
with
running
over
here
has
no
idea
that
those
exist
and
we're
still
getting.
You
know,
values
like
736
512
256,
because
the
existing
monolith
has
no
clue
that
these
services
are
out
there.
So,
in
order
to
tie
these
in,
we
can
actually
use
open
shifts.
Software
Defined
Networking
to
do
that.
B
So
this
monolith,
when
I
load
this
into
my
browser,
it's
making
callbacks
to
itself
to
get
the
catalog
in
the
inventory
information
I
can
intercept
that
and
redirect
it
to
my
new
micro
services
through
Software
Defined
Networking.
So
let's
go
ahead
and
do
that.
So,
let's
shift
over
to
my
new
project
here,
what
I
want
to
do
is
create
what
we
call
a
new
route.
It's
a
path
based
route
which
allows
you
to
intercept
specific
calls
to
a
specific
host
name
and
path
and
redirect
those
to
different
services
running
in
my
cluster.
B
So
I
have
two
routes
here:
for
the
catalog
in
inventory,
I'm
going
to
create
a
third
route
called
redirect,
doesn't
matter
what
you
call
it,
the
hostname
is
going
to
be
the
host
name
of
the
monolith.
The
path
I'm
going
to
override
is
the
slash
services,
slash
products
path,
which
is
the
path
that
the
monolith
makes
a
call
back
to
itself
using
that
path
and
I
want
to
redirect
that
to
my
new
catalog
service,
which
in
turn
will
call
the
new
inventory
service
and
then
return
those
values
back
to
the
UI.
B
So
with
this
we're
out
in
place
now
any
call
from
my
monolith:
I
can
switch
back
to
the
monolith
and
experience
that
so
when
it
calls
back
into
itself,
it's
actually
being
redirected
to
my
new
microservices
in
getting
the
values
from
my
new
micro
service
and
the
corresponding
back
end
inventory
system,
which
is
controlled
now
by
an
independent
team
rather
than
the
monolithic
development
team,
and
so
I
can
now
essentially
continue
this
process.
I
can
take
the
price
service.
B
I
can
take
the
shopping,
cart
service
and
turn
those
into
micro
services
and
then
similarly
strangle
it
strangle
the
monolith
so
that
it
uses
these
new
services
and
then
ultimately,
I
can
turn
off
the
monolith
and
I
can
you
know
fire
all
the
developers
that
developed
it
and
then
move,
maybe
not
fire,
but
you
know,
find
different
jobs
for
them
and
and
and
continue
on
with
my
independently,
developed
and
fundamentally
autonomously
deployed
micro
service
teams.
Okay,
so
that's
it
for
the
demo.
So
again,
all
this
code
is
on
on
github.
B
If
you
want
to
have
a
look
and
there's
actually
a
solution
branch
in
there,
that
gives
you
the
solution
with
the
code
that
I
that
I
added
to
this
project
so
that
you
can
get
started
quickly.
The
solution,
if
you
want
to
see
exactly
what
I
did,
okay
so
switching
back
to
the
final
slide
here,
so
that
was
the
demo.
So
the
last
summary
slide.
So
while
fly
is
super
awesome
built
on
the
upstream
wildfly
java
ee
community.
B
Essentially
it
keeps
Java
EE
developers
in
the
game.
So
if
you
have
experience
with
Java
EE-
and
you
want
to
continue
using
that
in
a
micro
service
world
in
a
new
modular
cloud
native
world,
my
qualify
swarm
is
a
great
option
for
you
because
it
provides
that
path
forward.
It
also
implements
the
standards
like
micro
profile
and
which
has
a
huge
community
behind
it
and
a
lot
of
momentum,
and
we
see
great
things
coming
forward
with
wildfly
swarm.
Okay,
so
that's
it
so
I'll
check
out.
A
B
B
Good
remember
if
it
was
wild
fly,
swarm
examples
are
or
examples
so
there's
the
URL,
so
I
hid
it
on
my
browser
here
you
can
see
it
so
actually
I've
used
this
code
for
a
couple
of
other
things.
We
have
a
vertex
micro-service
and
a
spring
blue
microservice,
which
we
do
a
similar
process
for,
so
you
can
see
the
code
in
there
as
well,
but
here's
the
monolithic
code
which
you
can
deploy
to
to
any
OpenShift
or
kubernetes
using
fabricate
here's,
the
nodejs
inventory
and
the
wild
fly
storm
catalog
that
we
used
in
the
demo.
A
Well,
I
think
you
did
a
pretty
awesome
job
with
it
with
the
demo,
even
with
the
fonts
shrinking,
but
always
expand
our
screens
and
see
that.
Then
there
aren't
any
questions
in
the
chat
that
I
see
I'm,
giving
people
a
couple
of
minutes
to
ask
if
you
can
also
now
pop
back
into
year.
Thank
you
and
by
then
I
think
we're
are
almost
to
the
end
of
our
hour
and
we
will
probably
have
more
for
pots
coming
up
in
the
future.
A
B
A
All
right:
well,
we
look
forward
to
more
and
hearing
more
from
the
people
are
running
wild
like
swarm
or
building
applications
with
that
and
roar
and
want
to
talk
about
their
use
cases.
Please
let
me
know
and
I'll
give
you
the
podium,
because
we'd
love
to
hear
from
you.
Alright,
thanks
very
much.
Okay,.