►
Description
In enterprise software, we see more and more of the cloud native technologies, especially container orchestration and service meshes, emerging and slowly taking over the market. Developers are facing the challenge which technology to choose to implement microservices for a cloud native setting. Java Enterprise has been used for software solutions for a long time and its APIs are well-established in the ecosystem. Jakarta EE aims to take over where Java EE left off. However, is it possible to develop cloud native, service-meshed Jakarta EE applications that fulfill concerns such as scalability, resiliency, and telemetry -- in an effective, manageable way?
This session shows how to implement service-meshed applications using Jakarta EE and MicroProfile. We will develop a mesh of microservices, managed by Kubernetes and Istio. We'll see why especially the Java Enterprise approach fits the concepts behind container orchestration and service meshes well. All of the time will be spent live-coding while explaining the concepts and solutions.
///GET SOCIAL!
Subscribe: https://www.youtube.com/user/EclipseFdn
Follow us on Twitter: https://twitter.com/JakartaEE
Like us on Facebook: https://www.facebook.com/JakartaEE/
Join us on LinkedIn: https://www.linkedin.com/groups/13597...
Tag us: #JakartaEE
Want more great Eclipse Community webinars?
Become a member of our Jakarta Tech Talks Meetup:
A
Hello,
hello,
welcome
to
another
Jakarta
tech
talks.
We
have
today
Sebastian
nari
here
with
us
and
apologies
to
everyone
for
a
little
bit
of
the
delay
here.
It
is
the
technology,
of
course,
that
caused
the
problems.
So
it's
not
us.
Never
us
so
I'll
just
write
away
handed
over
to
Sebastian
and
give
him
a
chance
to
get
going
with
kubernetes
kubernetes
and
is
to4
jakarta.
He
developers
thank
sebastian
for
joining
and
yeah.
A
A
Kubernetes
and
sto
for
Jakarta
EE
developers,
so
about
myself,
Sebastian
Nara,
born
and
raised
in
Munich,
Germany
and
I
am
a
developer
advocate
for
IBM
and
I
have
a
vague
like
Java
background
and
enterprise
software
at
backgrounds
in
general,
and
today,
I
want
to
show
you
a
few
things
on,
while
why
we
Java,
EE
or
jacquard
EE
developers
should
be
interested
in
cloud
native
technologies,
specifically
kubernetes
amidst
you,
and
what
that
is.
So
we
gonna
see
a
little
bit
about
that,
and
first
of
all,
I
want
to
introduce
an
example.
A
Micro
service
quote-unquote
example,
application
or
actually
actually
two
applications,
because
one
application
is
boring
and
we
want
to
have
some
communication
specifically
with
container
orchestration
and
service
measures
and
all
that
and
I
like
coffee,
so
I'm
gonna
have
an
enterprise,
Java
and
enterprise
coffee
example.
So
what
that
is?
We're
gonna
have
a
coffee
shop,
an
example
of
enterprise
coffee
with
two
applications
to
micro
servers.
If,
if
you
want
and
one
is
called
coffee
shop
and
the
other
one
called
barista,
so
that
means
if
we
want
to
order
some
coffee
as
a
developer.
A
A
We
have
a
request
coming
in
or
the
coffee
that
could
be
an
HTTP
endpoint
or
whatever
boundary
we
we
offer,
and
that
then
does
is
synchronous,
requests
to
the
barista
back-end,
so
we're
gonna
have
order
coffee
and
then
something
like
start
a
coffee
brewing
process
and
order
that
at
the
barista
back-end
system,
okay.
So,
finally,
is
go
to
the
code
enough
slides,
so
what
I
have
is
actually
two
enterprise
applications
that
use
the
Java,
EE,
api's
or
2-car
de
api's
and
as
in
the
future,
and
also
micro
profile.
A
I'm
gonna
show
a
little
bit
of
that
in
a
second,
so
one
is
called
coffee
shop
and
the
other
one
is
called
barista.
So
these
are
Java
Enterprise
projects,
we're
gonna,
have
the
Java
EE
8
API.
That
is
provided
a
little
bit
more
about
that
in
a
second,
and
just
because
I'm
brave
I
use
JDK
11
already
on
an
application.
Server,
I
use
open
Liberty,
and
let
me
quickly
have
some
quick
walkthrough
to
the
code
and
then
we're
gonna
deploy
that
so
today
it's
a
little
bit
less
about
only
Java
EE
or
jacquard
EE
api's.
A
It's
a
lot
more
about
the
cloud
native
environment,
so
we
quickly
gonna,
deploy
that
using
docker
containers
and,
of
course,
kubernetes
clusters
and
sto
service
meshes.
So
how
that
works?
This
order,
coffee
process
is,
let's
have
a
look
at.
There
is
one
resource
that
is
called
ortus,
so
our
order,
coffee
boundary
is
gonna,
be
an
entity
of
HTTP
endpoint
that
we
implement
using
jax-rs,
so
as
enterprise
developers
we're
probably
familiar
with
jax-rs.
A
So
we
have
something
like
at
path:
orders
annotation
on
a
class
that
makes
us
that
gives
us
a
jack
source
resource
here,
and
then
we
have
something
like
the
orders
in
application,
JSON
format
and
also
takes
some
order,
order.
Some
coffee
or
we
can
provide
applying
a
Java
object,
the
type
Java
class
coffee
order.
So
that
means
we
gonna
post
a
specific
JSON
object.
That
represents
a
coffee
order
here
and
then,
let's
quickly,
walk
around
walk
through
this
code.
A
We're
gonna
have
a
coffee
shop
or
the
coffee
component
here,
another
class
where
we
have
the
business
logic
of
ordering
a
coffee.
So
if
we
have
a
look
at
the
diagram
well,
ultimately
we
want
to
call
that
second
system
we're
gonna,
have
a
synchronous
requests
to
the
barista
system.
That
means
we
kind
of
have
some
client
call
that
might
be
HTTP
in
that
case
as
well.
This
is
what
I
have
were
in
another
component.
A
Now,
if
we
want
to
run
that
example
in
a
cloud
native
setting,
first
of
all,
what
we
might
have
is
well,
we
want
to
run
that
in
a
docker
container.
So
that
means
we
need
a
docker
image.
That
means
we
need
some
darker
files,
for
example.
So
this
is
the
docker
file
for
a
coffee
shop
application
and
in
jacquard
EE.
That
is
actually
very
simple
to
do,
because
if
we
use
thin
deployment
artifacts
most
of
it,
what
we
need
is
actually
done
in
our
base
image.
A
A
This
is
actually
super
fast
because
we're
only
using
caches
for
the
base
image
layers
thanks
to
the
copy-on-write
file
system
of
a
docker,
and
then
we
have
a
thin
deployment
artifact.
That
is
actually
tiny.
If
we
use
that
approach
with
only
provided
dependencies,
so
that's
20
kilobyte
and
then
we
build
build
us
and
then
we're
done.
Alright.
The
same
is
actually
true
for
the
barista
system,
so
the
barista-
that's
even
more,
is
simple.
A
What
I'm
gonna
do
here
and
I'm
talk
a
little
bit
about
about
that
later
I
here,
I
use
only
micro
profile
dependencies.
That
means,
in
this
case
I
actually
only
used
jax-rs
and
CDI
and
think
JSONP,
for
that
example
for
the
barista.
So
it's
even
sufficient
to
use
that
dependency
anyway,
if
I
use
an
application
server
that
also
supports
micro
profile
or
you
know,
combinations
of
the
api's
depending
what
you
need
in
your
project
that
is
possible
as
well.
So
the
stalker
file
here
for
our
barista
application
looks
very
similar.
A
We
have,
while
our
deployment,
artifact,
barista,
odwar
and
the
same
thing
here
as
well.
Alright,
that's
enough
of
docker
assume!
We
know
about
that
already.
So,
let's
go
into
the
kubernetes
world
a
little
bit.
So
if
we
build
that,
when
I
just
showed
you
well,
we
could
deploy
that
locally,
but
that's
kind
of
boring
actually,
because
we
want
to
run
this
in
a
cloud
native
setting
in
a
kubernetes
cluster.
A
So
we
could
run
our
docker
containers,
but
now
well,
I
want
to
have
an
approach
where
I
manage
some
containers,
and
this
is
actually
where
kubernetes
comes
into
play.
Why
kubernetes
well
kubernetes
is
called
container
orchestration.
Well,
that
means
in
orchestrates
containers
as
easy
as
it
sounds.
So
that
means
if
we
have
a
production
setting
or
a
more
sophisticated
environment
where
we
have
multiple
nodes
actually
and
not
just
one
running
laptop
or
something,
then
it
becomes
quite
complex
quite
easily
how
to
well
run
all
of
that
in
production
right.
A
We
need
to
manage
networks,
we
need
to
setup
ports
and
forward
them,
and
so
on
and
so
forth.
We
need
to
orchestrate
where
our
individual
containers
actually
run
and
so
on
and
so
forth.
So
this
is
actually
already
provided
by
the
technology
in
a
somewhat
production-ready
way,
and
that
means
we
can
well
deploy
that.
So
how
do
we
get
a
kubernetes
cluster?
There
are
many
many
ways
how
to
do
that.
For
example,
we
could
set
up
a
mini
cube
on
our
running
laptop
or
we
could
go
to
to
the
cloud
for
a
managed
environment.
A
I
use
the
IBM
cloud.
That
is
called
IKS
for
managed
kubernetes,
and
this
is
what
I'm
going
to
use
here.
So
we
have
the
cube,
control
command
line
available
for
while
accessing
kubernetes,
and
then
we
can
do
something
like
cube
control,
give
us
the
services
that
are
running
or
give
us
the
running
part,
and
this
means
this
is
currently
empty.
So
what
is
that
a
service
or
a
pod?
So
how
our
application
looks
like
in
container
orchestration
is
something
similar
to
follows:
we're
gonna
have,
while
apart
and
a
so-called
service.
A
So
what
is
that
a
service
is
a
logical
abstraction
over
an
application
or
over
a
micro
service
in
in
our
case,
that
means,
if
we
have
a
coffee-shop
application,
the
application
itself.
That
will
be
a
service
that
might
be
backed
by
multiple
running
instances.
So,
if
we
gonna,
if
you
want
to
have
multiple
running
application,
servers
or
containers
or
runtimes
that
all
provide
the
same
functionality,
that
would
be
one
service
for
the
coffee-shop
implemented
by
multiple
running
parts.
A
part
is
an
atomic
workload
in
Cabana
DS.
A
So
that
means
we
have
one
or
more
running
parts
and
each
of
them
contain
a
container.
A
dock
docker
container,
for
example-
and
this
is
provided
by
the
coffee
shop
service
and
now,
if
we
want
to
access
an
order,
some
coffee,
we're
going
to
access
that
coffee
shop
service
and
end
up
at
one
running
instance
here
and
then
in
the
same
way,
if
they're
running
container,
if
our
application
wants
to
access
another
application,
for
example
the
barista,
it
accesses
the
service
and
ends
up
at
one
of
the
running,
pods
and
well
the
same
way
back.
A
So
let
me
quickly
show
you
some
llamo
code.
Yay,
everybody
loves
em,
oh,
so
this
is
modern
way:
I
guess
how
to
define
cloud
native
resources,
we're
gonna
have
some
ml
definitions
for
a
service,
and
a
deployment
well
now
hold
on
what
is
a
deployment?
Well,
a
deployment
is
a
way
how
to
manage
parts
in
a
more
sophisticated
ways
of,
for
example,
if
we
say
we
have
a
running
instance
a
running
container,
and
now
we
want
to
actually
deploy
a
new
version
or
scale
up
or
down.
That
means
we,
instead
of
creating
a
part
directly.
A
We
actually
create
a
resource
that
manages
parts
for
us,
and
this
is
the
deployment
and
we
can
say
now.
Please
provide
1:1
replica
one
part
of
the
following
specification,
for
example,
with
the
following
docker
image
that
we
just
built
and
and
run
that,
and
what
is
up
here
is
the
service
definition.
So
this
is
just
defining
a
name:
coffee
shop,
that's
the
name
of
the
service
and
it's
gonna
forward.
Well,
that
port
90-80.
A
That's
the
default
port
for
open
Liberty
to
following
parts
that
are
well
that
contain
this
label
app
coffee
shop,
so
I
might
have
multiple
parts
and
that
backed
my
coffee
shop
service
and
that
all
will
are
selected.
Then
from
the
service
and
the
service
does
a
load,
balancing
or
load
distribution
to
all
the
running
instances
there
all
right,
the
barista
one
looks
very
similar.
We
have
a
barista
service
here
with
a
named
barista
and
also,
of
course,
a
deployment.
These
two
applications
again
totally
isolated.
A
Alright.
Now,
let's
do
this.
Let's
finally,
deploy
something:
we're
gonna
use
cute
control,
apply
command
to
well
apply
these
resources
that
we
have
so
we're
gonna.
We
can
throw
in
a
whole
folder,
actually
off
the
coffee
shop
and
the
barista,
and
then
it's
gonna
create
all
the
resources
for
us.
The
reason
why
this
is
called
applied-
and
this
is
actually
a
nice
story-
we
can
say,
oh
if
I
reapply,
that
it
actually
doesn't
hurt
anything.
These
resources
are
applied
or
changed
or
created
depending
on
the
current
status
of
the
cluster.
A
So
if
that's
already
existent
on
the
cluster
that
doesn't
matter
and
now,
if
I
ask
for
the
services
that
are
in
my
cluster
queue
control,
that
services
I'll
see
a
coffee
shop
and
a
barista
service
and
cute
control
get
pods.
Give
me,
while
the
running
gives
me
the
running
pots
and
for
coffee
shop
and
for
barista
all
right,
that's
nice!
So
now
we're
gonna
access
that
and
I
get
my
cluster
IP
in
my
running
cluster
I,
say:
coffee
shop
resources,
orders,
for
example.
A
That
gives
me
the
coffee
orders
that
is
well
empty,
empty
JSON
array,
because
there's
no,
there
are
no
orders
in
the
system,
so
this
corresponds
to
what
you
just
saw
in
the
orders
resource.
This
is
now
deployed
here.
That
is
the
coffee
shop
application
I
accessed,
well
the
IP
of
the
cluster
coffee
shop.
That
is
the
context
path
of
my
application.
A
Then
the
resources
is
actually
all
the
name
of
my
jax-rs
application
here
and
then
we
end
up
at
the
orders
resource
alright
and
we
get
the
orders
and
the
system
that's
in
memory
actually
for
default,
for
example
cases.
So
there's
nothing
here.
There
is
no
coffee
yet,
but
let's
change
this
we're
gonna
create
some
coffee,
so
that
means
I
need
to
post
some
JSON
to
this
resource
right
gonna
create
a
post
request
on
using
curl,
for
example,
where
we're
going
to
post
some
application.
A
Json
content
type
have
a
look
at
how
the
coffee,
or
it
actually
looks
like
the
coffee
order,
has
a
bunch
of
things
and
especially
a
coffee
type
that
we
want
to
provide.
That
means,
while
espresso
or
latte
or
whatever
we're
gonna
we
want
to
drink.
Let's
say
we
would
like
to
have
an
espresso
here
and
we're
gonna
create
that
and
hopefully
well
that
works
to
a-1
created,
so
that
has
been
created
and
hopefully
well
yeah,
that's
already
also
in
the
system.
Alright,
that's
good
news.
A
So
how
does
that
work?
Kubernetes
per
default?
Does?
Where
is
my
resource?
Does
the
dns
resolution
a
cluster
internal
DNS
resolution
for
all
the
service
names?
So
that
means
because
of
that
name
barista,
we
can
actually
access
barista
to
a
hostname
lookup
in
that
internally,
in
that
namespace
in
the
cluster
and
end
up
at
one
of
the
running
instances
of
our
barista
application,
which
is
very
nice
because
then
we
don't
have
to
configure
an
IP
address
or
a
dns
name
for,
for
example,
test
system,
dot,
barista
dodd
example,
corporation
and
so
on
and
so
forth.
A
So
this
makes
it
very
easy
for
us
to
get
rid
of
configuration
here.
So
that's
about
the
kubernetes
here
and
then
apparently
well
that
works
so
as
we
saw
this
already
gives
us
that
running
application
in
well
production
in
a
production
setting.
So
a
few
more
things
when
it
comes
to
configuration,
for
example,
and
configuration
is
a
very
interesting
part,
especially
if
we
talk
about
12:12
factor
applications.
So
12
factors
are
well
interesting
aspects
that
have
been
set
up
in
this
initiative.
A
Here
you
might
have
a
look
at,
and
especially
if
we
build
our
enterprise
applications
using
or
cloud
native
technologies
using
containers
and
container
orchestration.
You
might
have
a
look
that
pretty
much.
All
of
these
factors
are
then
already
applied,
for
example
configuration
that
means
get
rid
of
the
configuration
on
the
application
level
and
rather
try
to
inject
it
from
outside
of
the
application
from
the
environment.
That
means
we
don't
want
to
configure,
which
barista
and
back-end
application
we
use.
A
While
we
make
that
part
of
the
environment
by
using
a
DNS
resolution,
or
in
other
words
if
we
have
to
change
a
replication
if,
for
some
reason
it
has
to
behave
differently
in
different
environments,
then
we
do
not
want
to
build
multiple
running
multiple
binaries.
Actually,
no,
we
want
to
build
one
in
the
same
binary
once
and
provided
everywhere
and
well
inject
potential
differences
from
the
outside.
Why?
Because
of
reliability
and
because
of
testing
that
means
in
our
continuous
delivery
pipeline.
A
We
want
to
build
our
image
and
binary
once
and
use
that
binary
in
each
and
every
stage
and
test
it.
So
then
we
can
be
sure
that
later
on,
it
will
work,
because
we
always
test
the
same
thing.
So
this
is
one
thing
that
I
already
use
here
in
especially
the
coffee
shop
class.
Here,
if
you-
and
you
maybe
saw
it
already-
I
have
a
location
here
that
is
actually
being
injected
or
being
figure.
That
is
well
when
my
coffee
is
being
brewed,
I
would
say.
A
So
if
we
have
our
coffee
order
and
if,
for
example,
we
access
that
that
order
here,
then
we
might
see
well,
we
have
also
a
location
available
default.
That's
it's
going
to
Brutes
on
Java,
so
at
the
island.
So
in
this
case,
where
does
that
come
from?
We
can
configure
actually
this
brew
location
and
in
this
way
we're
gonna
use
micro
profile
config.
A
So
actually,
if
you
use
an
application
runtime
that
supports
the
Java
EE
or
two
card
eee
standards,
as
well
as
micro
profile
projects,
for
example,
mica
profile
config
for
configuration,
you
can
actually
use
and
mix
and
match
all
the
api's
that
are
part
of
while
Enterprise
Java
that
are
part
of
Java
EE,
slash
micro
profile.
So
why
do
I
want
to
use
this
well
I
want
to
configure
a
configure
my
application
here
in
a
somewhat
cloud
native
way.
That
means
I,
don't
want
to
change
my
application
here,
but
provide
the
configuration
from
the
outside.
A
In
this
case,
it's
actually
provided
by
an
environment
variable.
Well,
how
do
I
know
this?
There
are
multiple
default
config
sources
in
micro
profile
available.
That
means
this
lookup
key
location
here
might
be
injected
from,
for
example,
the
environment
variables
of
my
running
container
of
my
system,
so
that
is
being
available
out
of
the
box
and
then
I
can
provide
this
location
here.
The
default
that's
being
called
home
and
I
have
a
few
locations
available
and
to
look
up
well
per
default
is
home
or
unless
it's
provided
a
well
in
an
environment
variable.
A
So
where
does
that
come
from?
Specifically
in
my
deployment,
you
probably
already
saw
that
actually
I'm
gonna
set
an
environment
variable
location
that
is
a
kubernetes
specific
configuration.
It's
very
similar
to
a
docker
run
with
an
environment
variable
a
parameter.
It
actually
does
that
under
the
hood
and
sets
this
environment
variable
well
with
a
specific
value,
so
you
can
either
set
a
value
directly,
for
example,
Java
or
say
the
value
actually
comes
from
a
config
map
or
another
configuration
store.
A
So
a
config
map
is
another
type
in
kubernetes,
where
I
can
actually
configure
something
in
an
environment
and
then
later
on.
What
I
actually
want
to
achieve
here
is
to
say
well
in
this
running
deployment.
I
want
to
configure
it
using
that
environment,
config
map
configuration
or
I'm
gonna
actually
outsource.
This
snippet
put
it
into
a
different
file
for
a
different
environment,
form
a
test
environment
for
production,
environment
and
I'm,
gonna
overwrite
that
using
a
different
location
and
then
well
I
can
reconfigure
my
application
without
actually
changing
the
image.
A
So
this
is
very
nice,
and
this
well
implements
12
this
approach
of
the
12
factors
here,
all
right,
that's
about
to
say
about
the
12
factors.
Now,
if
we
have
a
look
at
that,
this
already
runs
in
production,
this
example,
but
it's
certainly
not
well
production
ready.
For
example,
it's
lacking
a
few
concerns,
and
now
this
is
where
service
meshes
or
sto
come
into
play,
and
especially,
if
we
think
about
well
the
part
observability
what
is
going
on
inside
our
application,
then
we
might
not
well
see
or
know
everything
here.
A
So
that
means
just
because
our
resource,
our
request,
has
been
created
here
and
just
because
our
diagram
says
that
apparently
the
barista
application
is
being
called.
We
actually
have
no
clue
what's
going
on,
we
don't
really
see
into
the
system,
so
we
lack
observability
here,
but
thankfully
the
cluster
that
I
have
here
is
not
only
a
kubernetes
cluster
but
is,
in
fact
an
sto
cluster
and
sto
is
a
service
mesh
technology.
A
That
well
is
probably
the
most
widely
used
service
mesh
technology
out
there
and
it
heavily
builds
upon
kubernetes
or
supports
kubernetes
and
works
very
well
together,
and
what
is
the
service
mesh?
Well,
a
service
mesh
is
a
mesh
of
interconnected
micro
service
deployments,
where
we
actually
can
add
some
concerns
to
each
and
every
application,
without
changing
the
applications
directly,
but
adding
concerns
from
the
outside
in
a
somewhat
transparent
way,
concerns
suggest
observability
or
resiliency,
or
more
advanced
traffic
management,
and,
let's
start
with
observability
here.
A
Actually
there
is
one
way:
let's
have
a
look
at
the
bits
that
work
again.
My
secret
port
forwarding
said
that
this
works.
This
is
Gravano.
What
is
gros
fauna,
that
is
a
monitoring
technology
and
I,
did
not
set
that
up.
That
is
actually
being
provided
and
included
in
the
ECU
installation.
So
what
we
gonna
have.
We
have
some
dashboards
here
that
are
actually
available
and
that
are
already
well
activated
for
my
services.
A
A
Create
some
more
new
coffee,
new
coffee,
new
coffee,
new
coffee,
just
to
have
some
more
traffic
in
our
system,
and
now
all
I'm
gonna
see
a
little
bit
more
in
my
coffee
shop.
So
I
see
that
this
coffee
shop
service
actually
has
now
some
traffic.
So
it
includes
some
default
as
some
technical,
metrics
out-of-the-box.
For
example.
What
is
the
request
volume?
What
is
the
request
and
duration
for
that
specific
service?
A
And
when
we
look
at
the
barista
service,
we
also
see
that,
and
we
now
actually
have
some
traffic
in
coming
into
the
system
and
also
we
have
a
look
at
where
the
traffic
is
coming
from
and
we
see
o
is
actually
coming
from
the
coffee
shop.
So
that
means
that
the
coffee
shop
is
indeed
calling
our
service
our
barista
service.
Ok,
so
that
is
being
provided
out
of
the
box
with
core
fauna
with
monitoring
have
another
nice
story
that
is
being
provided
is
now
a
connection,
it's
failing.
So
what
I'm
gonna
do
here?
A
Actually
I'm
gonna
forward
the
part
off
specific
wealth
services
into
the
cluster.
So
that's
action
running
on
localhost,
but
that's
running
inside
the
cluster
and
I'm.
Just
using
a
cute
control,
a
port
forward
command.
So
what
we
have
here
is
this
cute
little
guy
with
the
German
named
Yaga,
that
is
a
distributed
tracing
technology
and
with
that
we
can
trace
individual
requests
that
go
through
the
system
to
while
being
able
to
backtrack,
what's
actually
going
on
and
which
request
is
going
through,
which
specific
instance.
A
So
if
you're
gonna
have
a
look
at
that
particular
request,
we're
gonna
see
that
well,
this
is
actually.
This
request
is
going
into
well
the
cluster
to
the
ingress,
ingress
gateway
and
it
ends
up
at
the
coffee
shop
application,
and
then
we
have
another
request
that
synchronously
calls
our
barista
application
with,
for
example,
a
request
that
we
already
know.
If
we
had
a
look
at
the
code,
it
should
be
put
request
to
that
URL.
A
A
A
We're
gonna
see
all
the
sto
resources
here,
for
example,
a
coffee
shop
service
and
the
barista
service,
and
while
which
one
in
which
particular
version
what
that
is,
when
the
explaining
a
second
is
calling
which
so
this
has
has
a
look
at
the
actual
requests
that
go
through
the
system
and
builds
up
the
dependency
graph
of
our
micro
services,
which
well
quite
frankly,
is
pretty
much
boring.
Since
we
only
have
two
applications,
one
calls
the
other.
A
But
if
you
can
imagine,
if
we
had
a
more
complex
setup
here,
then
we
actually
see
which
version
is
calling
which
application.
So
now?
How
does
that
work,
especially
that
observability
being
provided
out
of
the
box
so
in
service
mesh
technology
or
in
Istria?
Specifically,
what
we
have
is
we
have
our
services
kubernetes
for
business
and
our
deployments
that
are
well
running
instances
running
parts,
but
now
what
we
do,
instead
of
only
having
the
main
container.
A
Well,
it
accesses
that
also
through
the
proxy,
and
that
request
ends
up
at
the
another
proxy
that
again
forwards
it
to
the
main
container
of
the
barista
instance
and
the
whole
thing
back,
and
these
sidecar
containers
are
deployed
in
each
and
every
part.
If
we
had
multiple
parts
parts
either
each
and
one
of
them
would
have
its
own
proxy.
A
A
And
now
you
can
imagine
well
how
all
of
that
observability
works,
because
well
now
the
proxy
sees
all
of
the
communication
here
and
has
the
ability
to
emit
that
information,
for
example,
to
Prometheus
and
core
fauna,
or
to
Yaga
and
key
ally,
and
so
on
and
so
forth.
There
is
another
thing
to
be
done
in
car
de
or
in
our
application.
A
Actually,
if
we
want
to
make
that
work
because
well,
if
you
have
a
look
or
if
you
imagine
how
that
the
stupid
and
tracing
technology
works
specifically,
how
do
we
know
or
how
does
Yaga
know
that
this
request
is
somewhat
well
correlated
to
these
requests?
Well,
the
answer
it
it
doesn't
because,
while
just
just
because
that
request,
coincidentally
happened
at
the
same
time
as
the
other
requests,
that
doesn't
mean
that
one
caused
the
other.
A
But
what
we
have
to
do
actually
is
to
provide
correlation
IDs,
typically
an
HTTP
header
information,
and
this
is
actually
what
we
have
to
do
manually.
So
Yaga
or
Zipkin
introduces
a
de
facto
standard,
open,
Zipkin
or
open
tracing
where
we
had
to
pass
HTTP
headers
they're,
typically
called
ax
b
3
tres
ad
span.
Id
and
so
on
and
so
forth,
you
might
have
seen
them
before
when
we
need
to
pass
them
in
our
synchronous
requests.
A
That
actually
goes
through
our
application,
because
we
have
our
orders
resource
here
and
if
we
create
a
new
coffee
order
and
we
gonna
end
up
at
this
resource
and
then
sto
injects
these
HTTP
headers
for
us.
But
that
means
that
now
inside
our
application,
we
knew
would
need
to
take
these
HTTP
headers
pass
them
here
in
the
next
call.
A
Pass
them
here
into
the
HTTP
client,
pass
them
here
or
actually
pass
them
here
and
then
extract
the
HTTP
header
information
again
well
put
that
to
DHCP
client,
because
that's
a
synchronous
request
right
well
that
works,
but
this
will
be
actually
pretty
cumbersome.
So
we
don't
want
to
do
that.
What
we
can
do,
luckily,
is
well
use
another
project
that
is
being
provided
by
micro
profile,
that
is
called
micro
profile,
open
tracing.
And
now,
if
you
have
a
look
at
my
specific
maiden
project
here,
I
don't
even
introduce
that
API.
A
Why
I
only
used
Java,
eight
api's,
plus
mica
profile,
config,
plus,
actually,
health
check?
This
is
due
to
the
kubernetes
health
checks
that
we're
gonna
introduce,
but
not
the
micro
profile
open
tracing.
Why?
Well,
because
we
don't
even
use
the
API,
but
what
we
can
do
is
to
instruct
our
runtime,
in
this
case,
open
Liberty,
to
please
provide
this
functionality
to
use
the
tracing
headers
and
pass
them
out
of
the
box
automatically
to
any
HTTP
client.
A
How
does
it
work
so
this
is
now
a
Liberty
specific
and
what
I'm
doing
here
is
I
configured
my
running
Liberty
with
these
features
that
I
can
use.
So
this
is
now
the
a
little
bit
optimized
version
that
is
a
little
bit
more
verbose,
I
can
say:
okay,
I
use,
specifically
these
features
here
in
my
running
runtime.
So
that
is
optimizing
my
runtime
a
little
bit
and
what
is
the
interesting
part
here?
Is
actually
these
mica
profile
open
tracing
and
while
a
Liberty,
specific
Zipkin
implementation
of
that?
What
does
these
things
to
do?
A
Well,
these
things
actually
enable
me
that
if
I
get
a
request
into
the
system
that
has
these
open
tracing
headers
available
then
well,
actually
I
can
pass
them
here
and
if
I
end
up
in
a
synchronous
requests
in
a
HTTP
client
in
a
jax-rs
client,
then
it
will
automatically
pass
these
headers.
In
my
request
and
I,
don't
have
to
do
anything
else.
A
I
just
have
to
instruct
to
runtime
that
this
is
actually
part
of
the
application
and
this
will
work
and
it
works,
because
while
we
see
that
this
actually
connects
to
the
other
and
correlates
to
the
other
requests,
so
this
is
shown
in
this
particular
one
page
that
one
request
causes
the
other.
That's
what
we
need
to
add
for
the
tracing
example
here,
other
than
that
we
can
see
that
the
server's
mesh
well
provides
all
this
information
and
then
further
how
that
works
is
we're.
A
Gonna
have
a
control
plane
that
consists
of
multiple
components:
that's
provided
by
pi
by
by
the
sto
insulation
and
that
control
plan
actually
communicates
with
all
of
the
individual
proxy
containers.
So
then,
we
can
well
configure
all
of
the
proxy
containers
how
they
actually
should
behave,
and
also
we
can
scrape
all
of
the
telemetry
data
to
provide
that
observability.
A
All
right,
that's
to
be
said
about
the
observability
part.
What
else
we
can
do
in
is
do
actually
is
well
to
have
some
more
advanced
networking
or
some
more
traffic
management,
because
we
have
these
proxy
and
proxy
containers
being
available.
So
now
we
could
actually
say
well
instead
of
routing
to
this
barista
instance,
for
some
reason
route
to
something
else
or
provide
some
more
resiliency
here.
So
the
proxy
has
now
more
control
over
this.
So,
let's
start
with
some
more
advanced
traffic
management,
so
this
is
a
fun
part.
A
Let
me
quickly
show
you
some
sto
resources.
This
is
now
a
lot
of
content
here
and
I.
Provide
am,
will
provide
you
some
further
resources
where
I
can
actually
read
and
watch
that
and
a
little
bit
more
than
one
hour,
but
just
as
an
introduction.
What
we
have
in
order
to
configure
the
traffic
management
in
is
do
is
we
have
some
more
llamo
yay,
especially
some
resources
that
very
much
look
like
humanities
resources,
and
actually
these
are
criminales
extensions,
so
one
type
is
called
virtual
service
and
another
one
is
called
destination
rule.
A
So
what
are
these?
A
virtual
service
is
well
configures,
a
service
that
is
part
of
the
service
mesh
in
repair
with
regards
to
traffic
routing,
so
it
configures
the
routing
rules
for,
in
this
case,
the
barista
service.
And
what
is
this?
What
is
the
service
in
the
service
mesh?
Well
per
default?
All
of
the
kubernetes
services
are
actually
sto
service,
mesh
services
as
well,
but
also
we
could
have
some
more
advanced
examples.
A
For
example,
we
could
provide
a
wild
card
virtual
services
arm
or
extend
our
mesh
with
services
that
are
not
actually
part
of
our
Cabana
cluster.
That's
why
it's
called
virtual
service
and
we
can
provide
some
routing
in
this
case
all
of
the
HTTP
routes,
everything
that
is
routing
to
barista
host.
Please
wrote
to
the
barista
back-end,
so
that's
very
boring.
A
That's
actually
a
default
route
here,
and
we
have
this
destination
rule
that
configures
further
policies
for
a
specific
destination
for
a
baristas
destination,
for
example,
if
we
want
to
have
some
further
authorization
or
some
mutual
TLS
that
we
can
also
do
in
this
deal-
and
we
could
provide
that
here
and
it
also
provides
the
subsets.
What
is
a
subset?
A
subset
is
a
further
well
sub
setting
of
a
specific
service
where
we
could
divide
a
specific
service
to
multiple,
slightly
different
instances.
So
we
have
only
one
subset
here.
A
That
is
actually
called
be
born
and
it
selects
all
of
these
instances
here
by
a
specific
label.
You
might
have
seen
that
before
this
label
is
actually
being
provided
in
the
pots.
So
this
is
another
meter
information
I'll
select
some
information
here,
out-of-the-box
it
doesn't
do
anything
because
we
always
route
to
that
label,
but
we
could
specify
that
further.
A
How
the
coffee
shop
looks
like
is
very
similar.
You
have
a
virtual
service
and
a
destination
rule
as
well,
and
since
that
is
also
the
user
facing
application,
we
have
something
that
is
called
gateway
if
you're
familiar
with
kubernetes
ingresses.
This
is
actually
very
similar.
This
provides
the
ingress
traffic
in
into
the
service
mesh.
Why
we
use
a
gateway
well,
because
this
is
aware
of
the
sto
configuration
here,
and
this
then
already
can
use
the
correct
resources
and
proxies
here
and
we're
gonna
route.
Well,
also
everything
to
the
v1
subset
all
right
now.
A
If
we
want
to
have
a
little
bit
of
a
further
configuration
here,
what
we
could
do
actually
is
well
provide
another
subset
just
for
fun
that
we
call
me
too
now.
Let's
live
code,
some
Y
mo,
let's
be
brave
here
and
hope
that
works
actually
I,
now
enhanced
my
subset
of
the
coffee
shop
service
to
include
b2
as
well.
You
might
have
seen
that
before
I
actually
have
v2
example
here
that
well
uses
a
different
tack,
a
different
image
here
that
works
slightly
differently
and
what
we
could
do
well.
A
Apply
this
now
the
nice
story
about
that
is,
since
these
resources
extend
kubernetes
the
sto
resources
or
they
can
see
here,
we
can
actually
use
cube
control
to
well
use
the
same
resources
in
the
same
look
and
feel
so,
for
example,
cube
control.
That
services
gives
us
the
services
and
cue
control
that
virtual
services
gives
us
these
virtual
services.
This
does
not
work
in
a
standalone
kubernetes
cluster,
but
it
works
once
we
installed
is
to
you
because
it
extends
our
API.
A
So
we
can
use
the
same,
look
and
feel
which
is
very
nice
for
the
development
or
user
experience.
And
now,
if
we
ask
for
the
coffee
orders
again
now,
this
is
actually
empty.
Why?
Well
now,
because
we
use
the
other
application
and
per
default,
we
don't
have
any
orders
in
the
system.
So
let's
change
this,
we
create
another
coffee
order,
and
now
we
actually
see
that
the
routing
goes
to
a
different
application
to
a
v2
application.
A
That
well
has
a
different
response
here,
so
we
introduce
some
hypermedia
link
instead
of
just
the
ID,
if
you
mem
remember
it
from
before.
So
this
is
now
to
reroute
the
traffic
from
subset
v1
to
v2,
but
manually
or
explicitly,
not
only
done
by
kubernetes
deployment.
What
we
could
do
also
so,
for
example,
what
we
can
do
here
to
provide
some
more
well
advanced
scenarios.
So,
instead
of
having
one
destination,
we
might
say
well,
we
want
to
have
two
destinations
v1
with
maybe
70%
of
the
traffic
and
we
with
30%
of
the
traffic.
A
So
this
is
how
we
could
implement
some
a
be
testing.
For
example,
that
means
we
deployed
two
specific
versions
of
our
application,
and
now
we
instruct
the
ISTE
of
proxies
actually
well
do
a
split
traffic
routing
with
a
percentage
based
based
routing
here.
So
if
we
say,
let's
do
this
again,
not
only
create
it,
but
let's.
A
A
So,
for
example,
if
we
have
a
new
version-
and
we
only
want
to
sprout
a
specific
subset
of
via
our
users-
to
introduce
a
change
not
in
a
big
bang
way
but,
for
example,
introduced
only
5%
of
the
traffic
first
or
10:30,
and
so
on
and
so
forth,
and
gradually
increase
that
this
helps
us
a
lot
in
in
doing
so,
and
we
can,
we
can
do
that
here,
actually
in
an
automated
way.
So
what
else
is
there?
We
could
have
some
other
approach
where
we
do
some
a
be
testing
as
well,
where
we
said
okay.
A
No,
it's
no
headers
user-agent,
that's
that's
name
and
then
having
a
rag
X,
for
example,
I
think
this
is
the
default
example
to
route
the
Firefox
here.
Firefox
browser
to
this
route,
v2
and
the
rest
goes
to
v1.
I
hope
this
routing
was
correct.
Again,
this
is
a
llamo
live
coding.
This
was
not
correct.
The
error
headers
use
an
agent
this
correct
nope.
A
A
This
was
correct,
yeah
first,
one
is
in
the
Rea.
Second,
one
isn't
again
live
coding,
but
now
what
we
can
see
that
if
we
ask
for
our
coffee
orders,
then
now
we
always
get
that
version
v1
unless
we
specify,
in
this
case
an
HTTP
header,
user
agent
or
well,
we
actually
use
the
Firefox
browser
and
then
we
all
only
get
this
resource.
So
this
is
again
for
further
a
be
testing
to
route
a
specific
subset
of
your
users
to
to
that
resource,
for
example.
A
So,
let's
undo
this
again,
let's
route,
everything
to
we
won
again
and
apply
it.
So
this
is
how
to
introduce
some
further
advanced
traffic
management.
What
I
also
include
here
and
will
provide
us
some
code
is
actually
some
example
where
we
can
do
connect
canary
release
with
a
more
automated
approach.
A
So
what
you
should
do,
of
course,
as
part
of
your
continuous
deployment
pipeline
as
part
of
your
deployment
set
up,
is
not
do
that
in
a
manual
way
like
I
just
did
by
manually,
editing
llamo,
but
actually
to
provide
some
automation
where
you
make
this
part
of
your
deployment
to
say.
Okay,
we
have
a
new
deployment
here.
That
means
we
have
a
new
version
of
coffee,
shop
or
barista,
for
example,
and
how
we
deploy.
A
If
that's
the
case
or
you
can
roll
out
further
and
increase
that
that
traffic
to
will
not
affect
that,
many
users
is
if
something
goes
wrong
and
to
make
an
to
have
a
better,
automated
approach
of
your
deployment.
So
that
is
an
approach
and
that
you
should
take
what
I
told
you
before
is
that
we
also
have
some
resiliency
being
built
in.
So
what
we
can
do
actually
is
to
say:
well
what
happens
if
the
baristas
service
actually
goes
down
and
becomes
unavailable?
How
does
our
application
react
if
that
is
not
there?
A
So
if
we
apply
that
well,
this
means
then
well
we
have
a
timeout
being
applied,
and
now,
if
we
well
create
a
coffee
orders
that
is
guarded
by
a
timeout
I
guess
well,
does
it
work
I
guess
it
looks
like
it
right.
Well,
how
do
we
test
it,
whether
that
timeout
is
actually
being
applied,
because
that
route
now
is
guarded
by
one
second
timeout?
A
So
that
means,
if
that
would
take
longer
or
if
the
barista
application
is
unavailable,
then
this
well
will
kill
the
connection
after
one
second,
but
in
order
to
test
that
we
would
either
need
to
redeploy
a
fault
test
version
of
our
barista
application
in
order
to
test
it,
whether
that
works
right
always
test
whether
that
is
actually
the
case
or
we
use
well
some
behavior
by
M
some
functionality,
but
is
do
that
actually
can
do
that
so
for
testing
purposes.
We
can
actually
introduce
some
faults,
so
that
means
just
for
fun.
A
A
Let's
say
we
want
to
have
a
fixed
delay
of
3
seconds,
but
not
all
the
time,
and
only
in
the
50%
of
the
cases
so
now
for
testing
purposes.
Don't
do
that
in
production.
This
will
make
the
application
slower
in
order
to
test
the
behavior
off
well
of
our
application
or
of
well
the
environment
here.
So
what
happens?
A
Is
that
now
either
that
request
immediately
works
or
the
barista
application
status
can
call
it
in
a
synchronous
way
would
take
3
seconds,
which
is
actually
too
long
for
the
timeout,
and
then
we
get
a
timeout
after
a
while
one.
Second,
that
is
being
provided
here,
and
then
we
also
see
well
that
we
have
a
fault
request.
If
we
have
a
look
at
our,
let's
try
to
find
a
faulty
request
here
in
our.
A
It
is
stupid
at
racing
with
the
Yaga,
for
example,
so
I
kind
of
find
one
right
now,
depending
on
how
much
we
trace
here.
So
that
would
be
a
bit
miserable
here
and
if
we
had
a
look
at
one
particular
request
that
is
actually
being
aborted
after
one
second
or
where
we
also
see
it.
So
this
is
now
actually
more
interesting.
A
Now
we
only
round
to
v1,
but
we
see
that
this
is
not
all
fully
a
functional
that
we
get
a
specific
error
rate
here
calculated
over
the
last
time,
so
that
again
provide
some
more
observability
and,
what's
going
on
here
same
with
Cortana,
where
we,
what
we
see
and
the
coffee-shop
application,
the
success
rate
goes
down
and
so
on
and
so
forth.
So
that
provides
you
some
information
out
of
the
box.
So
this
is
also
helpful
for
debugging
and
testing
purposes
in
general.
A
If
you
want
to
test
how
your
application
reacts
once
an
an
external
system
is
faulty,
then
you
can
have
a
look
at
that
as
well.
What
is
also
very
helpful
so
just
quickly.
The
last
thing
is
well
how
to
debug
your
java
enterprise
applications
in
a
kubernetes
environment.
So
there
are
a
few
tools
available
that
actually
help
you
to
debug.
A
What's
going
on
here
and
specifically,
what
I
want
to
show
you
is
two
things:
is
one
tool
called
watch
and
deploy
or
wad
made
by
adam
bean,
which
well
does
not
much
and
actually
listen
for
any
file,
changes
and
rebuilds
and
redeploy
your
application
into
a
thin?
A
deployment
artifact
same
thing,
what
we
have
here
and
what
you
can
also
do.
Well,
if
you
point
watts
to
a
deployment
directory
that
is
actually
being
being
connected
to
a
running
container,
you
can
how
to
redeploy
your
docker
containers
as
well,
not
just
local
applications.
A
Well,
but
now
we
also
have
kubernetes
so
that
works.
I,
provided
some
information.
If
you
want
to
look
at
Hana,
have
a
look
at
that.
How
that
works
with
local
docker
containers,
we're
using
what
what
it
also
works.
Well
using
a
kubernetes
cluster
if
you
use
a
tool
called
a
telepresence,
so
that
is
a
tool
to
well
connect
and
replace
containers
that
run
in
a
kubernetes
environment,
with
your
local
processes
or
local
running
containers.
So
what
that
is?
A
It
well
introduces
a
two
way
proxy,
where
you're
actually
providing
an
instance
for
a
running
service
such
as
coffee
shop,
where
you
then
well
actually
provide
that
service
with
something
that
runs
on
your
local
laptop
just
for
testing
purposes.
You
can
connect
into
the
cluster
and
use
the
same
while
networking
features,
for
example
the
dns
resolution
that
I
showed
you
before
and
if
you
use
such
a
tool
suggest
this
watch
and
deploy
tool,
you
can
even
hot
and
hot
reload.
Your
code
have
code
changes
here
and
have
them
being
reflected
in
your
application.
A
So,
for
example,
if
we
provide
this
orders
example
again,
we
have
the
coffee
orders
here.
Well
now
we
have
the
time
or
example,
so
that
takes
too
long.
But
now
we
see
okay,
new
application,
no
orders
in
the
system-
and
what
is
now
here
is
that
this
is
actually
being
replaced
and
then
locally.
We
have
well
a
running
coffee
shop
container
and
if
we
access
our
application
here,
we
actually
end
up
at
a
local
running
container
and
what
we
can
do,
then,
is
actually
change.
A
Something
in
our
application,
for
example,
say
well,
instead
of
just
providing
the
order
here
also
provide
some,
let's
say
the
location
that
I
just
showed
you
before.
So
we
want
to
enhance
this
to
introduce
a
new
location
into
our
order
as
well,
and
now
what
that
is
doing
is
actually
rebuilding
our
replication
and
then
immediately
redeploying,
and
especially,
if
you
use
an
application
server
that
can
we
deploy
quickly.
That
means
your
changes
are
automatically
reflected.
Okay.
A
Well
now
you
don't
see
anything
because
we
have
to
create
an
order
first,
but
then
you
see
well
now
also
in
the
orders
resource.
This
location
is
being
provided
case
in
Java
and
again
we
could
change
and
redeploy
it
or
introduce
some
some
other
examples
and
immediately
you
would
have
you
change
available.
That
is
actually
in
only
in
your
running
and
docker,
container
or
locally,
but
very
quickly.
A
You
see
it
very
quickly,
redeploys,
and
if
you
use
the
tools
such
as
telepresence,
you
can
actually
connect
that
into
your
local
development,
to
your
local
kubernetes
cluster,
for
development
purposes
and
to
debug
or
develop
your
applications
connecting
to
them
and
well
give
up
them
locally
is
in
the
local
container.
If
you
need
to
or
use
such
a
tool
to
improve
your
development
productivity.
So
that's
another
way
to
well
introduce
some
further.
Some
further
productivity
enhancement
for
your
Jakarta
EE
application
inside
a
kubernetes
environment.
A
So
if
you
take
aways
for
container
orchestration
or
kubernetes
em
in
general,
what
it
provides
us
is
well
a
few
things.
For
example,
we
have
some
service
discovery,
provided
we
saw
that
in
the
barista
application
we
have
some
dns
resolution
being
there
out-of-the-box
and
the
services
specifically
distribute
our
load
and
do
some
load
balancing
over
the
multiple
instances
we
might
specify
and
of
course,
kubernetes
also
sets
up
all
the
complicated
networking
and
configuration
of
our
applications.
So
we
don't
have
to
do
that
in
our
application.
Also,
we
have
some
deployment
and
scalability
options.
A
A
So
what
we
ship
actually
is
still
a
thin
deployment
artifact
that
well
builds
and
integrates
very
well
with
containers
with
docker
containers,
thanks
to
copy
and
write
file
system
layers,
and
that
means
our
business
logic
is
being
provided
in
the
application
in
the
Java
code
using
Java
and
Turk,
our
de
api's,
and
everything
else
is
then
well
either
being
implemented
by
the
application
runtime
by
the
application
container
here
or
being
part
of
the
environment.
In
this
case,
then,
the
sto
cluster
and
the
sto
sidecar
containers.
A
So
by
doing
so,
we
can
actually
focus
on
what
we
should
focus
on
as
developers.
That
is
implementing
business
logic.
So
now,
if
you
want
some
further
resources,
what
I
have
you
have
this
example
available
on
github
with
all
the
code
here,
including
some
workshop
I'm?
Actually
that
we
created
where
you
can
go
and
get
your
kubernetes
cluster
with
sto
in
the
cloud,
so
you
can
get
that
for
free
and
try
out
kubernetes
in
this.
Do
if
you
want,
we
have
a
lot
of
resources
available
here.
A
We
can
see
coffee
shop
and
baristas
service,
create
your
own
coffee
and
also
well
see
the
observability
features
of
Sto,
see
how
that
integrates
with
Java,
EE,
jacquard,
EE
and
micro
profile,
and
have
a
look
at
that.
If
you
want
so
I
will
provide
you
all
of
these
links
and
also
how
to
do
this.
A
WOD
watch
and
deploy
approach
with
docker
and
with
the
kubernetes
debug
example
other
than
that
I
hope.
A
This
was
a
very
helpful
session
for
you
and
thanks
a
lot
for
your
attention,
thanks
so
much
Sebastian
for
an
awesome
demo,
and
thank
you
to
the
community
for
coming
out
and
watching
it
was
fantastic.
So,
as
Sebastian
said,
he'll
be
providing
links,
I'll,
throw
them
in
the
description
down
below
for
everybody
to
access,
and
at
this
time
we
have
no
questions.
So
thank
you
for
joining
us
and
we'll
see
you
for
our
next
Jakarta
EE.
Tech
Talk
have
a
good
one.
Everyone
thank
you.