►
Description
In order to thrive and compete in an era of business reinvention, building innovative solutions requires tackling different challenges simultaneously: transforming the organization into agile cloud-native teams while ensuring enterprise governance and security. All of these with speed and quality.
IBM Cloud Pak for Applications is excited to introduce Accelerators for Teams, an offering to simplify the delivery of cloud-native solutions, from idea to production.
* Remove complexity and friction for multidisciplinary teams
* Enable developers, architects, and operations to rapidly innovate with confidence
* Equip teams to comply with unique operational, security, and technology standards without worrying about it.
Special Guests: David Harris and Chris Bailey, IBM
Learn more: https://www.ibm.com/cloud/cloud-pak-for-applications/accelerators-for-cloud-native-development
A
Hello,
everybody
welcome
again
to
another
openshift
commons
briefing.
Today
we
have
special
guests
from
ibm
from
the
cloud
pack
for
applications
team.
We
have
david
harris
who's,
an
offering
manager
for
accelerators
and
chris
bailey
who's,
chief
architect
for
cloud
native
solutions
and
they're
going
to
be
talking
about
ibm
cloud
pack
for
applications
and
the
new
accelerators
for
teams
so
and
stick
around
for
the
q
a
afterwards
and
please
post
any
questions
in
the
chat.
Thank
you.
Please,
david.
B
B
So
that's,
namely
how
can
you
deliver
faster?
How
can
you?
How
can
you
contain
operational
costs
which
are
ever
increasing
and
partly
what's
causing
that
high
cost?
Is
the
complexity
that
we're
seeing
as
enterprises
are
also
adopting
this?
This
transformational
journey
that
they're
on
from
legacy
applications
and
methodologies
towards
the
cloud
native
platform.
B
B
So
we
we
kind
of
believe
with
the
compact
for
applications.
Any
any
successful
application
strategy
requires
you
to
be
able
to
to
balance
your
investments
so
to
be
able
to
deliver
those
those
new
experiences
for
your
customers
more
rapidly
and
not
be
not
be
disrupted
by
new
companies
emerging
in
your
in
your
industry,
but
that
you
also
have
this
existing
investment
and
those
business
critical
applications
that
you
need
to
keep
running.
B
They
need
to
stay
on
supported
versions
of
software,
and
for
some
of
them
you
will
also
want
to
to
unlock
more
value
in
them.
So
how
do
you
bring
them
into
a
containerized
world?
How
do
you
provide
api
so
that
they
can
be
leveraged
by
your
your
new
cloud
native
applications
and
with
with
the
cloud
pack
for
apps?
B
We
see
containers
as
kind
of
the
practical
way
of
achieving
multi-cloud,
portable
workloads
and
kubernetes
as
that
way
to
have
a
common
management
and
orchestration
for
those
workloads
together.
Ibm
and
red
hat
have
contributed
to
almost
every
part
of
the
kubernetes
platform,
and
we
we
do
truly
believe
that
building
this
in
the
open
has
been
critical
to
both
the
breadth
of
the
ecosystem.
That's
built
up
and
the
rapid
pace
of
innovation
and
adoption
that
we've
seen
around
these
technologies,
but
we
also
see
that,
what's
crucial
to
our
customers
in
particular.
B
Is
that
it's
it's
the
integration
of
that
innovation
into
a
coherent,
secure
and
supported,
offering,
and
that's
why
ibm
in
particular,
has
really
doubled
down
on
openshift
as
the
foundation
for
our
cloud
pack
strategy,
where
we
deliver
a
common
experience
for
all
of
our
solutions.
Now
this
is
kind
of
our
bill
of
materials
for
what's
in
cloud
pack
for
apps
at
the
moment,
as
you
can
see
on
the
top
left,
we
have
the
licenses
for
those
traditional
runtimes,
the
familiar
websphere
family
of
products
and
jboss
eap
in
the
bottom
left.
B
B
As
you
can
see
from
this,
the
emotional
journey
that
this
developers
on
is
not
a
particularly
pleasant
one
and
a
lot
of
times
getting
spent
bogged
down
just
getting
set
up
getting
infrastructure
and
onboarded
and
actually
getting
configuration
and
integration
right.
We
saw
this,
particularly
as
they
were
starting
to
move
those
applications
out
of
development
into
staging
and
production
environments.
B
So
what
we
try
to
do
with
accelerators
is
to
enable
multi-disciplinary
teams,
so
that
is
anyone
with
a
vested
say
in
how
a
solution
ultimately
gets
delivered
to
collaborate
and
codify
their
decisions,
so
that
developers
are
empowered
and
safeguards
are
in
place.
So
that
issues
aren't
encountered
further
down
the
line.
We
provide
content
and
capabilities
across
the
full
sdlc,
so
starting
on
the
left,
how
do
folks
actually
design
and
iodate
around
a
cloud
native
solution
to
solve
a
business
problem?
B
We
provide
a
set
of
content
with
the
ibm
garage,
so
these
are
services
organization
who
have
best
practice,
agile
principles
and
they
have
a
set
of
proven
out
reference,
architectures
and
we've
built
to
exemplar
applications
using
those
and
the
cloud
pack.
For
applications,
we
provide
a
collaborative
solution,
development
tool
which
helps
development
teams,
actually
be
productive,
much
faster.
Ultimately,
this
allows
us
to
automate
day
zero
if
you
will,
as
well
as
the
capabilities
to
ensure
that
you
you've
got
through
ci
cd
and
speed
of
delivery
and
day
two
operation
like
observability
and
maintenance.
B
Starting
with
developer
tooling,
we
kind
of
recognize
it
it's
important
to
let
developers
use
the
tools
and
ides
that
they
love.
So
we
have
always
tried
to
take
a
flexible
approach
where
we
have
had
to
introduce
new
concepts
like
the
application
stack,
we're
we're,
making
sure
we're
supporting
developers,
use
them
in
an
easy
way.
B
Looking
now
at
application
stacks
themselves,
so
the
best
way
to
kind
of
think
of
these
is
a
best
practice.
Technology
stack
for
containerized
applications,
so
this
will
include
a
particular
runtime
and
framework.
We
support
the
full
set
of
ibm
red
hat
runtimes
here,
so
you
can
see
open
liberty,
the
new
caucus
runtime
the
gs
spring
boots.
B
They
include
common
operational
capabilities
so,
for
example,
health
checks,
so
that
an
application
can
be
automatically
restarted
and
we
include
endpoints
for
monitoring
and
for
open
tracing.
The
stacks
themselves
are
semantically
versioned
for
auditability
and
control
of
updates.
We
provide
a
lot
of
labels
on
the
actual
deployed
artifacts
so
that
you
can
trace
back
to
where
this
applications
come
from,
and
this
allows
an
enterprise
to
kind
of
deploy
and
manage
these
applications
at
scale.
B
They
are,
of
course,
completely
customizable,
so
they
are
starting
point,
but
obviously
we
recognize
that
you
may
want
to
change
a
particular
technology
choice
based
on
something
that
you're
already
using
or
you
would
like
to
provide
a
stack
which
better
suits
a
a
particular
workload
type.
Should
we
say
the
one
way
that
you
can
do
this
is
through
this
concept
of
stack
inheritance,
so
stacks
can
build
on
previous
levels
of
stacks
and
you
can
gradually
abstract
concerns
away
from
the
application
developer.
So
on
the
left,
we
kind
of
have
like
this.
B
This
base
stack
for
for
node.js,
which
is
very
similar
to
an
sy
approach
where
you
package
your
application
in
a
best
practice,
docker
file
within
what
we
call
the
cloud
native
stacks,
such
as
node.js
express.
This
is
where
we
include
a
preconfigured
express
server,
which
has
those
endpoints.
I
mentioned
for
metrics
monitoring
health
things
like
that,
and
you
can
even
go
a
step
further.
B
B
One
of
the
great
things
about
this
is:
it
also
allows
for
much
easier
maintenance.
So,
for
example,
if
I
wanted
to
bump
the
version
of
node.js
in
that
base
stack
from
12
to
14.
the
any
stacks
which
extend
that
would
also
be
updated.
So
the
node.js
express
stack
and
all
those
applications
built
from
either
will
just
have
to
be
rebuilt
to
get
that
update.
B
Finally,
we'll
take
a
quick
look
at
the
pipelines
that
we
provide,
so
we
provide
a
set
of
pre-configured
tasks.
It's
all
best,
based
on
techton
running
on
openshift
pipelines
that
can
easily
be
triggered
through
web
hooks
and
github
to
set
up
ci
cd,
workflow
and
one
of
the
great
things
or
one
of
the
reasons
that
we
chose.
Tekton
in
particular,
is
that
it's
it's
a
kubernetes
native
technology
which
allows
for
a
much
more
consistent
approach
in
how
you
manage
your
overall
technology
stack
for
for
application,
development
and
deployment.
B
B
What's
continuing
to
assure
that
developers
are
productive
and
that
these
solutions
can
be
delivered
quickly
and
we're
starting
with
kind
of
the
fundamental
building
blocks
for
those
solutions,
so,
namely
microservices,
which
communicate
over
rest
and
microservices,
which
are
event
driven,
so
reactive
microservices.
Perhaps
using
a
technology
such
as
apache
kafka,.
B
So
I'd
like
to
walk
you
through
the
the
workflow
that
we
have
with
these,
so
we
start
off
with
what
we
provide
for
the
garage
as
best
practice
reference
architectures.
We
actually
bring
this
into
this
workflow.
We
have
the
best
practice
application
stacks
for
creating
applications
and
we
deploy
through
a
series
of
operators
which
I'll
talk
about
in
a
bit.
B
Clients
can
work
either
with
the
garage
or
entirely
using
the
the
on-demand
materials
that
they
have
through
things
like
the
cloud
architecture
center
and
the
solution
architect
and
business
owner
can
start
to
collaborate
in
this
tool.
We
call
solution
builder
and
this
allows
them
to
load
those
reference
architectures
to
learn
from
or
start
from
scratch
as
blank
canvas
and
drag
components
onto
it
to
design
their
intended
solution.
B
B
In
a
moment
we
set
up
the
we
provide
the
build
pipelines
so
that
you
can
go
from
the
the
microservice
source
code
to
the
github's
depository,
which
will
have
the
the
built
image
ready
for
deployment,
and
we
also
provide
the
deployment
pipelines
and
the
operators
so
that
you
can
actually
run
those
applications
on
openshift,
and
these
will
automatically
connect
to
each
other.
They
will
be
viewable
in
the
openshift
topology
viewer.
B
They
will
basically
paint
as
green
before
an
application
developer
is
even
involved
when
they
do
get
involved.
They
simply
have
to
check
out
the
the
respective
github
repo
they
can
start
to
commit
their
changes.
Those
will
trigger
and
build
and
deploy
pipelines
and,
of
course,
operations
aren't
ignored
from
this.
They
have
full
control
of
how
things
get
deployed
through
that
configuration
as
code
approach
with
gitops.
B
I
did
promise,
I
would
talk
a
little
bit
about
get
ops,
so
this
is
a
a
methodology
which
is
starting
to
emerge.
Weave
works,
I
believe
coin
determined.
We
do
have
a
very
good
blog
if
you'd
like
to
find
out
a
bit
more
about
it
but
effectively.
It
is
configuration
as
code
and
it
allows
you
to
record
your
intended
state
for
a
kubernetes
deployment
within
your
source
code,
repos
or
within
source
code
control,
so
that
you
have
that
audit
trail.
It's
very
easy
to
do,
roll
back
and
to
promote
between
different
environments.
B
We
also
use
this
tool
called
customize,
which
is
now
baked
into
cube
ctl
itself,
and
that
allows
us
to
to
tailor
the
configuration
through
overlays.
So
things
like
the
number
of
instances
you
would
like
that
can
be,
that
can
be
altered
between
development
and
production
environment
without
having
to
change
the
application
itself.
B
B
B
So
if
you
were
to
connect
to
these,
you
would
usually
need
to
know
that
up
front,
and
that
means
that
you
end
up.
You
can
actually
code
that
into
your
application,
but
it
means
that
you
end
up
very
tightly
coupled
or
ideally,
you
would
want
to
be
able
to
do
it
dynamically
and
the
way
that
we
can
do
this.
So
this
is
a
truncated
version
of
our
deployment
configuration
for
microservice
c
and
the
addition
that
I've
highlighted
here
is
the
statement
which
basically
says
I'm
going
to
provide
an
open
api.
B
B
B
The
same
secret
can
be
injected
into
microservice
b
and
what's
important
is
that
they
no
longer
need
to
know
in
advance
the
location
for
that
microservice
c.
Instead,
they're
dynamically
discovering
it
by
stating
that
they
consume
microservice
c,
and
this
is
useful
for
when
you
start
to
move
where
that
microservice
is
located.
So,
for
example,
if
I
move
microservice
c
to
a
staging
environment-
and
it
suggests
now
changes,
I
don't
have
to
change
anything
in
microservices,
a
or
b,
because
that
that
discovery
and
that
connection
is
all
handled
through
the
secret.
B
B
So
the
reason
this
is
an
advantage
is
because
the
alternative
is,
you
would
have
to
either
store
this
within
the
application
source
code
or
within
the
application
configuration
in
the
github
repository
and
generally
it's
it's
accepted.
That
storing
credentials
in
this
way
is
a
bad
idea,
and
I
think
we've
seen
a
number
of
recent
exploits
of
this,
which
have
been
very
public.
B
So
that's
the
that's
the
secret
created
for
the
backend
service.
The
next
step
is
to
say
which,
which
microservice
actually
needs
this
so
within
the
application
selector
we're
saying
that
this
is
required
by
microservice
c
and
that
will
then
get
the
secret
and
have
that
information
injected
in
the
same
way
as
before.
B
B
B
We
have
storefront,
which
is
a
simple
rest.
Ecommerce
solution
with
web
bff
pattern,
four
back-end
microservices,
which
connect
to
their
own
respective
data
stores.
As
I
say,
you
can
start
from
scratch.
We
provide
three
components
at
the
moment:
rest
microservices,
reactive,
microservices
and
database.
B
B
B
B
Within
the
blueprint
itself,
you
can
give
the
application
a
name,
and
you
can
provide
some
choices
on
how
you
want
to
do
gitops
and
how
you
want
to
configure
kafka.
Should
you
be
using
that
which
we
automatically
include
if
you
start
to
include
reactive
components,
so
I'm
going
to
start
with
coffee
shop,
I'm
going
to
save
this
as
my
own
version.
B
B
B
B
B
B
B
B
The
approach
that
we
have
taken
with
cloudpack
for
applications
is
designed
to
help
you
meet
the
twin
challenges
of
both
deliver
faster,
retain
governance,
make
sure
that
you're
using
pre-approved
application
stacks,
but
all
of
this
is
based
on
open
standards
and
open
technology
with
crucially
enterprise
level.
Support.
B
A
B
B
Not
necessarily
so
the
reason
that
we've
we've
put
this
out
as
tech
previews
is
really
to
show
the
intent
and
the
journey
that
we're
on,
but
we
want
to
make
sure
that
we
can
really
get
feedback
from
our
customers
to
inform
the
design
decisions
early
on,
because
there's
some
things
that
we
we
kind
of
know.
As
in
inherently,
we
will
need
to
add
or
new
features
that
we
will
need
to
add,
but
we'd
like
to
hear
from
our
customers
where
they
want
to
draw
the
line
between
what
is
a
developer's
concern.
B
We
found
that
there
were
some
very
common
patterns
where
a
microservice
would
produce
and
consume
on
the
same
topic.
We
didn't
have
a
way
to
represent
this
with
the
view
that
we
had
set
up
so
we're
we're
currently
working
on
a
way
which
mitigates
that
and
the
topic
can
be
a
sort
of
shared
asset.
That's
viewable
in
the
viewer.
B
We
knew
some
things
around
securing
communication
with
kafka,
which
we
currently
aren't
able
to
do
by
a
near
update,
we'll
be
able
to
do
some
things
along
that
line.
We
are
hearing
that
a
lot
of
folks
have
their
own
their
own
application
stacks.
They
would
like
to
bring
in
so
we're
looking
at
how
we
can
make
this
tool
potentially
more
flexible,
there's
a
number
of
very
early
requirements
that
we've
had
that
are
really
exciting
for
us,
because
it
shows
us
that
that
appetite
in
what
we're
doing.
A
D
C
D
It
was
bringing
in
service
binding,
which
makes
it
possible
for
us
to
migrate
applications
between
environments,
that's
kind
of
a
foundational
basis,
but
you
so
service
binding
is
something
that
we
now
need
to
drive
out
through
the
community
to
get
all
of
the
the
providers
of
operators
making
that
possible.
Now
one
of
the
things
you'll
then
see
in
solution
builder
is
that
we'll
start
to
dynamically
read
from
the
installed
set
of
operators
that
implement
service
binding
as
a
set
of
services
and
capabilities
that
you'll
be
able
to
use
in
solution
builder.
D
D
So
one
of
the
things
you'll
see
us
start
to
do
in
the
future
is
allow
you
to
configure
security
policies,
so
should
all
of
the
traffic
on
a
kafka
topic
or
between
two
rest-based
micro
services
be
encrypted
and
do
certificate
exchange.
So
so
we
kind
of
got
this.
This
foundational
set
of
capabilities,
but
in
the
future
it's
going
to
become
more
about
the
richer
set
of
components.
D
You
can
use
the
more
complex
applications
using
greater
sets
of
services
and
then
being
able
to
start
securing
those
starting
to
potentially
add
requirements
that
you
want
to
have
in
terms
of
performance
and
understanding
what
your
performance
criteria
is
and
building
custom
dashboards.
So
all
of
the
components
we
lay
down
today
are
already
you
know,
health
check
and
metrics
enabled,
but
you
still
have
to
build
your
own
dashboard.
D
The
fact
that
we
know
the
components
you've
got
in
solution
builder.
We
know
the
services
that
you're
using
like
kafka.
We
can
actually
automatically
build
custom
dashboards
that
represent
all
of
your
microservices
represents.
You
know
the
topics
that
are
are
being
used
in
kafka,
giving
you
an
application
level
dashboard,
and
if
you
tell
us
things
like
performance
requirements,
then
we
can
start
to
overlay.
You
know
alert
manager
to
alert
you
when
slas
are
being
missed
or
you
know,
for
uptime
or
performance
criteria
at
the
front
end.
A
B
Yeah,
I
think
that's
something
that
we've
we've
seen
start
to
evolve
a
lot
over
the
years
in
terms
of
like
the
access
code
approach.
So
we
talked
about
skit
ops
as
configuration
of
code,
but
we're
already
seeing
solutions
around
like
compliance
as
code
and
ultimately
being
able
to
to
store
that
decision
in
a
way
that
can
can
be
policy
enables
a
much
much
faster
delivery
cycle,
certainly
and
it
kind
of
couples
with
that
idea
of
of
shift
left
where,
if
you
can,
you
can
already
put
these
concerns
up
front
in
the
development
life
cycle.
B
A
No,
that's
I
mean
that's
great,
to
hear
the
direction
that
you
are
going,
especially
all
the
enterprise
grade
and
security.
I
know
we
would
love
to
focus
more
on
security
as
well,
and
I've
heard
you
talk
a
lot
about
collaboration
with
red
hat
such
as
service
binding
and
other
teams,
and
also
the
techton.
You
mentioned
openshift
pipelines
now.
A
B
B
B
I
guess
because
for
us
that
that
allows
us
to
build
value
on
top
of
that,
rather
than
be
producing
something
that
is
fundamentally
the
same
so
yeah.
I
think
that's
the
trend,
that's
going
to
continue
to
grow
and
we're
already
looking
at
the
new
runtimes,
such
as
caucus,
which
is
obviously
a
great,
a
great
choice
for
serverless
java.
B
D
So
your
your
kubernetes
configuration
for
deployment,
you
can
set
a
single
flag
to
true
and
that
will
deploy
it
as
a
an
openshift
server
service
rather
than,
as
a
you
know,
a
regular
kubernetes
pod.
So
we
built
that
in
in
from
day
one,
because
serverless
is
something
that's
going
to
be
coming
increasingly
more
important
over
time,
so
everything
that
we
we
kind
of
lay
out
and
we
built
them.
D
A
D
So
I
I
would
certainly
say
for
for
large
parts
of
ibm,
it's
no
different,
because
we've
been
doing
it
for
10
or
15
years.
I
don't
think
there's
there's
a
single
project
that
I've
worked
in
in
ibm.
That
is
not
now
open
source.
The
first
project
I
worked
on
that
wasn't
was
ibm's
implementation
of
java,
but
that
became
open
source
through
openj9
and
in
the
eclipse
ecosystem.
D
So
I
think
pretty
much.
Every
line
of
code
I've
ever
worked
on
in
ibm
is
is
an
open
source.
So
for
the
largest
waves
of
ibm,
it's
been
no
different
and
in
fact
the
fact
that
we've
been
collaborating
with
red
hat
on
things
like
service
binding
on
get
ups,
and
so
on.
The
fact
that
you
know
there
was
an
acquisition.
D
Actually,
it's
not
gonna
change
the
approach,
because
all
of
this
collaboration
has
been
done
through
open
source
communities,
and
you
know
for
a
lot
of
the
things
so
techton.
For
example,
now
openshift
pipelines
same
with
things
like
istio,
you
know
ibm
and
red
hat
were
already
collaborating
through
those
open
source
communities.
D
A
It
was
kind
of
a
leading
question
because
I
I've
seen
a
lot
of
the
collaboration,
especially
you
know,
run
times
and
other
teams
and
upstream
projects,
and
it's
just
it's
always
amazing.
Seeing
everybody
work
together.
You
know
in
the
open
fashion
and
seeing
it
better.
Both
you
know
cloud
packs
for
applications,
as
well
as
the
platform,
the
openshift
container
platform,
so.
A
B
D
I
I
I
think
that
the
only
thing
to
to
kind
of
end
with
is
you
know,
as
dave
visited
said
what's
out
there
in
terms
of
you
know,
solution,
accelerator
solution,
builder
and
so
on.
It's
there
as
a
tech
preview.
You
know
our
intent
is
to
continue
to
build
on
it
and
it's
like
any
open
source
community
or
any.
You
know,
tech
preview
product,
the
more
feedback
that
we
get
from
users,
the
more
we
can
do
to
build
something
that
actually
does
what
users
wants
it
to
do.
D
A
Thank
you
and
some
final
thoughts
too.
You
mentioned
the
service
binding
collaboration
the
hour
right
before
this
one
is
the
developer,
open
office
hours
and
next
week,
at
the
hour
right
before
this
one,
it's
going
to
be
service,
binding,
so
open
office
hours
on
service
binding.
So
anybody
that
wants
to
join
that
also
and
commons.openshift.org.