►
From YouTube: An open platform to support digital transformation
Description
Hear from John Clingan, Sr. Principal Product Manager, Red Hat in this breakout session from Red Hat Summit 2017.
Enterprises are transitioning from on-premise, monolithic applications to highly dynamic, polyglot environments using microservices and cloud computing. In this session, we’ll discuss Red Hat OpenShift Application Runtimes, an application platform that runs legacy applications alongside greenfield polyglot microservices on Red Hat OpenShift, helping enterprises embrace microservices and cloud computing at their own pace. You'll learn the tradeoffs of microservices and monolithic architectures, as well as the costs and benefits of deconstructing a monolithic architecture. You'll also learn how legacy applications and greenfield applications written in Eclipse Vert.x, Java Platform, Enterprise Edition (Java EE) and MicroProfile, and Spring Boot can take advantage of a common set of cloud platform services for application interoperability, security, and manageability. With this knowledge, you can build a cloud roadmap that is optimized for your enterprise.
https://www.redhat.com/en/summit/2017/agenda/session
A
Alright,
some
of
you
must
work
for
startups,
because
some
of
you
are
reaching
your
hand
for
everything.
Okay,
how
many
are
managers
that
don't
really
code
a
whole
lot?
Okay,
so
okay-
and
this
is
always
a
tough
thing
right
about
an
audiences.
How
do
you
you
know
target
the
target?
The
audience
properly,
so
I'll
have
some
high-level
stuff
and
if
we
need
to
dig
down,
we
can
dig
down
I'll
be
happy
to
do
that.
So,
okay,
how
many
you
know
out
of
the
hundreds
of
you
in
the
audience.
You
know
because
this
is
being
recorded.
A
Nobody
can
really
see
how
many
are
in
the
audience
right,
so
how
many
in
the
audience
have
actually
heard
of
open,
shipped
application
run
times
a
couple
of
you,
okay,
so
just
for
the
record
is
probably
only
about
30
or
40
people
in
the
room.
So,
okay,
so
talk
about
the
OpenShift
application
run
times
and
there's
a
little
bit
of
you
know
context
around
some
operations,
some
context
really
the
end
of
the
day.
It's
it's!
A
Basically,
the
way
we've
been
traditionally
writing
applications.
If
you
think
about
whether
it's
dotnet
over
the
last,
you
know
decade
or
two
decades,
traditional
java
ee,
traditional
spring
framework,
the
way
developers
tend
to
the
right
applications,
kind
of
encouraged
by
the
runtimes
and
the
way
some
of
these
platforms
are
designed
is
to
create
monoliths,
and
that
is
I
basically
designed
this
application
to
include
an
awful
lot
of
functionality
right.
A
So,
if
you
can
think
of
a
retail
store,
it's
got
the
shopping
card,
it's
got
the
customer
and
for
me,
information
it's
got
the
bill
system
and
all
this
kind
of
stuff
pieces
of
that
are
all
kind
of
in
one
big
application
right
and
that's
kind
of
the
definition
of
a
monolith
and
that's
pretty
much.
How
I
think
a
majority
of
people
today
are
deploying
their
applications
is,
to
you
know
traditional
Java,
EE
application,
servers
or
dotnet
or
whatever
right
kind
of
these,
these
rather
large
feature-rich
platforms
and
what
these
platforms
tended
to
do.
A
Is
they
mix
the
idea
of
application
api's,
but
also
operations
right?
So
with
these
platforms
I,
can
they
provide
the
functionality
the
administration
functionality
to
manage
the
lifecycle
of
an
application?
I
can
deploy
an
application
and
able
it
disabled
it
on
deploy
it.
These
platforms
also
do
things
like.
Let
me
deploy
new
instances
of
the
platform
in
instances
of
an
application
server.
A
So
I,
can
you
know
if
I
have
a
server
farm
I
can
go,
deploy
a
new
instance
of
an
application
server
start
it
up,
and
then
you
know
so
that
way
I
can
deploy
applications
to
it.
So
there
is
all
of
this
kind
of
management
infrastructure
built
in
as
well
as
kind
of
a
programming
API
right.
So
that's.
How
would
you
know
have
been
developing
traditional
java,
ee,
traditional
Spring,
Framework
stuff
for
quite
a
while,
and
did
any
of
you
attend?
Rich
Sharples
talk
yesterday
kind
of
about
middleware
application
platforms.
A
It
was
one
of
the
first
presentations.
Okay,
I.
Definitely
recommend
and
I
have
a
slide
that
will
show
sessions,
but
if
you
go
and
watch
replays
definitely
kind
of
take
a
look
at
his
session,
because
this
provides
kind
of
an
additional
view
on
top
of
that
right.
But
the
idea
is
that
you
know
Java
EE
has
been
in
this
sense
maturing
right.
The
releases
aren't
as
frequent
as
they
used
to
be
and
traditional
Java
EE
application
servers
are
kind
of
designed
for
this
approach.
A
Where
you
have
you
know
the
administration
functionality
as
well
as
the
programming
API,
is
that
developer
use
all
all
built
together
and
it's
it's
it's
slowing
down
and
things
like
micro
services
are
picking
up
speed
right.
So
you
know
the
question
is:
how
do
we
go
from
monoliths
to
the
micro
services
architecture
running
in
the
cloud
and
the
nice
thing
about
JBoss
EAP
is
while
the
java
ee
market
is
basically
staying
relatively
constant
in
terms
of
overall
market
size
or
slightly
growing
it.
A
Maybe
3%,
JB
OCAP
is
really
growing
at
about
33%,
because
what's
happening
is
a
lot
of
customers
are
consolidating
their
Java
EE
runtimes
on
to
JBoss
EAP
right,
it's,
it's
very
flexible,
very
mature
and
much
more
cost
effective
than,
for
example,
Webster
traditional
WebLogic.
So
we
have
tools
if
you're
at
the
keynote,
you
even
saw
James
Falkner
talk
about
how
you
can
take
a
Java
EE
application
running
on
one
of
those
application
servers
run
it
through
a
tool
called
wind
up.
A
This
slide
in
detail
is
really
just
meant
you
to
show
that,
whereas,
in
the
past
application
servers
provided
all
this
administrative
functionality
what's
going
on
now
is
the
cloud
is
replacing
that
functionality
right
now.
The
cloud
is
the
tool
that
you
use
to
deploy
application
it's
the
tool
or
they
provide
the
tools
for
you
to
deploy
your
applications
right.
A
So
we're
shifting
the
administrative
responsibilities
from
a
product
like
a
Java,
EE
application
server
to
a
cloud
right
and
the
nice
thing
about
that
is
that
same
model
works
not
just
for
Java
EE
apps,
but
for
kind
of
any
application.
Runtime
right,
so
you
get
leverage
across
many
different
kinds
of
application:
runtimes!
A
A
These
large
monolithic
applications
into
many
smaller
pieces
and
the
idea
behind
splitting
them
up
into
smaller
pieces
is
that
I
can
then
divide
up
my
development
team
along
each
one
of
these
individual
pieces
and
they
can
all
move
at
their
own
pace
and
when
I
make
a
change,
whether
it's
a
bug
fix
or
a
major
new
feature.
I
can
deploy
that
at
my
own
pace,
whereas
with
a
model,
if
you
know
there's
this
case
where,
if
I
introduce
major
new
features,
all
the
other
people
working
on
all
the
other
functionality
get
really
nervous
right.
A
A
Performance
is
going
to
tank
because
if
I
have
all
these
services
crosstalking
on
the
network,
when
they
may
not
necessarily
need
to
you've
got,
you
know,
potentially
a
big
performance
problem
and
there's
other
architectural
problems
as
well.
So
the
idea
is
make
sure
you
have
your
model,
that's
right
before
entering
in
the
world
of
micro
services
and
again
having
the
model.
That's
right
means
make
sure
that
you've
modeled
your
business
correctly
inside
of
the
monolith
before
you
break
it
up
into
micro
services.
That's
the
idea,
so
there's
a
concept
of
the
majestic
monolith.
A
Monoliths
aren't
necessarily
a
bad
thing.
What
people
kind
of
think
on
the
downside
of
monoliths
potentially
is,
if
I
have
one
big
application.
It's
really
easy
for
me
to
have
all
of
these
different
pieces
of
the
application
become
intertwined
right.
It
becomes
really
hard
to
maintain
over
time,
because
you
know
things
like
schedules
tend
to
get
in
a
way
right.
A
I
need
this
feature
by
you
know
by
next
week,
and
if
you
don't
have
the
feature
by
next
week,
it
could
impact
the
business,
so
what
people
tend
to
do
is
take
shortcuts
and
when
you
take
shortcuts.
So
you
end
up
with
this:
what's
called
a
big
ball
of
mud
use,
this
monolithic
application
that
was
neatly
architected
over
time
tends
to
become
this
big.
You
know,
spaghetti
code
is
what
they
call
it.
A
So
the
majestic
monolith
basically
says
you
know
if
we
have
a
well
architected
monolith
and
we
split
up
our
teams
to
own
pieces
of
that
monolith,
the
monolith
isn't
necessarily
a
bad
thing.
It's
easy
to
debug!
It's
easy
to
develop,
there's
lots
of
benefits
to
a
monolith.
So
what
keeping
did
and
I
have
a
link
there
to
a
blog
post
that
really
kind
of
digs
into
what
Key
Bank
did?
Is
they
basically
kind
of
rewriting
their
entire
application
to
break
it
from
this
big
monolith
into
smaller
microservices?
A
What
they
did
is,
is
they
just
took
pieces
of
the
application
and
kind
of
microservice
enabled
it
where,
where
it
made
sense,
you
know
even
a
monolith
tends
to
talk
to
external
systems
right.
You
may
have
to
talk
to
the
air
P
system
from
your
application,
for
example,
and
there's
micro-service
patterns,
for
how
do
you
deal
with
failure
if
your
connection
to
that
ERP
system
goes
down
right,
there's
micro-service
patterns
that
even
apply
to
monoliths,
and
so
they
kind
of
refactored
some
of
their
codes
or
leverage
some
of
those
concepts.
A
They
also
adopted
OpenShift
in
kubernetes
as
a
container
platform
that
gave
them
a
lot
of
operational
efficiency
right
because
now
I
have
this
container
I.
Have
this
container
platform
and
I
could
rapidly
provision
new
new
to
new
applications
or
rapidly
upgrade
this
application,
because
they
went
from
this.
A
You
can
think
of
it
that
way,
and
that
also
means
you
know
with
great
freedom.
You
could
choose
what
you
want
to
do,
but
great
responsibility,
it's
your
job
to
keep
it
running
right
and
to
patch
it
and
all
that
stuff.
So
it
definitely
shifts
responsibility
around
and
they
also
got
to
as
part
of
going
to
one
week.
They
also
basically
got
rolling
deployments.
They
could
just
easily
upgrade
their
app.
A
Was
zero
downtime
right
leveraging
open
shipped
so
now,
let's
think
a
little
bit
about
adopting
micro
services
and
how
do
we
make
our
developers
more
productive?
So,
when
we
move
to
the
cloud,
we
really
get
a
lot
of
operational
efficiency.
Now
the
question
is:
how
do
I
make
my
developers
more
productive,
so.
A
There's
there's
various
ways
of
looking
at
parsing
that
right
when
I
move
from
you
know
a
monolith
to
a
micro
service,
the
idea
is
I'm
changing
the
way
I
develop
applications
I'm
going
from
again
the
Big
Bang
ball
of
features
to
decomposing
it,
and
these
may
very
small
siloed
applications
that
all
talk
to
each
other
and
that
allows
each
team
again
to
be
to
define
their
own
upgrade
path
and
release
cadence
right.
So
one
King
isn't
slowed
down
by
another
team.
A
You
get
a
lot
of
speed
out
of
that,
but
the
part
of
the
problem
is
think
about
it.
From
a
developer's
perspective,
I've
got
a
cloud:
that's
new,
probably
in
my
environment,
I'm,
moving
from
a
monolithic
application,
architecture
to
a
micro
services,
architecture
I
might
be
adopting
new
language
runtimes
right,
whether
it's
node
or
vertex
or
spring
boot,
or
whatever,
there's
a
lot
of
changes
that
developers
are
kind
of
dealing
with
all
simultaneously,
and
so
what
we
want
to
do
is
make
that
as
painless
as
possible.
A
So
what
are
the
paths
that
a
developer
can
take
to
become
more
productive?
Well,
if
I
have
a
traditional
java,
ee
environment,
I'm
running
I'm,
using
with
Java
EE
standards,
I'm
running
on
top
of
JBoss
EAP,
where
I
mentioned,
you
know,
if
it's
good,
if
it's
WebSphere
WebLogic
and
you
kind
of
Rijo
stit
on
EAP.
A
What's
the
path
for
me
to
get
the
micro
services,
that's
where
we
have
something
called
wild
fly
swarm.
While
sigh
swarm
basically
takes
the
pieces
of
JBoss
EAP
that
your
application
needs.
Maybe
they
only
needs
to
talk
rest
over
Network
into
a
database
and
that's
it
and
then
you
sprinkle
in
some
business
logic
right,
that's
relevant
to
the
problem.
You're
trying
to
solve
while
flies
form,
will
take
those
basically
pieces
of
the
application
server
package
it
along
with
your
application,
into
a
single
complete,
a
bowl
artifact,
a
jar
file.
A
Then
I
can
just
run
that
from
the
command
line.
So
what
we've
done
is
we've
taken
basically
Java
EE
and
turned
it
from
a
platform
where
you
write
your
application
and
deploy
it
to
the
application
server
to
actually
packaging
the
application
server
with
your
app
and
then
deploying
that
on
top
of
the
cloud
right,
so
we've
also
gone
the
extra
step.
A
We've
gone
the
extra
step
where
we're
now
working
with
adding
micro-services
technologies.
If
you
want
to
call
it
that
wild
fly
swarm
so
in
the
micro-services
world
there's
very
common
development
patterns,
how
does
one
service
locate
another
service
running
in
the
cloud?
It's
no
longer
at
a
single
IP
address,
necessarily
right,
because
you
have
these
services
coming
and
going
all
the
time
you
scale
them
up.
You
scale
them
down.
How
do
they
find
each
other?
A
So
another
one
is
how
do
I
deal
with
failure
if
I'm
breaking
this
application
up
into
many
pieces,
the
odds
of
one
piece
failing
go
up
right
so,
whether
it's
you
know
a
problem
of
the
application,
the
platform,
the
hardware
or
whatever
that
application
may
go
down.
So
how
do
you
deal
with
failure?
So
there's
something
called
circuit
breakers
and
bulkheads
way
to
deal
with
failures
in
your
environment
from
a
developer's
perspective.
A
So
what
we're
doing
is
we're
basically
solving
some
of
those
problems
from
a
micro-services
sense
in
wild
fly's
form,
so
extending
traditional
Java
EE
to
adopt
microservices
patterns
as
well,
and
you
can
combine
the
pieces
of
Java
EE.
You
need
with
the
Wrights
microservices
technologies
that
you
need
all
in
your
application
together.
It's
all
it's
all
very
seamless
and
the
Java
EE
pieces
are
built
from
you
know
upstream.
You
know
an
open-source
version
wildfly,
but
in
terms
of
product,
the
JBoss
Enterprise
Application
Platform.
A
Now
what
you
see
there
on
the
right
here
is
something
called
eclipse
micro
profile.
So
one
of
the
nice
things
about
Java
EE
is
it's
a
standard.
The
idea
is
that
you're
not
locked
into
one
vendor.
You
have
choice
and
the
fact
that
we're
actually
doing
really
well
at
rhe
hosting
competitive
application
server.
You
know
a
threatened
for
competitive
application.
Servers
on
JBoss
EAP
shows
that
a
lot
of
our
customers
are
executing
that
choice
right,
they're,
making
that
choice
that
we
host
their
app
and
that's
only
enabled
by
something
like
a
standard
right.
A
So
what
we're
doing
is
well
in
the
micro
services
world.
You
know:
Java
EE
wasn't
quite
moving
fast
enough
to
add
the
micro
services
technologies
to
the
standard
right.
It's
in
the
roadmap
well
see
if
it
gets
there,
but
we
didn't
want
to
wait.
So
all
of
these
Java
EE
vendors
were
going
off
trying
to
solve
the
micro
services
problem
and
that
began
to
kind
of
split
the
community.
So
we
had
the
wildfly
developers
that
were
developing
micro
services.
A
We
were
trying
to
introduce
easier
ways
to
write
micro
services,
same
thing
with
all
the
other
app
server
vendors
IBM.
Well,
almost
all
these
server
vendors,
IBM,
payara,
Tommy,
Evie,
and
so
on.
So
what
we
decided-
let's
not
split
this
Java
EE
community.
That's
worked
well
together
to
go
off
and
do
micro
services.
Let's
all
continue
to
work
together,
but
let's
do
it
in
an
open
source
manner
in
an
open
community,
and
we
could
have
done
it.
A
We
have
calls
every
week
any
one
of
you
can
join
the
calls
and
listen
in
any
one
of
you
can
join
the
micro
profile,
Google
Group
and
begin
participating
hey
how
do
I
bring
micro
services
into
Java
EE
lots
of
different
threads
about
all
these
micro
services,
things
that
you're
hearing
about.
We
even
have
now
kind
of
this.
This
subgroup
that's
off
kind
of
doing
the
marketing
around
this
right,
whether
it's
vendors
or
individuals.
So
at
the
end,
what
we
want
to
pop
out
is
more
standards
right.
A
So
if
standards
are
important
to
you
and
have
been
with
Java
EE,
this
is
how
we
get
the
standards
in
the
micro-services
sense
right
for
the
traditional
java
ee
community.
So
we
want
to
provide
that
safety
for
our
customers
moving
forward,
so
the
micro
profile
is
kind
of
a
way
to
accelerate
that
right.
A
So
micro
profile
is
an
open
source
community
kind
of
it's,
not
necessarily
a
standards
community,
but
we
are
working
on
specifications,
multiple
implementations
of
these
specifications
and
eventually
again
well,
what
we'll
look
towards
standardizing,
so
lots
of
vendors
are
involved
pretty
much
all
the
major
vendors
except
Oracle,
RightNow
and
they've
been
invited.
We
hope
to
join
so
another
path
that
you
can
take
is
you
know,
we've
heard
about
reactive
development.
We,
like
the
idea
of
reactive
about
development
and
reactive
development,
basically
means
I'm
developing
an
application
so
that
I'm
always
reacting
to
events.
A
Somebody
makes
a
request.
I
react
to
that
request,
execute
some
business
logic
and
return
a
response,
and
that's
built
throughout
the
entire
system,
same
thing,
with
a
connect
talking
to
a
back-end
ERP
system
or
talking
to
a
database.
It's
basically
a
way
of
doing
development.
That
is
very,
it's
considered
very
fast,
single
threaded.
You
know
for
your
developers,
it's
typically
you
don't
deal
with
multiple
threads
and
concurrency
issues,
it's
basically
an
environment
where
everything
is
kind
of
single-threaded
and
that's
designed
into
the
environment.
A
That's
a
path
to
get
the
micro
services,
another
path
that
some
of
you
may
be
taking
is
you
know
if
you're,
a
traditional
spring
shop,
Spring,
Framework
running
out
an
EAP
or
any
other
application
server.
Then
you
might
decide
that
spring
boot
is
the
way
that
you're
going
to
go
to
do
micro
services.
So
what
spring
boot
does
is
provide
a
very
opinionated
way,
meaning
they
define
this
well-defined
path.
If
you
program
along
this
path,
we've
defined
for
you
you'll
be
really
productive
right
and.
A
What
they
take
this
opinionated
approach
using
you
know
the
historical
spring
framework,
along
with
some
some
additional
blue
code
to
make
it
very
productive
and
we've
already
certified
spring
boot
with
some
of
our
technologies.
So
we
have
a
Java
image
that
runs
on
top
of
openshift,
for
example,
that
will
run
any
java
application.
We
certified
spring
boot
running
on
top
of
our
java
image
and
we've
also.
A
We
also
support,
for
example,
our
embedded
tomcat
container
within
spring
boo,
because
the
way
string
boot
works
is
it
needs
some
Java
EE
technology
just
to
get
off
the
ground
right
to
basically
even
boot
up,
and
so
we
support
some
of
those
Java
technologies
that
are
bundled
in
spring
boot.
And
what
you're
going
to
see
is
you
know
today?
It's
it's.
It's
just
the
servlet
container
Tomcat.
Whatever
time
you
going
to
see
more
and
more
pieces
of
our
Java
EE
technologies
being
supported
within
spring
boots,
so
things
like
hibernate,
cxf
or
arrests.
A
A
Now,
to
kind
of
introduce
you
to
something
that
we
announced
we,
the
press
release
go
out
yesterday,
on
this
the
red
hand
open
shipped
application
runtimes.
So
what
we've
kind
of
talked
about
very
generically
is
here's
a
path
for
you
to
go
from
where
you
are
today.
Maybe
it's
Java
EE,
maybe
it's
spring
to
potentially
other
language
runtimes
that
are
doing
you
know
micro-services
style
development
and
that's
doing
quick
time
check
here.
A
Okay,
so
Red,
Hat,
OpenShift
application.
Runtimes
basically
either
supports
these
language
runtimes
in
the
case
of
JBoss
EAP,
while
applies
warm
vertex
we're
actually
bringing
goes
to
market
through
the
openshift
application
runtimes
and
around
spring
boot
I
mentioned.
We
don't
actually
support
the
spring
boot
bits
themselves,
but
we've
certified
spring
boot
well,
you'll
see
is
certifying
more
and
more
of
the
spring
bootie
ecosystem,
but
we
do
support
pieces
of
spring
boot
that
rely
on.
You
know,
technology
that
we
already
have
right.
A
So
you
can
run
your
beat
your
spring
boot
applications
on
openshift
and
we
want
to
make
it
basically
easy
drop
in
for
spring
boot.
Applications
running
on
openshift
with
basically
no
work
at
all
right.
You
just
change
your
configuration
file
in
free
developers,
a
pom
file
change
your
dependencies,
and
things
should
just
run
now.
What
does
this
really
mean?
So.
A
Openshift
itself,
kubernetes
right,
open,
shipped,
is
layered
on
top
of
kubernetes
kubernetes
and
open
ship
provide
an
awful
lot
of
features
that
are
relevant
to
development
to
developers
and
things
like
I
mentioned
before.
How
do
I
do
service
discovery?
Well,
that's
a
capability
built
in
the
openshift.
How
do
I
do
load
balancing
that's
already
taken
care
of
by
OpenShift?
How
do
I
do
extra?
How
do
I
externalize
my
configuration
right?
A
So
if
I,
if
I
I,
want
to
keep
my
configuration
of
my
application
separate
from
the
application
itself
right,
so
I
externalize
it
somewhere
I
need
to
store
that
configuration
somewhere.
It's
built
in
the
openshift
and
kubernetes
right
through
something
called
config
map.
So
what
we're
doing
is
we're
actually
integrating
these
language
runtimes
with
kubernetes
we're
doing
that
work
or
either
modifying
our
existing
implementation,
adding
new
frameworks,
whatever
it
takes
to
kind
of
make
running
these
runtimes
on
top
of
open
ships
and
kubernetes
as
natural
as
possible?
A
Ok
and
taking
it
kind
of
the
next
level.
We're
also
doing
that
same
thing
with
our
other
middleware.
So
if
you
want
to
run
a
cache
or
distributed
data
grid
inside
of
OpenShift,
we
want
to
make
it
as
simple
as
possible
for
your
application
to
discover
where
that
cache
is
and
be
able
to.
You
know,
put
data
in
and
out
of
that,
cache
make
it
as
simple
as
possible,
pretty
seamless
right
we're
already
doing
that
with
Red
Hat
SSO.
A
So
you
can
secure
your
restful
endpoints,
for
example,
with
Red
Hat
SSO
and
provide
kind
of
a
single
sign-on
functionality,
and
that's
that's
something
that
we've
already
done
to
work
on
and
we're
going
to
continue.
Basically
integrating
all
of
these
language
runtimes
into
the
Red
Hat
middleware
all
running
on
top
of
open
shipped
right.
So
we
have
kind
of
our
backlog
or
list
of
things
to
do.
Include
the
logging
system
of
openshift
API
management
with
rescale
ActiveMQ
for
messaging
right.
So
we
just
we're
just
getting
started
right
with
the
SSO.
A
A
So
if
you
have
these
services
running
in
this
large
cluster,
with
hundreds
of
hundreds
of
physical
servers-
and
you
don't
know
where
these
your
actual
software
instances
are
running
of
your
set
of
your
application,
how
do
you
trace
the
paths
of
all
these
requests
so
that
as
they
go
from
service
to
service
or
service?
How
do
you
know
where
the
bottleneck
is
right?
So
this
is
functionality
that
we're
building
right
now,
so
application
performance
management,
APM?
A
Basically
we'll
do
that
kind
of
distribute
tracing
for
you
and
help
you
figure
out
where
performance
bottlenecks
are
along
with
leveraging
hawker
metrics,
which
is
basically
a
way
of
acquiring
metrics
of
all
your
services
and
storing
them
into
a
database.
So
you
can
go
back
and
kind
of
do
on
an
on
a
service
by
service
basis,
go
back
and
do
kind
of
performance
analysis
and
then,
as
I
mentioned,
we're
all
can
be
doing
some
certification
work.
A
So
I
mentioned
spring
boot,
but
that
also
includes
some
of
the
other
open
source
technologies
like
Netflix,
OSS,
hysterics,
and
so
many
developers
may
know
this
for
basically
providing
circuit
breaker
functionality,
but
also
the
history
dashboard
so
that
you
can
actually
take
all
you
know
understand
where
the
failures
are
track.
The
failures
all
through.
A
What's
a
hitch
history,
dashboard
same
thing
with
ribbon
and
client
side
load,
balancing
for,
for
example,
spring
boot,
and
if
there's
other
open
source
frameworks
that
you
think
are
important
to
your
business,
then
we'll
look
at
certifying
those
as
well
right
I
mean
that's
kind
of
you
know
the
value
that
RedHat
offers
right
is
you
can
work
with
us?
We
can
work
with
you
and
help
you
well.
You
can
help
us
yeah.
We
can
help.
You
basically
pick
the
right
set
of
you
know:
where
should
we
certify?
Where
should
we
build
right?
A
A
Basically,
you
don't
have
to
assume
that
well,
if
I'm
running
on
top
of
open
ship
and
I
have
to
be
doing
new
micro
services,
development
right
and
that's
what
it's
good
for,
no,
you
can
actually
take
your
existing
applications
like
we
talked
about
and
run
it
on
top
of
openshift,
and
that
actually
might
be
a
good
idea
for
a
lot
of
your
applications.
If
you
have
applications
that
aren't
that
that
don't
have
to
be
updated
very
often,
they
don't
maybe
perform
a
critical
business
function
and
they
work.
A
Just
fine,
then
keep
miss
mountainous,
just
lift
and
ship
and
run
em
on
OpenShift.
The
other
thing
is:
if
you
look
at
the
big
picture
with
open
ships
itself
and
the
application
runtimes,
we
support
multiple
application
architectures.
So
we
support
monoliths
fast
moving
monoliths
like
that
Key
Bank
example,
where
they've
taken
a
monolith
and
moved
it
to
basically
a
weekly
release.
Cadence
we
support
micro
services
and
we're
even
working
on
server
lists
right.
So
how
do
we
do
serverless
on
top
of
open
ships
as
well?
So
we
can
support
multiple
application
architectures.
A
Obviously
we
support
multiple
programming
languages
or
programming
runtime,
so
I
mentioned
spring
boot,
vertex
wildfly
swarm,
JBoss
EAP
we're
going
to
be
doing
node
at
some
point.
That's
in
our
plans,
hopefully
later
this
year
again
all
integrated
with
openshift
services,
whether
it's
the
middle,
we're
running
on
open
shift
or
open
shift
itself
right.
So
we're
providing
you
in
a
very
rarely
do
I
run
into
a
customer.
A
That's
running
just
one
thing:
they're
not
running
just
bring
booth
they're
not
running
just
Java
EE
they're,
not
running
just
dotnet
or
whatever
they
have
multiple
runtimes
in
their
environment
and
the
idea
is.
We
want
to
make
it
as
painless
as
possible
for
you
to
take
those
applications
and
those
that
experience
that
you
have
the
developer
experience
the
operational
experience
as
much
as
possible
and
bring
that
over
to
OpenShift.
A
So
we
launched
something
pun
intended
yesterday
called
launched,
open,
shipped
IO,
and
if
you
go
to
launch
at
OpenShift,
IO
and
you're,
a
developer
which
is
which
is
what
this
is
geared
toward,
you
can
sign
up
for
early
access
to
basically
running
these
language
runtimes
running
examples
that
we
have.
We
call
them
missions,
I,
use
cases,
predefined,
use
cases
like
securing
a
restful,
endpoint
or
doing
a
health
check,
so
open
ship
can
detect
when
an
application
is
unhealthy
and
restart
it.
Well,
on
the
other
side,
an
application
wants
to
provide
to
openshift.
A
Perhaps
it's
view
of
whether
or
not
it's
healthy
right,
and
so
we
we
basically
provide
that
that
link
with
with
the
integration
work
that
we've
done.
That
I've
mentioned
before
and
there's
examples
about
how
to
do
health
check,
and
they
said
you
know,
within
the
application,
expose
the
health
of
the
application
to
the
runtime.
That
there's
examples
for
that
right
and
so
on
and
right
now
it's
early
access.
You
get
on
the
early
access
list.
If
you
go
there
and
then
you
will
have
a
completely
online
development
experience
right,
you
can.
A
A
It
then
take
it
and
deploy
it
inside
of
a
continuous
delivery
pipeline
inside
of
openshift
right
all
with
just
a
couple
of
clicks,
which
is
really
nice
and
you
know
because
it's
not
quite
available
yet
we
also
have
the
ability
for
you
to
do
this
yourself
locally
on
your
desktop.
Using
something
called
mini
shift,
mini
shift
is
mini
shift
is
basically
open
shift
running
on
your
desktop
right.
A
It's
really
easy
to
set
up
and
install,
and
you
just
basically
say
mini
shift
start
and
it
just
downloads
everything
it
needs
to
download
and
you're
up
and
running
with
it
with
the
open
shift
and
then
what
we
do
is
we
provide
you
instructions
to
basically
go
off
and
download
this
online
experience.
It's
actually
pretty
easy.
All
you
do.
Is
you
fill
out
a
form
with
just
a
couple
of
pieces
of
information
and
it'll?
A
So
it's
a
really
good
way
of
developers
to
take
a
look
at
how
these,
how
we've
integrated
these
language,
runtimes
into
OpenShift
and
I,
should
also
bring
up
that
OpenShift
online
starter
does
have
a
one
gigabyte
limit,
which
means
we
can't
run
all
of
our
examples
in
OpenShift
online
because
they're,
you
know
some
of
them
have
databases
and
stuff
like
that.
So
you'll
get
a
subset
of
what
we
offer.
A
If
you
take
the
online
experience,
if
you
download
it
locally,
then
you
basically
get
all
of
our
examples
right
and
what
we
have
OpenShift
online
available
and
a
broader
sense
with
you
know,
paid
levels
and
all
that
then
you'll
be
able
to
run
all
of
them
online
as
well.
It's
just
that
the
starter
has
a
one
gig
gig
of
ram
limit,
so
just
for
the
developers
in
the
room.
If
you
want
to
see
everything,
consider
downloading
full
mini
ships
experience
as
well.
A
Alright,
we
are
conducting
a
survey.
If
you
could
take
a
picture
of
this,
if
you've
already
seen
this
in
other
sessions,
you
don't
have
to
take
the
survey
again.
It'd
probably
ruin
our
data
right.
If
you
did
that,
but
the
idea
is
we
want
to
find
out
where
you
know,
are
you
still
doing
Java
EE
development,
if
you're
doing
some
java
ee
but
you're
also
moving
to
other
language
runtimes?
What
are
you
moving
to
it's
those
kind
of
questions?
It
basically
helps
us
to
find
our
roadmap
for
what
we
should
be
doing.
A
Based
on
what
you
want
us,
what
you
want
to
do
right.
We
want
to
make
sure
that
we
can
support
you
as
best
as
possible.
So,
for
example,
do
we
need
to
add
another
language
runtime?
You
know
stuff
like
that.
This
just
helps
us
out
with
our
planning,
and
data
is
king
with
that
kind
of
thing,
so
there
are
other
sessions
for
for
you
to
hear
about
application
platforms.
A
Unfortunately,
a
couple
of
them
already
passed
I
made
a
reference
to
rich
sharp
old
presentation,
but
these
are
all
going
to
be
recorded
right.
So
you
can,
you
can
go
watch
these
I
think
it's
going
to
be
on
YouTube.
You
know
you
can
go
watch
them
online
and
if
you
happen
to
miss
the
session
while
you're
here
so
the
ones
I
want
to
point
out
is
there
is
a
hands-on
lab
for
how
you
go
from
Java
EE.
A
My
monolith
to
a
wild
fly
swarm
kind
of
micro-services
transition,
there's
a
hands-on
lab
later
today
on
that
there
are,
if
you're,
interested
in
Java
reactive
systems.
We
have
a
talk
on
vertex
tomorrow,
there's
also
one
competing
with
the
session
that
competes
with
the
session
Ken
and
I.
Here
we
have
some
of
the
team
in
front
are
doing
on
well
fly
swarm
in
micro
profile
it
it's
really
developer.
Talk
right.
Both
of
those
are
developer
talks,
so
we're
going
to
show
code
show
examples.
A
You
know
IDE
stuff,
like
that
rich
Sharples
will
be
doing
a
function
as
a
service.
Basically,
serverless
talk
tomorrow
as
well,
and
then
there's
also
another
vertex
presentation
in
the
afternoon
on
Thursday.
So
we've
talked
about
some
of
these
these
runtimes
and
now
you
can
go
actually
look
at
them
in
a
deeper
level
or
even
get
some
hands-on
with
it
right,
there's
even
oh
it
missed
it
was
yesterday.
There
was
also
one
on
spring
Boonton
spring
cloud
running
an
open
shift
right.
So
there's
a
session
on
that
as
well.
A
A
Me
shift
good
question
is
many
shift
available.
Many
shift
is
available
if
you
go
click
on
people
to
launch
that
open
shift
at
I/o,
and
you
want
to
try
this
out
online
I'm
sort
of
trying
to
tell
locally
there's
a
link
where
you
can
go
to
the
instructions
and
in
that
link
is
instructions
on
how
to
install
mini
shift.
Now,
just
be
aware
that
we've
done
our
testing
with
this
on
beta
5
mini
shift
was
like
really
mini
shift,
one
that
was
released
yesterday.
I,
don't
know
if
we've
actually
done
the
testing
on
it.
A
Yet
so,
if
you
want
to
try
it
in
this
context,
use
beta
5
every
one.
If
you
want
to
try
a
mini
shift
just
very
generally,
then
you
could
try
one
dot.
Oh,
it
says
that
in
the
instructions,
okay
thanks
so
just
be,
especially
especially
we're
not
worried,
but
careful
about
that
so
I
thought
maybe
I'd
just
do
one
one
quick
thing
showing
you
a
little
bit
of
the
get
started
experience.
Is
there
any?
Are
there
any
other
questions?
We
have
a
couple
minutes
you
have
left.
Yes,.
A
So
the
question
is,
you
know
when
it
comes
to
Java,
EE
or
wild
fly
swarm,
which
is
kind
of
Java
EE
and
with
micro
services
and
and
spring
boot.
Are
we
seeing
these
as
two
totally
separate
things
that
we're
going
to
work?
Are
we
going
to
consider
them
working
together,
collaboratively
running
inside
of
openshift
good
question,
so
one
of
the
things
that
we
definitely
want
to
do
is
we're
running
these.
A
So
one
of
the
things
that
we
want
to
do
some
testing
around
is
how
does
the
spring
Buddha
app
discover
a
wild
fly,
swarm
app,
and
maybe
you
know
you
deal
with
these-
the
failure
use
cases
like
circuit
breakers
right,
but
between
these
things
to
be
honest,
if
it's
all
just
jax-rs,
it
shouldn't
really
be
that
complicated
right,
because
it's
all
just
HTTP,
but
if
you
have
specific
use
cases
that
you
think
we
that
we
should
be
addressing.
Definitely
let
us
know,
but
we
aren't
seeing.
A
We
definitely
aren't
seeing
these
things
as
very
vertical
stacks
along
the
language
runtimes,
as
I
mentioned,
we
expect
customers
to
be
deploying
not
just
one
of
these
things
in
their
environment
there.
We
expect
them
to
do
multiple
language
runtimes,
it
might
be
it's
a
big
organization.
Different
parts
of
the
organization
chose
different
ways
of
doing
it.
It
might
be
dealing
with
acquisitions
where
your
acquire
a
company
that
uses
a
different
technology
so
yeah.
We
definitely
want
to
make
sure
that
these
things
do
talk
to
each
other
all
running
on
openshift.
In
this
way.
A
So,
let's
see
how
we
doing
on
time
all
right.
Just
one
quick
thing:
I'll
show
you
this
is
especially
for
the
kind
of
developers
this
is
actually
openshift
running
in
mini
shift
on
my
desktop,
and
this
is
about
4
gigs
of
ram,
and
I
could
deploy
lots
of
these
examples.
Probably
at
least
three
of
these
examples
running
an
open
shift
on
my
desktop
I'm,
not
going
to
run
through
the
higher
experience
per
se,
but.
A
That
is
a
project
called
basically
Launchpad,
and
that
project
is
basically
a
bunch
of
containers
running
parts.
Well,
you
might
say
that
launchpad
itself
is
a
collection
of
micro
services
right,
and
so
what
I
did
is
that
is
click
clicked
on
the
link
to
the
front-end.
For
this
experience
and
as
you
can
see,
we've
got
the
three
runtimes
you'll
eventually
see
nodejs
pop
up
here
and
what
I
can
do
is
actually
go
on
to
the
next
screen.
A
I
apologize
that
some
small
text,
but
basically
on
the
left
hand
side,
it
says:
do
you
want
to
do
this
entire
development
experience
online
or
you
do
it?
Do
you
want
to
download
the
zip
file
locally
and
just
try
it
out
on
your
desktop
without
you
know,
having
kind
of
the
end-to-end
experience,
so
if
we
choose
the
end-to-end
experience,
I
got
to
log
in
so
the
nice
thing
is
this
actually
ties
into
SSO
right
and
what
they
want
to
do
is
in
this
case.
Okay.
A
A
We
have
a
database
example.
How
do
I
externalize
configuration
the
health
check?
I
mentioned
secure,
an
endpoint
with
read
ahead
SSO
in
this
case.
It's
just
a
simple
database
example:
I
choose
the
application
run
time.
Let's
say:
I
choose
wild
flies
form
I
got
the
team
here
in
front
of
me,
so
I
got
I
got
to
do
that.
I,
add
a
project
name,
we'll
call
it
swarm
crud
session,
because
this
is
a
database
kind
of
crud
app
create.
You
know
we
move
up
a
bleach
or
whatever
and
then
I
could
actually
launched
this
on
openshift.
A
So
it's
actually
a
go.
Take
this
project
fork
it
to
my
github
account,
which
means
over
time
even
after
I
run.
This
example.
I
go
to
my
github
account.
Make
changes
to
that
application.
Extend
it
do
neat
things
with
it,
try
things
out
and
then,
when
I
say
that,
if
I
make
a
commit,
it
actually
kicks
off
the
continuous
delivery
pie
line
and
actually
deployed
the
app
on
a
commit.
So
one
really
quick.
Let's
see
if
I
can
do
this
here,
I.
A
A
This
is
the
continuous
delivery
pipeline
all
running
on
OpenShift,
and
this
is
the
actual
you
know,
UI.
That
kind
of
shows
it
now
I
go.
Look
at
the
code.
I
can
understand
how
we've
how
we've
actually
made
this
run
on
OpenShift
and
it
kind
of
work.
You
know
any
kind
of
configuration
that
you
might
need
to
do
over
time.
We
want
to
reduce
as
much
of
that
configuration
as
possible,
so
we
really
want
to
make
it
easy
right.