►
From YouTube: OCB: Counting on the Cloud: Cloud Native Transactions and IBM Cloud Pak® for Applications
Description
In a hybrid cloud world, transactional workloads are mostly running today as highly resilient monoliths. In all its forms, hybrid cloud facilitates flexibility and portability for applications and data.
This session looks at the changing nature of how applications will use cloud native transactions in the cloud and how IBM is planning to simplify building, running, and managing these new cloud native transactions with IBM Cloud Pak for Applications.
Guest speaker: Ian Robinson, Distinguished Engineer, CTO IBM Application Platform
Ian is responsible for the technical strategy of IBM Application Platform products, including IBM Cloud Pak for Applications and WebSphere, and for innovation delivered through community projects like Open Liberty. He leads numerous globally-distributed engineering teams and works with a wide variety of industry partners. Ian is a founder member of both the MicroProfile and Jakarta EE projects at Eclipse, which are helping define the future of Java for the cloud.
A
Good
morning,
good
afternoon,
good
evening,
I
am
very
happy
to
welcome
you
to
today's
developer
experience
office
hours,
we're
going
to
be
talking
about
the
service
binding
operator
this
morning
and
this
morning
this
afternoon,
wherever
you
may
be,
I'm
chris
short
principal
technical
marketing
manager
at
red
hat.
I
am
using
my
standing
desk
today
because
standing
is
good
for
you,
but
I'm
joined
today
by
several
friends
of
mine.
Let's
just
go
around
the
horn
ryan
I'll
start
with
you
ryan.
Please
introduce
yourself.
B
C
C
D
B
A
B
Now
they
get
a
list
of
labels
slapped
on
them
and
if
you
do
linking
with
odo
there's
also
additional
labels
that
show
up,
and
these
this
labeling
scheme
is
consistent
with
how
the
sig
apps
effort
and
other
folks
in
the
upstream
community
have
kind
of
elected
to
do.
Markup
for
microservices
that
are
are
part
of
a
collection,
and
so
the
service
binding
operator
is
intended
to
work
within
those
kind
of
expectations
that
the
community's
been
putting
out
and
set
up
labels
and
other
expose
other.
B
You
know
other
content
into
the
running
pods
so
that
they're,
aware
of
each
other
and
have
more
support
and
more
more
than
just
the
native.
What's
the
coupe
dns
kind
of
service
discovery
which,
if
you
already
know
the
service
name
of
another
microservice,
you
could
try
to
target
it
directly,
but
that's
also
a
lot
of
knowledge
that
you
may
want
to
distribute
in
a
more
clear
and
concise
way
and
putting
them
in
via
labels
or
a
secret
or
other
details
like
that.
Can
help
make
it
happen.
B
B
B
B
A
B
How
about
this
does
anyone
want
to
volunteer
to
drive?
If
not,
I
will
do
my
best
to.
I
am
already
logged
in
in
a
cluster,
and
I
can
see
if
I
can
set
up
my
screen.
Sharing
I've
been
having
some
issues
with
silver
blue,
but
I
can
give
it
a
test
unless
there's
any
other
volunteers
in
the
in
the
channel
here.
B
A
B
A
A
B
You
know
I've
been
warned
in
the
past
and
I
haven't
actually
done
the
log
out
and
logged
back
in
yeah
deal.
Yet
I'm
I'm
actually
very
happy
with
this
silver
blue
setup
overall,
but
there
are
a
couple
times
where
you
want
to
go
and
customize
things
and
it
encourages
you
to
stick
with
good
practices
for
security
and.
E
C
A
B
A
C
E
A
B
C
B
C
I'm
logged
into
my
openshift
cluster,
that's
running
on
bare
metal
and
I
was
playing
with
this
a
little
bit
already,
so
I
have
a
project
set
up
and
I
think
probably
the
easiest
way
I'll
just
show
the
simplest
service,
binding
operator
demo
ever
and
I'll
show
you
how
this
is
going.
We
could
figure
out,
you
know
if
we
want
to
make
it
more
complex
later.
You
know
as
we're
going,
but
just
to
get
an
idea
of
what
this
does
for
you
is.
It
removes
some
of
this
complexity
of
thinking
about.
C
Well,
I
have
an
app
that
I
built
it
needs
to
talk
to
a
database.
I
need
all
of
these
things.
I
need
credentials.
I
need
ip
addresses.
I
need
all
of
these
things
that
that
you
know
are
related
to
connecting
to
the
database
right.
So
I
have
an
app
it's
a
node.js
app,
that's
running.
I
I
deployed
this
using
this
add
button
here
and
I
deployed
from
git
in
here
I
just
put
in
the
git
repo
url
and
it
automatically
decided.
This
is
an
ojs
app
from
there.
I
didn't
change
anything
else.
C
C
E
C
C
B
C
B
But
we
want
to
try
to
give
you
best
practices
on
what
labels
make
sense
from
other
folks
perspective
within
the
kubernetes
community.
So
I
think
what
we're
giving
you
most
likely
in
the
open
shift.
Catalog
is
things
that
are
a
mix
of
what
is
consistent
with
upstream
plus,
probably
a
little
bit
of
embellishment,
just
to
give
you
additional
meaning
to
what
you're.
Looking
at
and.
E
C
A
So
serena's
pointed
out
a
ton
in
chat
right
like
you,
if
you
use,
if
you
are
using
the
import
from
git
flow,
there
are
things
that
are
automatically
generated
by
the
console.
For
example,
a
label
is
applied
that
says
yes,
this
was
generated
by
the
console,
as
well
as
the
application
that's
associated
with
it,
and
it
looks
at
the
run
time
to
apply
that
label
and
define
the
logo
into
the
topology
view.
So
yeah
there's
a
lot
of
analysis
happening
when
you
do
that
import
from
git
to
apply
labels
too
so
yeah.
C
You
could
also
custom
as
you're
putting
them
in
if
you
have
custom
ones
that
you
want
to
add,
you
could
add
them
in
here.
There
was
a
little
label
button
that
I
clicked
down
at
the
bottom,
the
very
end
of
the
deployment
and
then
here
I
could
specify
label
one
equals
test,
for
example,
and
that
would
pop
up
in
there.
C
So
you
would
see
that
if
you,
if
you
haven't
seen
that
so
that's
the
app
the
app's
deployed
and
like
I
said
it's
just
a
simple
app,
it's
looking
for
database
if
it
doesn't
have
one,
it
still
works,
but
I
can't
really
add
a
fruit
to
my
application
that
I
have
right.
It's
not
going
to
work,
it's
going
to
give
me
an
error.
So
that's
the
problem.
Obviously,
there's
no
database
connection.
I
didn't
specify
anything
about
a
database
just
the
app
whenever
I
developed
it
or
whenever
you
know
whoever
developed
it.
C
C
The
next
part
was
deploying
a
postgres
sql
database
and
what
I
did
was
I
installed
a
operator
to
deploy
databases
there's
details
on
how
to
do
that
in
a
link
that
I'll
share
out.
That's
part
of
the
documentation
for
the
service
binding
operator,
but
basically
what
it
lets
me
do
is.
If
I
go
into
the
administrator
view,
I
can
see
the
installed
operators
that
I
have,
and
I
can
see
that
I
have
a
postgres
sql
database
operator,
that's
available
to
me
right.
C
C
B
A
B
C
A
C
Can
check
that
real,
quick
that
is
available
that
that
that
will
be
available
in
operator
hub
so
just
search
for
service
binding
operator,
and
that
is
there
it's
a
community
operator,
but
it
is
available
on
the
operator
hub.
You
don't
have
to
add
any
additional
operator
sources
and
on
here,
when
you
install
it,
it
will
ask
you
hey:
do
you
want
to
install
this,
for
all
namespaces
is,
which
is
what
I
did
yeah.
B
Yeah
yeah,
but
this
often
is
going
to
be
something
that,
as
if
you're
on
a
team,
that's
working
towards
an
open
shift
environment.
Hopefully
you
can
expect
that
your
whoever
set
up
the
clusters
for
you,
if
you're
in
a
large
corporate
environment
most
likely,
has
already
installed
and
enabled
this
service
binding
operator.
If
it's
a
prerequisite
of
part
of
your
workflow,
if
not
talk
to
your
admins,
make
sure
they
know.
This
needs
to
be
pre-installed
on
on
clusters,
where
you
do
your
work,
it'll.
E
A
C
Yeah
exactly
that
way,
they
don't
have
to
deal
with.
You
know
connecting
things
doing
the
things
that
operators
do
and
if
you
do
have
access.
So
you
know
you're
working
on
openshift.
The
way
to
find
out
is
within
your
namespace
that
you're
creating
or
your
project
on
here
you
could
see
these
are
all
of
the
operator
or
sorry,
the
cluster-wide
operators
that
are
available,
and
I
could
roll
out
that
are
installed
on
the
cluster
that
I
have
running
over
here
right.
So
I
went
and
installed
these
operators
already.
C
So
if
I
need
the
service
binding
operator
well
there
you
go
it's
available
for
me.
If
I
need
camel
k,
if
I
need
post
across
the
database
like
what
I
used
earlier,
I
could
roll
that
out
with
an
operator
that
was
already
pre-installed.
So
that's
that's
how
this
list
already
you
know,
has
a
couple
different
things
that
are
in
here.
B
C
I
will
say
the
one,
so
the
one,
the
one
thing
with
operators
in
openshift
that
you
have
to
think
about
at
least
right
now.
You
know
maybe
olms
you're
working
on
getting
smarter.
It
does
a
ton
which
is
awesome,
but
so
I've
started
out
with
a
4.4
cluster
and
you
can
see
I've
done
a
couple.
Different
updates
here.
Everything's
went
smoothly,
no
problems,
I'm
on
five
or
4.5
right
now,
yeah.
F
C
How
I
did
that
was
I
changed
the
channel.
I
don't
want
to
take
up
too
much
time,
but
I
just
switched
the
channel
and
did
the
update
talking
about
operators
that
happened.
Cluster,
updated
everything
worked,
the
the
the
services
and
things
like
that
that
I
had
worked
no
big
deal,
but
I
do
have
a
couple
different
operators
that
are
dependent
on
the
version
of
openshift
that
I'm
running.
So
this
is
something
for
the
admins
of
openshift
clusters.
Make
sure
that
you
watch
out
because
I'm
not
sure
how
widely
this
is
known
for
everything.
C
C
So
even
though
they're
the
same
version
of
the
thing
there
could
be
some
differences
at
some
point
right
so
make
sure
that
you
also
double
check
the
operators
you
install
and
make
sure
that
the
versions
match
together.
Not
all
operators
are
like
that,
though,
so
make
sure
that
you
pay
attention
the
serverless
one
is
one,
for
example,
but
say
the
service
mesh
one
just
has
a
stable
channel.
So
that's!
Okay!
You
don't
have
to
deal
with
it
when
you
do
a
major
upgrade
with
openshift,
which
just
recently
happened
on
mine,
because
openshift45
came
out.
C
A
C
A
C
Agreed-
and
that
being
said,
sometimes
you
don't
have
the
option,
so
the
pipelines
operator
has
not
been
updated
yet,
or
at
least
my
cluster
hasn't
gotten
that
update,
I'm
pretty
sure
it
hadn't
been
updated
yet
with
a
new
channel
right,
so
I
still
have
to
use
the
4
4.
You
know
older
channel,
I
guess
which
is
the
current
channel,
but
anyways
it's
it's
somewhat
confusing
right
now,
but
things
you
know.
C
C
Of
that
stuff
being
said,
I
have
the
service
binding
operator
installed
cluster
wide.
You
can
see.
I
got
a
couple
different
things
running
in
this
operator's
project.
Let
me
switch
back
over,
so
I've
got
all
of
the
the
the
service
binding
operator.
I
have
my
application
that
I
just
copied
the
get
repo
in
and
had
open
shift
build
it,
and
then
I
deployed
a
postgres
sql
using
the
operator.
E
C
G
C
Why
not
you
can
see
what
it
looks
like,
so
this
is
the
one
that
we
don't
want
at
least
as
at
the
moment,
we'll
see
we'll
see
how
this
stuff
ends
up,
but
you
can
see
visual
connector,
that's
not
the
one
you
want.
We
want
a
binding,
connector,
so
anyways
I'll,
create
that
binding
connector.
You
can
see
that
that
app
is
going
to
things
are
happening.
C
A
A
The
order
of
operations
was
service,
binding
operator.
Oh,
you
created
a
name
space.
First
of
all,
you
installed
the
service
binding
operator.
You
installed
a
node.js
app,
you
installed
a
postgres
operator
and
then
you
just
drag
and
drop
the
connection
over
and
it
should
have
all
the
info
needs.
That's
it
is
it
running.
Is
it
working?
That's.
A
B
H
B
B
F
C
B
A
Chat,
so
you
can
get
a
free
copy
of
the
book.
Just
go
to
the
you
know
if
you're
in
chat
right
now
just
go
to
that
link,
get
a
free
copy
of
josh
and
jason's
book.
It's
a
fantastic
book.
I
have
a
copy
of
it.
Now,
thanks
to
brian,
I
use
it
routinely
to
find
and-
and
you
know,
figure
out,
operatory
things
so
yeah.
It's
it's
pretty
awesome.
F
Right
on,
thank
you
chris.
I
I
do
hope
it's
useful
and
I
think
especially
there's
some
some
really
hands-on
stuff
in
the
middle
chapters
about
building
these
things.
Interestingly,
today's
topic
is
one
of
the
things
that
that
is
to
say,
the
service
mining
operator
is
sort
of
this
idea
of
an
advanced
feature
that
we
built
on
top
of
some
of
this
operator
machinery
that
we
would
have
loved
to
examine
in
the
book.
F
But
really
the
feature
wasn't
complete
enough
in
time
to
match
the
book
schedule
and
we
wanted
to
focus
the
book
down
really
on
that
basic
operation
of
building
things
in
it
with
the
helm,
ansible
and
golang
support
in
the
red
hat
operator,
framework
and
sdk,
so,
hopefully,
or
possibly
in
the
future.
We'll
do
an
expansion
into
a
second
edition
or
even
another
volume
that
that
focuses
on
kind
of
this
higher
level
and
things
you
build
out
of
the
operator
machinery
like
olm
and
bindings
between
services.
F
F
B
I
wanted
to
take
oh
serena
in
chat
mentioned
that
you
can
right
click
on
a
node.js
app
and
then
tell
it
which
database
you
want
to
add,
and
the
service
binding
operator
will
all
automatically
just
leap
into
action
behind
the
scenes,
so
that
when
the
database
arrives,
all
the
linking
and
labeling
and
everything
has
basically
already
been
done
for
you.
So
that
might
be
interesting
to
look
at
from
from
the
ui
right
clicking
on
the
node.js
deal.
F
B
This
user
interface
has
evolved
quite
a
bit
in
these
recent
releases
of
openshift
over
four
four
and
four
five,
and
you
know
really
there's
a
lot
more
to
look
at.
It
has
recently
won
an
award.
In
fact,
I
forget
the
name
of
the
award,
but
congratulations
to
serena
and
team
who's
been
chiming
in
and
chat
here.
Excellent
work
seriously
really
cool
to
see
all
this
stuff
come
together
and
definitely
if
you're
in
the
chat,
make
sure
to
check
back
next
week.
B
Serena
is
on
every
alternating
week
to
share
more
upcoming
demos
and
get
your
early
feedback
on
this
stuff.
She
was
saying,
I
think,
visually
here,
there's
the
core
node.js
app
and
then
maybe
another
ring
for
the
deployment
and
so
maybe
clicking
on
the
deploy
there.
It
looks
like
there
you
could
do
add
more.
C
B
B
B
A
Yeah,
I
mean
a
big
part
of
the
reason
for
this
channel
is
to
connect
with
everyone
out
there.
You
know
in
in
you
know
the
world.
So
if
this
is
another
feedback
venue
for
us
as
well,
so
we
hope
that
if
you
have
issues
or
ideas
or
suggestions
for
the
console,
please
come
to
these
office
hours
and-
and
let
us
know
if
you
want
some
features
added
or
you
know,
having
some
issues
with
something
we're
here.
C
C
C
So
how
I
got
there
and
how
you
could
test
this
out
yourself
without
you
know
deploying
your
own
app.
If
you
want
to
see
it
yourself,
the
same
way
that
I
have
it
deployed
just
look
up
the
service
binding
operator.
There's
details
on
get
on.
You
know
what
you
need
to
do
to
get
started.
There's
a
couple
different
examples.
If
you
scroll
down
here
so,
depending
on
your
own
situation,
this
doesn't
just
work
with
postgres
sql.
This
works
with
aws.
It
could
work
with
etcd,
for
example,
or
what
what
have
you?
C
The
one
that
I
use
is
the
very
top
one
and
on
here
there's
details
on
what
you
need
to
do
to
roll
this
out
and,
of
course,
like
what
you
said.
This
is
kubernetes.
So
if
you
don't
want
to
use
the
the
console
or
you
want
to
form
this
on
yaml,
all
of
this
is
available
to
you
know
you
to
your
yaml's
content
right.
You
can
do
whatever
you
want
with
all
the
ammo,
but
as
far
as
the
repo
for
the
particular
app
that's
available
here
and
from
here,
let's
see
yeah.
B
E
D
Chat
icon
and
you
were
able
to
edit
this
code
inside
the
cluster
with
auto
integration,
so
you
can
code
test
directly
from
the
browser
inside
open
shift,
so
you
can
also
work
from
there
with
the
dev
file
mechanism
of
eclipse
code
ready
workspaces,
so
not
only
developing
connecting
things
but
also
developing
directly
the
code.
This
360
degree
developer
experience
that
you
have
in
the
topology
view.
It's
very
cool.
It's
very
cool
now,
for
instance,
is
downloading
a
node.js
container
packing
inside
the
pod.
D
So
you
can
start
coding
the
node.js
app
from
there
and
then,
when
you
are
okay
with
the
auto
plugin
of
the
shift
connector,
you
can
push
this
code
to
the
open
sheet
project
and
then,
with
the
service
binding
operator,
you
can
connect
those
things.
So
you
can
really
have
this
very
nice
developer
experience
from
the
code
to
the
binding
things
and
going
up
to
the
routing
system
and
then
networking
layer.
C
C
B
I
I
found
a
link
to
the
code
that
I
the
specific
line
of
code.
It
looks
like
it's
basically
just
environment
variables
in
this
particular
example,
and
serena
has
offered
to
follow
up
next
week
with
a
demo
of
the
basically
right
clicking
on
the
deployment
to
add
the
database.
What
we
attempted
to
do
but
was
missing
in
in
this
ui,
she
said
she's
going
to
bring
it
to
next
week's
office
hours.
A
B
B
D
Another
another
nice
things
I
wanted
to
say
about
the
service
binding
operator
is
sometimes
you
know.
Those
service
discovery
is
over-engineered
in
a
another
tool
or
you
don't
need
things
like
a
service
mesh
right.
You
just
need
to
attach
buying
those
things
we
used
to
do
that
with
the
in
the
past,
with
the
service
broker
api
kind
of
now,
it's
come
with
the
service
binding
operator.
So
this
is
another
cool
things
to
do.
The
service
discovery
for
a
minimal
stack
and
develop
development
environment
without
having
their
overhead,
maybe
of
service
measure.
B
B
Yeah
this
this
has
moved
around
a
little
bit
recently,
so
yeah
the
node.js
one
and
then
yeah,
there's
terminal.
And
then,
if
you
type
in
env,
you
should
get
the
environment
variables
and
there's
a
couple
in
there.
Yeah
database
password
database
yeah
a
bunch
of
database
config
map,
and
so
there's
probably
also
a
config
map,
or
there
may
be
a
secret,
that's
mounted
somewhere.
That
has
this
information
in
a
more
structured
way
if
you
needed
something
more
than
just
key
values.
E
E
E
B
E
E
C
Ultra
easy
demo,
I
mean
it's,
it's
literally
a
30
second
drag
and
drop
there,
you
go,
but
that
that
saves
a
lot
of
time
whenever
you're
working
on
applications
deploying
stuff
right.
You
know
how
how
do
I
I
have
to
usually
go
in
and
manually
type.
You
know
the
database
is
this
particular
thing
or
add
that
to
to
yaml
and
have
a
config
map
and
manually
tie
these
things
together.
This
does
all
of
that
for
me,
so
I
don't
have
to
think
about
it.
B
B
B
Let
me
let
me
step
over
that
land
mine
and
get
back
to
work,
and
so,
if
you
are
trying
to
be
productive
on
kubernetes,
this
type
of
workflow
hopefully
allows
you
to
adopt
all
of
the
best
practices
get
the
most
out
of
kubernetes
and
related
tools,
while
not
having
to
waste
huge
amounts
of
time.
Learning.
Every
single
detail
along
the
way.
B
C
C
C
C
F
Yeah
and
so
for
for
folks
that
are
writing
operators
to
manage
database
or
file
store
foundation,
apps
or
foundation
services.
Like
this,
I
touched
on
a
little
bit
ago.
You
have
this
idea
of
an
annotation
in
the
in
the
custom
resource
for
the
operator
that
can
describe
basically
the
elements
we
were
just
looking
at
as
environment
variables,
which
is
the
connection,
information,
authentication
information
and
what
service
it
provides
for
those
services
that
a
binding
operator
is
looking
for.
F
Yeah
yeah,
eventually
you
could,
you
could
actually
so
so
ryan.
You
actually
kind
of
touched
on
what
I
think
of
at
least
is
two
different
things
right.
So
there's
I've
worked
at
a
database
vendor
or
in
a
database
community
project,
and
I
want
to
provide
an
operator
that
describes
itself
as
a
bindable
service,
and
this
best
practices
guide
tells
you
those
two
mechanisms
I
describe
where
you
can
make
those
annotations
and
then
there's
the
side
you
just
mentioned.
F
That's
also
really
interesting
and
it's
sort
of
a
whole
other
can
of
worms,
which
is,
if
I'm,
an
application
developer,
and
I
use
one
or
more
foundation
services
like
a
db
to
back
my
application,
like,
let's
take
something
simple
that
everybody
knows
maybe
like
wordpress,
it's
always
my
sequel:
there
isn't
really
an
official
postgresql
or
no
sql,
back-end
or
or
sql,
so
I
might
want
to
ship
my
app
in
terms
of
its
own
annotations.
That
say,
I
use
this
service
from
the
service
binding
operator.
F
Whenever
you
install
my
application
operator
and
you
get,
you
can
deploy
a
whole
stack
in
terms
of
the
user
says.
I
want
to
use
this.
This
end
piece,
this
front
end
piece,
that's
wordpress
or
whatever
web
app,
and
that
thing
can
actually
signal
olm
either
pull
in
a
particular
database
name
and
version
or
or
describe
it
in
terms
of
a
service,
and
maybe
my
requirements
aren't
that
strict
and
specific,
maybe
I
run
across
a
number
of
sql
databases.
So
I
just
want
a
sql
database
and
the
olm
on
the
cluster
and
the
I'm
sorry.
F
F
I
don't
know
the
mechanics
of
this
thing
today,
but
I
do
know
that
the
over
going
vision
in
openshift
with
operators
is
that
even
this
binding
that
that
lets
me
push
a
button
to
open
a
source
code.
Editor
can
happen
because,
because
the
operator
that
runs
the
console
has
said,
I
want
to
bind
to
a
service
that
edits
text
on
and
then
attach
that
to
that
ui
action
right.
So
so,
even
within
openshift,
we
can
use
this
architecturally
to
describe
the
relationship
between
components
that
we
deliver
as
operators,
which
increasingly
is
the
whole
everything.
C
B
F
B
F
It's
even
beyond
rebuilding
certain
things,
because
if
you
look
at
say
your
baseline
posix
system,
that
dominated
deployment
environments
for
a
decade
or
two,
this
has
never
been
a
particularly
well
solved
problem
at
that
level.
Right
java
has
solutions
to
this
idea
of
service
discovery
and
binding
and
there's
cobra
and
other
ridiculously
elaborate
and
complicated
answers
to
service
discovery
and
binding.
Sorry,
corba,
but
same
thing.
A
F
New
ground,
like
we
can
do
this
a
little
bit
better
atop
that
kubernetes
machinery
than
just
a
re-implementation,
because
at
one
level
the
unix
space
kind
of
didn't
solve
this
problem,
except
maybe
with
the
idea
of
posting
sockets
right
and
then
at
the
next
level.
Up.
I
I
consider
the
other
solutions
at
kind
of
the
platform
and
above
the
os
level,
to
have
been
very,
very
complicated,
arcane
or
even
baroque,
whereas
here
we
can
do
kind
of
as
natalie
was
hinting
at
like
by
convention,
this
kind
of
service
discovery
and
binding
together.
A
A
G
I
Hello
welcome
back
to
another
openshift
commons
briefing.
Today
we
have
ian
robinson
distinguished
engineer
and
cto
ibm
applica,
ibm
cloud
pack
for
applications
platform
and
he's
here
to
talk
about
counting
on
the
cloud
cloud
native
transactions
and
the
future
of
cloud
packs.
So
please
take
it
away.
J
I'd
say
that
people
that
are
deeply
into
transactions
are
fascinated
by
the
inner
workings,
different
transaction
models
and
levels
of
data,
the
levels
of
data
isolation
they
provide.
That's
actually,
my
own
history,
I'm
going
back
over
more
years
than
I
care
to
admit
to
now,
but
across
I've
been
a
in
the
past,
the
developer
on
kicks.
I've
worked
on
corba
and
ots
standards.
J
I've
worked
for
many
years
on
the
websphere
family
of
products.
I've
implemented
numerous
transaction
standards
on
some
of
those
platforms,
although
that's
that's
going
back
a
little
bit
now.
What
we're
going
to
talk
about
today
is
some
amount
of
motivation
for
why
we're
doing
some
of
the
work
we're
doing
with
cloud
native
transactions,
I'm
also
going
to
be
talking
about.
So
some
of
this
is
forward-looking,
and
so
anything
that
we
haven't
actually
delivered
yet
is
subject
to
change.
So
this
is
a
typical
ibm
disclaimer.
J
So,
having
said
that,
people
that
are
deeply
into
transactions
care
about
the
inner
workings
of
different
transaction
models,
most
people-
don't
most
people-
really
couldn't
care
less
about
how
a
transaction
works
so
long
as
it
does.
What
it's
supposed
to
do
and
in
the
end
transactions
are
really.
I
would
say
about
simplifying
how
we
count
things.
The
more
complex
a
thing
is
to
count
the
greater
the
need
there
is
for
a
tool
to
help
count.
It
and
counting
tools
themselves
can
be
quite
complex
to
use.
J
We'd
all
just
rather
use
a
calculator
so
and
that's
what
people
want
from
transactions
most
of
the
time
when
people
are
using
transactions,
they
don't
even
know
they're
using
transactions.
They
just
want
their
applications
to
work
and
to
access
data
with
integrity
with
the
minimum
amount
of
fuss.
So,
let's
start
off
by
looking
at
why
transactions
this?
This
is
a
number
that
you
can
debate,
but
you
know
whether
it's
10
15
percent
or
more.
J
It's
generally
well
understood
that
the
vast
majority
of
application
code
is
needed
only
is
needed
for
the
error
part.
So
not
only
is
that
a
huge
blocker
on
productivity,
which
is
about
happy
path,
but
it's
also
a
huge
part
of
the
test
cost,
and
I
think
everybody
here
is
familiar
with
the
fact
that
most
of
the
money
we
spend
post
release
on
application
maintenance
is
about
is
about
the
error
path.
J
So,
transactions
to
a
large
extent
are
all
about
reducing
that
at
the
most
fundamental
level,
they're
about
reducing
the
burden
specifically
on
the
application
when
something
goes
wrong
and
in
particular,
or
maintaining
the
integrity
of
the
data
that
the
application
interacts
with
so
transactions
in
their
most
basic
form
are
here
to
clear
up
the
mess
so
that
applications
don't
have
to
coming
from
the
uk.
Every
presentation
I'm
legally
obliged
to
have
a
picture
of
the
crown
jewels
there.
They
are,
and
enterprise
and
enterprises
data
are
tools.
J
J
So
I've
got
a
repeating
theme
through
these
slides,
where
I've
got
applications,
applications
represented
by
blue
boxes
and
a
large
part
of
those
applications
again,
whether
it's
90
or
slightly
less,
represents
the
error
handling
and
in
every
part
of
this
discussion.
This
is
really
all
about
making
that
red
box
as
small
as
possible
for
the
application,
so
that
the
the
valuable
parts
of
the
parts
are
are
the
majority
of
the
application
transactions
are
everywhere
and
most
of
the
time
you
don't
even
notice
that
they're
there.
J
So
because
you
don't
notice
them,
you
take
them
for
granted,
which
is
why
I've
got
this
rather
trite
picture
of
an
astronaut
flooding
around
in
space
gravity,
being
one
of
the
things
that
we
take
for
granted.
But
before
you
could
take
it
for
granted,
you
did
notice
that
it
was
bare
and
the
same
is
true
of
transactions.
J
I
would
say
that,
on
every
step
of
the
digital
evolution
of
the
last
50
years,
we
have
been
through
a
pattern
of
three
different
phases
when,
when
new
capability
is
made
available,
so
the
first
thing
that
happens
is
there's
a
new
opportunity
for
application
innovation
through
some
capability
that
wasn't
there
before
that's
the
first
thing.
That
happens
as
a
result
of
that.
J
And
do
stop
and
ask
questions
as
we
go.
I
want
to
do
that
so
right
at
the
beginning,
databases
and
information
management
systems
obviously
transformed
the
way
in
which
applications
could
could
could
use
data
and
make
that
data
valuable
application.
Enterprises
corporations
could
load
their
data
into
these
systems,
perform
queries
and
updates
and
access
that
data
with
isolation
and
integrity.
And,
of
course,
in
those
days,
the
database
or
the
information
system
essentially
was
the
application.
J
Then,
where
are
we
now
20
years
ago,
a
little
bit
more
than
that,
with
the
arrival
of
the
internet,
an
online
business
three-tier
architectures
and
in
particular,
three-tier
architectures,
with
a
java
based
middle
tier
application?
Server
started
to
make
that
started
to
put
that
data
out
into
the
internet.
At
the
end.
J
But
if
you
think
about,
if
you
think
about
what
that
did
for
application
developers
at
the
time,
it
extended
the
notion
of
that
database,
local
transaction,
all
the
way
into
the
application
and
all
the
applications
having
to
do
was
use
connections
to
that
database.
So
you
know
you
look
up
through
a
data
source
or
a
managed
connection.
Factory
got
your
connection
and
started
performing
queries
or
back-end
specific
operations
on
that
connection
and
the
fact
that
there
was
a
local
transaction
going
on
with
that.
J
Back-End
data
system
was
completely
encapsulated
and
hidden
by
the
connection,
which
is
the
only
thing
the
application
cared
about.
So
you
know
that
that's
an
example
of
the
cycle
I
was
talking
about
at
the
beginning.
You
get
the
ability
to
use
local
transactions
extended
into
your
middle
tier.
It
becomes
a
little
bit
difficult.
You
have
database
specific
or
back
end
specific
apis.
There's
error
handling
that
has
to
go
on
when
you
want
to
roll
back
that
local
transaction
and
suddenly
javory.
J
J
J
That's
going
on
between
the
back-end
systems.
All
that
complexity
was
taken
care
of
and
solved
by,
the
interactions
between
the
infrastructure
components,
back-end
databases,
messaging
systems
and
the
transaction
manager
that
was
running
in
the
middle
tier
application.
So
again
we
go
through
a
cycle
where
the
application
gets
new
opportunities
as
harder
things
to
deal
with,
and
then
we
simplify
it
again
through
standard
transaction
based
in
this
particular
case
to
pc
and
jta.
J
And
then,
as
we
went
into
the
2000s
summer,
there
were
and
web
service
trans
web
service
applications.
Soap
based
communication
became
more
common,
and
those
transaction
models
were
extended
to
stoke-based
web
services.
There
were
new
transaction
protocols
that
were
defined
ws
atomic
transactions
being
one
of
them.
J
There
have
been
multiple
implementations
and
solutions
to
web
service
transactions
provided
by
both
ibm
and
red
hat
as
part
of
our
as
part
of
our
technology
stacks.
One
of
the
things,
of
course,
with
with
web
service
transactions,
is
that
web
services
also
than
co-located
or
even
distributed
java
components,
were
designed
to
be
more
loosely
coupled.
J
So
it
is
the
application
developers
responsibility
to
provide
that
error,
handling
it's
not
as
simple
as
the
infrastructure
just
rolling
stuff
back,
and
so
the
the
pink
box
with
the
error
handling
does
get
a
little
bit
larger.
But
it's,
but
it's!
The
scope
of
the
complexity
is
constrained
just
to
what
an
individual
web
service
needs
to
do
to
make
itself
right.
J
If
the
overall
infrastructure
in
which
it
is
running
determines
that
the
overall
transaction
has
failed
and
directs
that
web
service
to
compensate
the
majority
of
the
complexity
is
deciding
first
of
all,
that
compensation
needs
to
occur
and
then
ensuring
that
the
outcome
to
compensate
is
reliably
delivered
to
all
of
the
web
service
transaction
participants.
That's
what
the
ws
business
activity
transaction
model
did
and
we've
had
that
capability
in
websphere,
since
the
6.1
release
about
10
more
than
that
15
years
ago.
J
J
If
you
modernize
a
complex
monolithic
application
today
by
breaking
it
down
into
component
microservices
that
each
run
in
their
own
container,
then
the
scope
of
any
transaction
used
by
that
monolithic
application
essentially
constrains
the
choices
you
have
when
breaking
that
application
down
the
picture
that
I'm
showing
here
works.
So
you
know,
you've
got
a
you've,
got
a
microservice,
it's
running
in
a
container.
In
this
particular
case.
J
It
is
accessing
multiple
backend,
I've
drawn
it
as
databases
here
and
and
that
works,
because
the
microservice
itself
is
running
in
a
single
container,
and
you
know
when
you're
running
in
a
single
container
you're
not
distributing
a
transaction
between
multiple
containers.
That's
completely
recoverable,
even
as
you
scale
instances
of
that
container
up
and
down
peer
recovery
can
take
care
of
that
and
the
transaction
model
works
so
long
as
you
don't
span
it
across
multiple.
J
If
you
were
to
try
to
break
that,
go
back
to
that
picture
there,
because
that
picture
is
acts
because
this
microservice
is
accessing
two
different
data
sources.
That's
a
kind
of
strange
way
to
think
about
a
microservice
would
typically
encapsulate
all
of
its
data
and
interact
with
one
back-end
persistent
store
if
it
needs
persistent
data.
J
I've
put
microservices
in
quotes
here
because
they're
not
really
two
separate
microservices
you're,
going
to
end
up
having
to
deploy
those
in
the
same
container
instance
if
they
have
an
expectation
that
they
will
interact
with
data
in
an
atomic
fashion,
and
the
reason
for
that
is
because
they
are
going
to
be
so
tightly
coupled
together
to
the
extent
that
they
succeed
or
fail
together.
But
there
is
actually
no
point
in
deploying
them
in
separate
container
instances,
because
their
life
cycle
cannot
be
decoupled.
J
J
If
you,
if
you
separate
and
more
loosely
couple
your
micro
services
and
you
and
you
want
a
transactional
atomic
outcome
between
those
micro
services
in
terms
of
the
the
data
that
they
interact
with,
then
you
need
a
more
loosely
coupled
transaction
model
and
that's
what
microprofile
long-running
actions
provide.
It
provides
a
compensating
transaction
model,
but
one
that
is
very
easy
for
the
individual
microservices
to
use.
J
I
want
to
put
that
into
the
context
of
micro
profiles
by
talking
just
just
to
make
sure
everybody
is
understands
what
the
micro
profile
set
of
standards
is
attempting
to
is
attempting
to
provide.
The
micro
profile
is
a
set
of
standards
that
have
been
around
now
for
about
four
years.
Ibm
and
red
hat
have
been
involved
with
micro
profile
standards.
Right
from
the
very
beginning.
We
helped
create
the
the
original
standards
and
the
the
community
around
microprofile.
J
We
helped
to
establish
it
as
an
activity
in
the
eclipse
foundation
and
we
provide
implementations
of
micro
profile
technologies
on
on
our
java
stacks,
including
open
liberty,
qarcus
and
and
jboss,
and
so
what
the
long-running
action
so
the
long-running
actions.
The
lra
specification
here
is
shown
in
yellow
with
reactive
messaging.
What
this
indicates
is
that
the
current
release
of
the
set
of
micro
profile
standards
is
the
blue
specifications.
J
The
current
version
of
micro
profile
is
3.3.
It
is
focused
on
on
defining
simple
cloud
native
apis
that
build
upon
the
most
commonly
used
java,
ee
building
blocks
and
transactions
and
reactive
messaging
are
standalone
specifications
that
augment
the
the
the
core
foundational
capabilities
of
micro
profile.
At
the
moment.
J
What
lra
long-running
actions
actually
provides
is
again
focused
very
much
on
making
that
red
box
as
small
as
possible
in
your
application
to
make
the
error
handling
for
more
complex
transaction
models
as
easy
as
possible.
So
here
is
an
example
of
microservice
a.
There
are
really
only
three
things
that
that
need
to
be
observed
here.
The
first
of
all
is
that
the
the
book
flight
method
is
annotated
and
at
lra
annotation.
J
Really.
What
that
is
saying
is
that,
before
this
method
is
dispatched
on
the
application,
the
infrastructure
in
which
the
application
is
running
should
establish
an
lra
or
in
some
cases
you
may
choose
to
join
an
existing
one.
This
application
is
specifically
starting
or
requesting
that
a
new
nra
be
created.
Anybody
that
has
ever
written
an
ejb
before
will
recognize
the
annotation
as
being
somewhat
inspired
by
jta
annotations
in
ejbs.
It
works
for
container
managed
transactions.
J
It
is
the
responsibility,
obviously,
of
the
application
developer
to
provide
those
methods,
but
it
is
not
the
responsibility
of
the
application
provider
to
decide
if
and
when
those
methods
are
run.
That's
what
the
platform
takes
care
of.
That's
that's
the
hard
part.
So
a
typical
saga
might
look
like
this.
This
is
a
this
is
a
familiar
example
booking
a
trip.
J
J
All
of
the
microservices
that
are
a
part
of
this
are
short
running
so
book
flight
will
execute
and
then
go
away.
Book
hotel
will
execute
and
then
go
away.
The
make
payment
microservice
failed
at
that
point.
An
instance
of
the
book
flight
and
the
book
hotel,
microservices,
are
are
called
and
their
compensate
methods
are
driven
to
make
the
over
transaction
right
and
again,
all
the
application
developer
has
had
to
do
is
to
provide
that
compensation
logic.
I
say:
that's
all
the
application
developer
has
to
do
we're
going.
H
J
So
a
very
quick,
compare
and
contrast
with
acid
transactions
on
the
one
hand
and
long-running
actions
on
the
other.
Essentially,
the
green
stuff
means
this
model
has
an
advantage
in
terms
of
simplicity
and
red
text
means
this
model
has
some
some
downsides,
so,
for
example,
with
with
acid
transactions,
those
are
isolated.
J
You
don't
get
intermediate
state
exposed
in
acid
transactions,
there's
no
logic
required
to
roll
those
things
back,
but
stuff
is
tightly
coupled
and
the
consequence
of
that
is
you're
deploying
everything
into
a
single
container
and
you
move
to
containers
on
a
good
platform
like
open
shift.
On
the
other
hand,
with
long
running
actions,
data
isn't
isolated.
J
It
becomes
eventually
consistent
at
the
end
of
the
lra,
after
the
complete
or
the
compensate
activity
run.
But
at
any
point,
during
the
long
running
transaction,
the
state
may
not
be
consistent
until
the
end,
but
on
the
plus
side,
services
are
loosely
coupled
they
have
an
independent
life
cycle
and
the
monolith
becomes
simpler
to
break
down
application.
Logic
obviously
has
to
be
involved
in
the
outcome,
but
because,
because
you
you're
not
holding
data
locks
database
locks,
for
example
over
the
entire
duration
of
the
transaction,
you
get
higher
scalability
through
less
database
convention.
J
So
there
is
a
little
bit
more
to
it
than
just
developing
your
applications.
If
that's
where,
in
the
ibm
cloud
pack
for
applications
as
well
as
providing
runtimes
that
include
the
lra
capability
and
an
lra
service,
we
have
within
the
cloud
pack
for
applications,
a
set
of
accelerators
or
different
types
of
application
pattern.
J
J
So
when
you
consider
the
additional
things
that
you
have
to
think
about
for
adding
transactions
into
the
mix,
well,
we
started
off
with
a
simply
a
simple
example
where
you
have
two
micro
services:
a
and
b
and
lra,
a
long-running
action
transaction
that
spans
between
those.
Not
only
do
you
have
to
ensure
that
your
applications
themselves
meet
best
practices,
the
developer
has
to
build
a
resilient
application
that
exposes
health
endpoints
and
provides.
J
Metrics
for
the
purposes
of
providing
overall
telemetry
views
of
their
solutions.
So
not
only
do
the
microservices
themselves
have
to
be
resilient.
The
microservices
have
to
bind
to
an
lra
service
which
is
itself
resilient
and
and
and
they
have
to
be
wired
together
in
a
fashion
that
can
be
tested
through
the
different
stages
of
the
delivery
process,
so
in
the
developers
environment
in
staging
and
in
production.
J
But
all
of
those
things
take
time
and
effort
to
become
repeatable.
What
the
solution
accelerator
in
cloud
pack
for
applications
does
is
speeds
that
up
and
makes
that
as
repeatable
as
possible.
So
the
transaction
accelerator-
that's
under
development
at
the
moment,
augments
some
of
the
patterns
that
we
already
have
in
cloud
pack
for
applications
4.2.
So
here
is
a
picture
of
the
solution
builder,
which
is
part
of
the
the
cloud
pack
for
solution
accelerator.
J
Cloud
pack
for
applications
accelerator
this
one
here,
so
this
the
pattern
that
I'm
showing
here
is
the
storefront
pattern.
That's
been
that's
one
of
the
ones,
that's
in
our
4.2
release,
but
this
one,
which
is
a
garage,
creative
pattern,
but
this
one
has
been
augmented
to
add
a
transaction
capability.
So.
E
J
What
this
solution
shows
is,
if
you
look
at
this
on
the
right
hand,
side
there
are.
There
are
five
microservices
that
make
up
the
business
logic
of
the
overall
solution.
That's
the
customer,
catalog
inventory
shipping
and
order
web
services.
That's
on
the
right
hand,
side
over
on
the
left
hand,
side
you
have
the
web
rather
in
the
middle,
really
you
have
the
web
and
the
mobile
bff,
so
the
the
the
back
end
for
front-end
web
services,
which
expose
the
overall
solution
to
different
client
channel
so
web
and
mobile.
J
Obviously,
the
thing
that's
interesting
that
I
want
to
call
out
on
this
one
is
that
this
pattern
has
now
been
extended
in
the
transaction
accelerator
to
have
a
transactional
relationship
between
the
order,
shipping
and
inventory
web
services.
So
when
an
order
is
placed
something
is
taken
out
of
the
inventory
and
shipped
I
mean,
and
in
this
particular
case
we
want
an
lra
transaction
to
ensure
that
when
something
is
bipped,
it
really
is
taken
out
of
the
inventory.
So
what
we
show
here
is
an
enhancement.
J
That's
been
developed
for
the
solution
builder
at
the
moment
that
shows
connectors
between
the
order
and
inventory
and
the
order
and
shipping
web
services
that
have
a
transactions
binding
to
them.
And
when
you
add
that
transaction
binding,
then
those
services
get
the
lra
service
bound
to
them
as
part
of
the
pipeline.
J
So
that's
under
development
as
a
transaction
accelerator
for
cloud
pack
for
applications.
At
the
moment
that
is
initially
focused
on
java,
specific
workloads
and
in
fact
the
micro
profile
specifications
are
designed
are
specifically
targeting
apis
or
java
microservices.
But
our
ambition
is
is
multicultural,
so
you
know
it's
beyond
just
java.
J
If
you,
if
you
look
at
the
the
opportunities
for
failure
in
a
a
simple
rest,
connected
scenario,
if
you
have
a
caller
over
on
the
left
hand,
side
of
this
sequence-
diagram
that
calls
micro
service
a
waits
for
a
response,
then
calls
micro
service
b
gets
the
response
back.
This
is
the
simplest
possible
saga
that
you
could
imagine
everything
can
fail
in
an
atomic
manner
at
any
point
during
this
flow,
but
the
opportunity
for
failure
and
the
opportunity
for
that
compensate
to
be
triggered
it.
J
J
More
scalable
and
responsive
through
the
adoption
of
a
reactive
programming
model
and
an
event-based
interaction
mechanism,
but
the
failure
window,
the
the
likelihood
of
the
overall
transaction
needing
to
be
compensated.
The
window
for
that
is
reduced
now
simply
to
the
duration
of
the
individual
transaction
participant.
J
J
J
Such
a
high
degree
of
understanding
of
transaction
processing
is
it
that
applications
become
impractical
to
exploit
that
transaction
model,
because
because
they're
they're
too
complex
so
there's
a
balance
between
providing
something,
that's
really
really
robust
and
something
that's
really
really
easy.
It
is
all
about
reducing
the
size
of
that
red
box
and
the
amount
of
error
processing
that
application
and
micro
service
developers
need
to
worry
about.
J
I
Thank
you
so
much.
I
love
the
evolution
of
micro
transactions,
especially
having
gone
through
most
of
those
and
seeing
where
we're
at
now
so
really
quickly.
I
did
post
in
the
chat
for
everybody
else
that
last
week,
if
you
missed
it,
david
harris
gave
a
great
demo
of
the
solution
builder
that
ian
just
talked
about
as
well.
So
if
you
want
to
go
back
and
view
that
and
then
rich,
I
think
you're
here
wanted
to
see.
If
you
wanted
to
hop
on
quick
as
well.
I
J
H
Yeah
I'll
pile
on
there
as
well
definitely
event-based
systems.
You
know
distributed
event.
Reactive
systems
definitely
seem
to
be
the
architecture
the
customers
are
adopting,
and
this
is
this:
is
company
of
building
distributed
systems?
Building
asynchronous
vendors
systems
is
complicated
stuff,
especially
when
you
still
need
you
know
all
of
the
kind
of
robustness
and
resilience
that
your
previous
generations
of
you
know.
H
Middleware
have
provided
like
jawbreakee,
so
yeah,
that's
a
real
challenge
for
us
to
ensure
that
we
can
make
these
these
building
these
systems
as
simple
as
possible
for
developers,
because
again,
moving
from
moving
from
programs
to
distributed
systems
is
huge,
you're
moving
a
cloud
native
moving
to
a
whole
new
set
of
development
tools.
This
is
a
pretty
significant
learning
curve,
so
yeah
investing
around
developer,
tooling
and
providing
those
those
guard
rails
to
make
it
as
easy
as
possible.
J
I
can
see
a
question
in
the
chat
about
where,
where
where
the
garage
example
are
so
what
one
of
the
one
of
the
one
of
the
things
we're
trying
to
make
more
consumable
is
how
to
actually
use
the
architecture
patterns
that
the
ibm
garage
creates.
So
each
garage
architecture
pattern
is
described
in
with
with
standard
collateral
around
it
in
the
ibm
garage
architecture,
section
each
pattern
that
is
described
there
has
an
exemplar.
J
That
is
that
that
is
backed
by
the
github
project.
But
before
we
introduced
accelerators
into
cloud
pack
for
applications,
there
was
nothing
that
you
could
do.
You
know
you
you,
you
could
read
the
architecture
center,
you
could
extract
stuff,
and
you
know
you
could
put
it
together
as
described
by
the
article
and
make
it
work,
but
there
wasn't
any
tooling
that
helped
automate
the
creation
of
an
application
that
used
that
pattern
or
provided
any
pipeline
building
tools
to
push
that
through
into
a
container-based
environment
like
openshift.
J
I
J
Asked
there
are
so
many
different
ways.
I
could
answer
that
question
that
that
wouldn't
be
helpful
so
for
for
any
solution
that
runs
on
both
open
shift
and
cloud
pack
for
applications.
We
do
have
some
gaps
at
the
moment
on
air
gap.
Install
that's
the
one
you
know,
and
some
of
that
is
some
of
that
is
on
the
ibm
side.
Some
of
that
is
on
is
on
the
openshift
side.
J
I
J
I
J
Well,
that's
right.
I
mean
you
know,
I
I
have
a
transactions
background
and
up
until
not
so
long
ago,
a
transactional
capability
for
microservices
was,
you
know
we
we
continued
to
think
about
it
as
a
bit
of
a
dark
corner
edge
case
for
very
advanced
scenarios,
but
we
kept
getting
asked
about
what
to
do
about
existing
applications,
monolithic
applications
that
use
transactions
and
just
having
an
answer
you
know
there
doesn't
have
to
be.
J
This
answer
is
right.
All
of
the
time
there
does
have
to
be
an
answer
that
says
in
our.
It
is
our
belief
that
this
pattern
is
a
good
pattern
to
take
a
monolithic
application
and
when
you
break
it
down
into
multiple
microservices
here
is
a
way
in
which
you
can
cope
with
your
previous
use
of
transactions.
You
are
going
to
have
to
do
a
little
bit
more
work.
J
C
H
Thinking
it
summed
up
pretty
well,
I
mean
yeah,
I
think
we've
seen
yeah
what
you
typically
see
with
with
kind
of
new
ways
of
technology
is:
is
people
very
quickly
kind
of
thrown
off
all
the
all
the
things
we
were
able
to
do
kind
of
dismissing
them,
as
is
not
relevant
anymore?
I
think
we
saw
that
with
with
transactions.
H
I
think
people
you
know,
as
we've
seen,
the
kind
of
micro
services
and
the
cloud
native
kind
of
curves.
You
know
people
have
they've
adopted,
they've
tried,
building
out
applications
yeah,
they
realize
you
know
a
lot
of
the
existing
capabilities
they
have.
They
still
need
in
these
new
architectures.
H
So
you
know
this
is
the
kind
of
typical
whiplash
effect
we
get
in
tech.
So
you
know
some
of
the
technology
that
ian's
been
talking
about.
You
know
the
lra
stuff's
been
around
for
a
while,
but
I
I
do
think
it's
gonna
find
a
find
a
sweet
spot
now,
as
people
start
building
these
distributed
applications
active
event
driven
so
could
well
be
good
timing
for
this
technology.
I
Okay,
I
just
got
the
word
that
we're
still
good
on
time.
We,
unless
you
have
a
hard
stop.
We
have
a
few
minutes.
Okay,
all
right,
so
I
know
at
least
in
the
openshift
platform.
We
still
have
to
balance
right,
the
hardening
the
platform,
making
it
more
robust
with
all
the
new
features,
and
how
are
you
balancing
that
with
cloud
pack
for
apps.
J
Well,
yeah,
so,
and
that's
why
this
is
so
that
that's
why
the
accelerators
are
a
tech
preview
capability
at
the
moment,
because
we
are
trying
to
manage
that
balancing
act.
We
expect
it
to
take
a
little
while
to
get
more
feedback
on
these
capabilities
and
to
enable
us
to
to
better
harden
before
we
actually
commit
to
making
these
accelerators
a
fully
supported
capability.
J
Okay,
so
from
a
websphere
and
cloud
pack
for
applications
perspective,
we
have
a
customer
advisory
board.
So
I'm
glad
you
reminded
me
to
talk
about
this.
This
is
this.
This
is.
This
is
one
of
the
most
common
ways
that
we
get
feedback
about,
capabilities
that
our
customers
want.
It's
it's
it's
a
means
for
us
to
share
some
of
our
pre-delivery
ideas
with
them
to
you
know,
sort
of
a
litmus
test
of
customers
that
we
know
and
trust.
I
J
So
at
the
moment
we
have
now
we
so
we
have
at
the
moment.
At
the
moment
we
have
a
cloud
native
accelerator,
the
the
event-based
one,
the
david
demoed
last
week,
the
in
development
one
at
the
moment
is
the
transactions
one,
and
there
are
others
that
are
on
the
drawing
board
the
transactions.
One
is
at
the
top
of
the
list
top
of
the
backlog.
J
There
are
other
ones
yeah,
but
that's
you
know,
so
we
we've
looked
at
so
we
have
patterns
around
which
we
would
like
to
build
accelerators
for
things
like
blockchain
edge
computing,
an
accelerator
that
unifies
some
of
ibm's
integration
portfolio
projects.
So
things
like
api
management
and
our
app
connect
products
and
don't
have
an
accelerator
at
the
moment,
but
it's
desirable
for
us
to
create
one.
I
I
J
I
Thank
you
so
much
really
really
appreciate
it.
It
was
great
information
and
thank
you,
everybody
else
for
joining
another
openshift
comments
again
next
week.
Next
tuesday,
we
will
be
here
again
same
time
noon,
eastern
and
we
will
be
talking
devops
with
packs
for
apps,
so
join
us
then,
and
talk
to
you
all
soon.
Thank
you.