►
From YouTube: How To Bring Your Java Microservices To The Cloud With Payara And Platform.sh | Jakarta Tech Talks
Description
All companies are software companies, and businesses will always experience the challenge of keeping integrations between users and applications scalable, productive, fast, and of high quality. To combat this, cloud, microservices, and other modern solutions come up more and more in architectural decisions.
Here is the question: Is Java prepared to deal with these diverse concepts in a corporate environment?
Yes, and to demonstrate how Jakarta EE and Eclipse MicroProfile work very well and in the cloud, the Payara and Platform.sh will work together on this webinar. Join us, and make your conclusions.
A
B
Okay,
thank
you,
vanessa.
I'm
working
for
payara,
I'm
doing
a
bit
of
developer
advocacy
so
doing
presentations
like
this
like
this,
and
I'm
also
working
for
the
service
team,
the
support
team,
so
that
customers
or
anyone
else
who
has
questions
about
payara.
They
can
come
to
me
and
I
try
to
help
them
as
much
as
possible.
Of
course.
C
B
Okay,
what
platform
is
edge?
Is
you
will
discover
in
this
session,
and
you
can
see
how
you
can
bring
your
applications
together
with
priyara
and
platform
sh
to
the
cloud
so
first,
what
is
cloud
short
introduction
so
that
everyone
knows
what
we
are
talking
about
and
what
we
mean
when
we
say
cloud
and
cloud
native,
the
other
term,
which
is
very
popular
these
days.
I'll
continue
with
a
few
words
about
payara
micro.
B
What
are
these,
how
you
can
use
it
and
why
it
is
important
for
your
environment
and
what
specific
features
we
have
in
the
clouds
and
then
otavio
takes
over
and
talks
about
the
platform
as
edge
and,
of
course,
a
demo
where
you
all
see
those
things
nicely
in
action,
and
it's
always
a
fun
and
thrilling
thing
to
see
if
it
works
or
not,
but
trust
us,
it
will
be
funding
so
cloud.
B
So
it's
no
longer
on
your
under
your
control
entirely,
but
someone
else
is
running
the
server
for
you
and
you
have
the
hardware
in
the
software.
The
hardware
like
the
cpu,
like
the
network
configuration,
is
delivered
to
you
via
the
network
and
you
can
access
it
through
a
gui
portal,
command
line,
etc.
B
So
some
of
the
responsibilities
are
also
delegated,
then
to
that
cloud
provider.
Most
of
the
providers
support
you
with
automatic
upgrades
of
the
operating
system.
For
instance,
there
are
a
few
benefits
drawbacks
also,
but
let's
focus
on
the
benefits
here,
because
you
can
do
a
faster
setup.
You
do
not
need
to
order
your
new
server
integrated
in
your
data
center.
Just
online,
you
access
it
through
that
portal
or
command
line.
B
B
You
have
a
web
shop
and
during
the
christmas
holidays,
for
instance,
you
have
a
higher
load.
Then
you
can
easily
foresee
that,
for
a
short
time
of
periods,
a
few
weeks
that
you
have
an
additional
server
to
cover
that
higher
load,
it's
also
a
good
thing
for
your
security,
because
those
cloud
providers
have
their
security
experts.
They
know
what
they
are
doing,
so
your
environment
will
be
probably
more
secure,
more
kept
up
to
date
than
when
you
are
maintaining
it
yourself.
B
A
B
A
service
so
with
the
infrastructure
of
the
service,
then
you
only
are
interested
in
the
hardware
itself,
so
you
have
that
server
with
the
configured
amount
of
cpu
and
memory
and
you
can
access
it
via
remote,
shell
script,
for
instance.
So
that's
that's!
That
server
is
available
for
you
and
you
are
responsible
for
installing
your
runtime,
your
application
server.
Whatever
application,
you
need
to
run
you're
responsible
for
doing
that.
So
that's
the
infrastructure
of
the
service.
That's
one
of
the
two
common
models.
B
If
you
talk
about
clouds
the
platform
as
a
service
which
platform
is
sh
is
an
example
there.
You
not
only
have
the
server
installed
for
you,
but
you
also
have
your
server
runtimes.
So,
for
instance,
pyramico
is
there
for
you
and
you
only
need
to
provide
your
application,
provide
your
configuration
to
the
database,
for
instance,
but
all
the
rest
is
done
for
you.
So
don't
you
don't
need
to
worry
anymore
about
installing
the
runtime
or
maintaining
the
render.
B
Another
use
case
is
the
software
as
a
service,
which
is
for
specific
cases.
For
instance,
your
email
service
is
probably
like
that
you
just
configure
your
email
ad.
So
the
server
is
somewhere,
the
the
software
is
installed
by
the
provider.
Only
thing
is
that
you
need
to
do
is,
for
instance,
connecting
and
by
connecting
to
that
service
and
you
can
get
started
so
there
are.
A
B
Degrees
of
what
you
need
to
maintain
this
is
only
the
server
the
server
and
the
and
the
server
and
the
application,
and
depending
on
that,
they
call
it
something
else.
There
is
even
more
things
like
a
service
that
you
have
something
like
50
or
60
terms.
Now
it's
say
xyz
as
a
service.
So
that's
a
very
popular
thing
today,
all
coming
with
that
cloud
model,
which
I
was
talking
about.
B
So,
let's
switch
to
the
second
topic,
then
what
is
cloud
native
and
there
it
becomes
a
bit
more
undefined,
because
there
are
a
lot
of
definitions
of
what
cloud
native
is
so
there
are
many
terms,
some
people's
see
other
things
classified
or
cloud
native
than
other
people,
but
all
of
them
speak
about
using
that
possibilities
of
that
cloud.
Environment.
B
You
have
that
infrastructure
or
platform
as
a
service.
You
can
access
it
via
fire
scripting.
So
let's
make
use
of
that
and
that's
one
part
of
the
cloud
native
which
is
important.
B
So
your
devops
story
scenarios
changes
a
lot
now
because
you
can
have
scripts
that
not
only
deploy
your
application,
for
instance,
but
you
can
have
a
script
which
even
set
up
an
entire
server,
and
so
you
launch
a
command
and
you
have
a
server
available
at
some
time
later
in
the
time
few
seconds,
maximum
a
minute,
for
instance,
so
the
devops
is
definitely
a
part
of
that
cloud
native.
B
B
If
you
have
an
application,
you
you
test
out
an
application
with
multiple
integration
test
units
tests,
and
then
you
go
from
test
to
production.
You
do
you
have
to
install
everything
on
production
before
it.
It
is
available
for
your
customers,
of
course,
a
lot
of
times
these
days.
People
are
using
containers
for
that
because,
when
properly
configured,
your
container
added,
your
database
connection,
for
instance,
is
outside
of
your
container
image.
It's
not
baked
into
that
image,
which
is
not
a
good
thing,
so
you
can
create
a
container
put
it
under
test.
B
That's
also
part
of
that
cloud
native
and
the
link
between
that
containers
like
the
docker
containers
and
that
cloud
native
other
people
also
tell
about
microservice
and
cloud
native
microservices,
which
are
coming
in
a
minute
more.
In
detail,
or
also
named
together
without
cloud
native,
because
of
all
that,
automation,
which
is
easier
to
do
with
smaller
things,
not
a
big
application
than
mastodons,
which
you
try
to
put
in
production
every
two
every
six
months
or
so,
but
you
do
it
regularly,
because
everything
is
automated
and
scripted
for
all
this
to
work.
B
As
I
mentioned,
your
you
need
to
have
a
proper
blogging
so
that
you
have
ever
so
that
you
know
what
you're
doing
that
you
can
verify
that
everything
worked
alerting
for
the
containers,
scripting,
the
configuration
outside
of
the
containers,
etc.
So
all
those
things
are
captured
in
the
12
factor.
Application
documents
has
12
factors
where
an
application
should
conform
to
not
only
important
for
plot
native.
B
You
should
have
a
look
at
those
two
effector
application
depth
definition,
because
it
is
a
general
best
practice
for
all
your
applications,
so
also
your
big
monolith
that
you
are
maintaining
yourself,
for
instance,
in
your
on-premise
situation,.
B
And
microservices
are
most
of
the
time
smaller
because
they
have
just
focused
on
one
business
domain,
but
don't
don't
say
that
microservices
are
small
by
definition,
it
should
not
be
that
a
microservice
should
only
contain
a
few
classes,
but
it
should
be
focused
on
a
business
domain,
so
it
can
be.
Several
megabytes
in
size
contain
a
lot
of
code
lines
whatever,
but
it
should
be
focused
on
one
business
domain
so
that
you
can
have
a
set
of
loosely
coupled
services
and
each
service
is
then
focused
around
the
business
domain.
B
That
makes
it
easier
for
you,
when
it's
loosely
coupled
to
replace
one
of
those
smaller
microservices
with
the
newer
version,
although
that
will
also
be
a
challenge,
because
other
microservices
are
still
calling
your
service
or
clients
or
calling
your
service.
So
you
need
to
make
sure
that
you
always
keep
that
backwards,
compatibility
aspect
of
your
service
or
that
you
need
to
place
both
services
to
that
you
need
to
place
both
versions
of
that
service
online,
one
old
version
for
your
other
microservices
or
your
clients.
B
If,
if
it's
not
completely
automated,
don't
start
with
microservices,
that's
one
thing:
there
is
also
besides
that
maintenance
over
it.
There
is
also
a
communication
overhead,
because
now
you
do
not
call
another
method
within
that
monolith,
but
you
call
probably
another
microservice,
which
is
another
jvm
can
be.
Another
machine
can
be
maybe
in
another
data
center.
So
you
have
a
communication
overhead.
You
have
to
do
the
serialization
from
your
native
in
memory,
representation
of
your
object
to
json
and
back
all
that
all
those
things
takes
time
and
makes
a
microservice
better
definition
slower
than
monolith.
B
The
all
these
small
microservices
also
put
a
constraint
on
your
security,
because
not
only
your
monolith
is
accessible
by
one
endpoint,
but
now
you
have
10
50
100
endpoints
that
you
can
call,
because
each
microservice
comes
with
an
endpoint
and
it's
not
only
protecting
those
endpoints,
because
if
you
have
a
chain
of
microservices,
then
your
microservice
at
the
end
still
needs
to
know
who
was
the
original
car?
Is
he
allowed
to
retrieve
the
information
by
that
provided
by
that
microservice?
B
C
A
B
Said
it's
very
strict
linked
to
that
cloud,
the
native
concept,
because
you
need
to
have
those
things
scripted
from
beginning
to
the
end
so
that,
for
instance,
when
you
do
a
commit
in
your
repository,
a
change
of
actions
is
set
in
motion.
And
then
at
the
end,
it
comes
out
that
it
is
in
test
because
you
do
not
put
everything
in
production
immediately
of
or
all
the
all
the
way
to
the
end
until
production.
B
A
few
things
around
the
payara
ndpr
platform
and
how
it
fits
into
that
cloud
and
cloud
native
concepts
that
we
saw.
First,
we
have
dpir
server,
which
is
the
jakarta
ee,
full
profile,
compliant
implementation.
So
you
can
deploy
that
any
application
which
you
can
deploy
on
any
jakarta,
ee
compliant
instance,
and
it
will
run
your
your
application.
It
will
do
its
job.
B
It
is
the
full-blown
platform
so
with
all
the
things
like
remote
egb
soaps,
jms
queues,
whatever
you
like,
the
typical
application,
server
thing
like
you
install
it,
you
configure
it
and
you
run
your
application,
but
nothing
is
stopping
you
to
put
a
payla
server
into
a
docker
container
and
put
that
into
that
cloud
concept
that
we
have
spoken
about.
B
B
So
it's
smaller
starts
up
faster
because
it's
smaller
it
is
optimized
to
run
in
the
cloud
and
in
those
containers,
and
it
has
the
jakarta
ee
web
profile
embedded
so
not
having
that
remote
edbs,
for
instance,
and
also
including
the
micro
profile
specifications.
But
more
on
that
later.
Just
a
note,
ira
server
has
also
the
micro
profile
there,
but
that
that
has
another
purpose
which
I
come
back
to
it
in
a
minute.
B
So
a
few
pair
of
micro
features
in
general
not
specifically
related
to
clouds,
but
it
can
be.
It
can
be
used
here.
Pr
micro
is
an
executable
jar
file
where
you
can
use
the
whole
jar
or
the
holo
features
with
the
executable
jar
file
means.
You
have
just
that.
You
can
start
up
your
instance
with
java
minus
jar,
and
then
you
point
to
that
by
a
micro
jar
file
and
as
a
parameter,
you
specify
the
war
file
and
then
the
instance
startup.
B
It
is
configured
on
the
fly
and
it
will
run
that
specific
application
in
that
war
file.
With
that
executable
jar
file,
you
can
have
an
optimal
layer
in
docker
images.
You
know
you
should
have
a
minimal
number
of
layers
and
your
top
layer
should
not
change
with
with
change
for
any
reason.
So
only
the
war
file
can
be
put
in
that
top
layer.
B
Another
thing
we
have
within
pi
r
micro
is
the
data
grid,
where
you
can
exchange
data
between
instances.
B
Most
of
the
time
the
the
microservices
are
are
stateless
are
not
keeping
any
information
about
your
user,
but
you
can
share
data
between
those,
of
course,
fixed
data
which
does
not
update
a
lot
like
postal
codes
or
or
city
names
or
whatever,
and
that
data
grid
is
designed
so
that
can
automatically
cluster
in
those
cloud
environments,
and
the
data
grid
looks
like
this,
so
you
have
one
grid
spanning
multiple
instances
of
vr
micro
in
your
application,
and
pr
micro
itself
also
makes
use
of
the
data
grid
so
that
you
have
a
common
common
data
set,
which
is
known
throughout
the
entire
environment.
B
Specific
payer
micro
options
for
the
cloud
is
that
all
of
jar
deployment
you
do
not
need
an
install
and,
like
I
said
you
have,
that
java
java
manager,
option
and
installation
of
your
database
connection.
B
B
Another
thing
that
we
have
is
the
automatic
clustering,
for
instance,
at
the
kubernetes
horizontal
pod
scaler,
determines
that,
based
on
the
cpu
that
you
need
an
additional
instance.
B
It
starts
up
another
container
and
due
to
that
data
grid
automatic
clustering,
it
joins
the
same
data
grid,
which
was
already
available,
so
it
can
immediately
participate
in
all
the
requests
and
make
use
of
all
the
data
which
is
gathered
and
available
to
all
the
other
instances.
So
the
clustering
at
the
easy
clustering
is
definitely
a
nice
feature
and
easy
to
use
of
iron
micro
feature.
B
Jakarta,
ee,
probably
you
all
know
that
this
is
a
more
general
presentation,
but
this
is
one
of
the
tech
talks
of
jakarta
ee.
So
you
probably
know
that
it
is
the
the
new
name
of
java
ee
under
the
eclipse
foundation
and
in
general,
that
is
around
enterprise
java,
with
with
a
set
of
specifications
and
standards.
How
do
you
access
the
database
with
jba?
How
do
you
receive
connections
for
rest,
endpoints,
f,
liability
access,
etc,
etc?
B
So
that's
the
specification,
the
standards
and
you
have
one
api,
but
multiple
implementations,
like
I
said
payara,
is
one
of
the
compatible
implementations,
but
there
are
others,
of
course,
and
I
checked
the
website
and
I
found
out
that
there
are
already
eight
registered
compatible
implementations.
So
you
have
a
lot
of
things
to
choose
from.
B
This
set
of
specification,
your
inputs
about
features
about
about
issues
that
you
find
about
your
your
help
in
in
development,
etc
is
highly
appreciated,
because
it's
now
entirely
community
based
in
a
lot
of
companies
are
of
course
also
involved,
but
the
focus
lies
now
on
the
community
and
the
main
focus
is
about
the
long-term
stability.
B
Just
as
java
ee
was
something
which
was
backwards
compatible
for
15
years.
The
idea
is
that
we
also
have
something
for
jakarta
ee.
We
are
now
doing
a
breaking
change
with
jakarta
e9
due
to
legal
requirements
of
package
names
and
namespace
names,
etc,
but
there
will
be
tools
to
help
you
overcome
that
issue
and
from
then
on.
We
again
strive
to
have
backwards,
compatibility
and
long-term
stability.
B
Some
people
say
that
jakarta
is
of
is
not
very
important
anymore,
so
the
question
is:
is
that
all
required?
But
if
you
see
the
list
what
is
in
there,
then
you
see
that
it's
used
in
a
lot
of
a
lot
of
other
frameworks
and
even
standalone
situations.
You
have
servlets
a
lot
of
frameworks
or
when
you're
dealing
with
http
requests
are
using
servlets.
B
So
that's
not
only
restricted
to
jakarta
same
for
jackson,
the
arrested
points
again,
a
lot
of
things
are
based
on
that
security
always
important
for
your
applications,
and
you
see
all
those
terms
and
all
those
specifications
and
features
from
jakarta.
Ee
security
coming
up
in
other
frameworks
also.
B
B
It
is
perfectly
possible
to
create
a
microservice
with
jakarta
ee
specifications
only
but
then
you're
missing
a
few
kuku
goodies
in
that
distributed
environment
because
microservices
the
focus
lies
there
on
a
distributed
environment,
and
you
all
probably
know
that
the
distributed
environment
comes
with
a
few
challenges.
One
of
the
thing
is
the
the
request.
B
A
request
can
take
a
lot
of
time.
It
can
time
out
it
can
can
fail,
because
there
is
a
network
issue.
It
cannot
happen
because,
for
instance,
this
service,
at
the
other
microservice,
is
done,
etc.
So
all
those
scenarios
are
handled
with
the
fault
tolerance
specification
where
you
can
do
a
retry,
a
default
value.
B
The
distributed
environment,
makes
it
also
more
difficult
to
follow
the
request
throughout
your
application,
because
it's
not
only
within
one
jvm,
but
it's
now
spends
five.
Ten
calls
remote
calls
even
with
remote
rest
calls.
So
with
that
open
tracing
specification,
you
can
do
what
you
what's
called
distributed
tracing
you
can
follow
all
those
calls
you
can
see
how
much
time
it
spends
in
a
certain
microservice
so
and
you
can
see,
for
instance,
what
is
the
slowest
part
of
your
request
and
what
should
be
tuned?
Maybe
another
thing.
B
B
Other
things
are
open
api
and
to
see
how
what
your
endpoints
are
defined.
What
the
contract
of
your
endpoint
is
metrics
and
held
to
see
the
status
of
your
system
is
it
operating
well.
Health
is,
for
instance,
used
by
kubernetes
to
shut
down
a
certain
microservice
and
restart
again
if
it's,
if
it
is
indicated,
as
no
longer
healthy,
etc.
B
Again,
a
similar
thing
to
jakarta
ee.
You
have
one
api,
multiple
implementations
and
you
find
implementations
of
the
core
microprofile
specifications
within
payer
micro,
but
also
within
the
payara
server,
because
those
specifications
can
also
be
useful
outside
of
your
microservice
environment.
You
have
something
like
the
config
specification
ad
so
that
you
can
define
the
configuration
external
from
your
application,
as
I
mentioned
that
you
should
do.
B
That
can
also
be
used,
of
course,
and
be
very
handy
in
your
application,
whatever
type
it
is,
but
as
mentioned
on
the
previous
slide,
not
I
did
not
say
there,
but
there
are
different
goals:
microprofile
wants
to
be
more
innovative,
will
do
more
breaking
changes
and
there
is
normally
breaking
change
every
year
so
that
you
need
to
update
your
code
in
those
cases,
and
you
cannot
rely
on
that
backwards.
C
Okay,
okay,
hello,
everyone!
Thank
you
rudy!
Oh
I
think
from
here.
So
that's
amazing
here
to
talk
about
payara
with
cloud
and
my
question
is:
how
can
I
make
that
easier?
How
can
I
pick
take
my
application
and
move
to
the
cloud
and
I'm
going
to
show
to
you
first
I'd
like
to
create
a
small
application,
that's
going
to
run
it
as
a
maven
project.
C
Yeah.
Thank
you
rodrigo.
As
you
can
see
here,
I'm
going
to
use
java
11,
therefore,
not
java,
8
anymore,
I'm
using
pyara,
and
basically,
what
does
this
application
gonna
do.
Basically,
this
application
is
a
microservice
to
hand
fish
right
by
ara,
the
brazilian
fish
and
basically
we're
gonna
start
that
fish
on
a
nosql
database
and
guess
what
a
mongodb
and
create
a
microservice.
C
Basically
I
showed
you
it's
it's
a
payout
and
therefore
the
microprofile
gonna
be
provided.
The
same
thing
gonna
happen
with
my
jakarta:
jakarta
e-api,
so
it's
gonna
be
provided
by
payara
and
to
integrate
my
application
with
my
mongodb.
That
is
a
nosql
database.
I'm
gonna
use
the
jakarta
e
specification
that
handle
that
to
me
that
make
easier
to
you
to
you
as
a
java
developer,
to
integrate
your
application,
your
java
application
with
a
nosql
database
that
is
jakarta
nosql.
C
C
Jdbc
to
mongodb
and
let's
move
forward,
so
let's
create
my
first
class
and
guess
what
my
fish
and
I'm
gonna
create
something
the
first
one
gonna
be
my
id
oops,
no,
the
id
and
my
name,
because
I
don't
have
enough
time
to
create
more
attributes
based
on
that.
What
I'd
like
to
do
next?
Basically,
I'd
like
to
take
my
class
and
convert
to
mongdb
and
vice
versa,
basically,
I'd
like
to
convert
to
or
from
a
no
second
database
to
make
that
either
jakarta,
no
sikko
a
notation
driven.
C
C
I
have
the
id
annotation
and
beyond
that
I'd
like
to
define
this
attribute
to
storage,
that,
on
my
nosql
database,
therefore
column
beyond
that,
usually
on
the
mongodb
itself.
I
have
one
information.
C
C
So,
basically
again
it
looks
like
my
converters,
where
I
have
my
string,
that
the
attribute
that
I
have
here
and
my
object
id
that
is
my
internal
nostril
database
storage.
Right,
I
put
my
id.
I
put
my
column
just
make
that
either
I'm
gonna
put
the
a
lot
of
get
setter.
I
don't
care
about
it
at
least
on
this
presentation
and
let's
create
my
equals
match
code.
C
Yeah,
I
just
have
one
asphalt
here
so
basically,
what
I
have
right
now
is
is
my
empty.
The
next
step
is
create
my
repository,
no
fish
hippo,
sorry,
and
that
is
interface.
If
you
know
it's
bring
data,
it
looks
like
spring
data.
Basically,
I
have
my
interface
that
is
fish
repository
and
then
I
can
extend
from
repository
where
I
have
two
generic
attributes.
The
first
one
is
my
type.
C
Of
that's
not
good
anymore,
it
is
my
second
one
is
my
type
as
you
can
see
here.
Let's
show
to
you,
I
have
the
t
and
the
key
so
the
empty
and
the
key
itself
done.
I
have
my
empty
in
my
head
poster.
The
last
step
is
my
fish
repository
where
oops
I
don't
know,
fishy
resort.
Sorry
for
that
fish
resource,
where
I
can
basically
put
my
output
here
before
I
have
my
path.
C
C
Let's
find
applications
corporate,
let's
create
my
fish.
Hippo!
Sorry,
hey!
Sorry!
Let
inject
thank
you
cdi
to
make
it
happy
to
me.
Let's
create
my
small
crude
operation
right,
so
the
first
step
is
return.
Everything.
C
Fish
fish-
that's
gonna,
get
get
all.
I
know
we
have
better
way
to
handle
that,
like
my
find
out
right-
and
one
good
point
is,
as
you
can
see,
I
don't
need
to
it
does
interface.
C
C
C
C
Let's
return,
my
404
view
application
right.
Okay
and,
as
you
can
see
here,
you
have
several
options
that
include
my
not
found
oops.
C
C
C
C
C
C
If
you
see
here,
it
looks
like
jpa
where,
instead
of
I
put
my
configuration
from
the
persistent
xml,
I
put
that
configuration
file
where
I
can
put
more
information,
I
can
override
information
I'm
going
to
show
to
you
later,
but
basically
I
put
localhost
because
I'm
going
to
run
my
docker,
as
you
can
see
here,
a
document
running
and
my
provider,
that
is
among
db
configuration
where
it's
going
to
take
that
configuration
and
run
my
dock,
my
application
locally.
C
So
it's
gonna
run
my
application
and
you
run
it's
building
my
application
to
run.
I'm
gonna
prove
the
java
slash
jar
target
micro
profile
brand
though,
and
that
is
it
that's
the
whole
environment
to
make
that
happen.
Basically,
what
I
did
was
take
my
application
and
run
locally.
My
my
next
question
is:
how
can
I
move
that
you
run
in
the
cloud
right
because
to
test
is
amazing,
but,
however,
I'd
like
to
put
that
in
the
cloud,
so
it's
a
deploy
it.
Let's
do
a
send
something.
C
C
C
There
are
much
more
to
just
kubernetes
so
that
we
have
several
solutions
and
basically
to
make
possible
with
platform
message.
I
have
a
three
configuration
file
that
I'm
going
to
show,
but
basically
I
have
one
to
define.
How
can
I
build
my
application
and
put
that
in
container
where
want
to
define
the
sets
that
I
want
you
on
this
case
I
have
mong
db,
that
version
and
the
how
to
run
that
application.
C
I
saw
I
searched
that
remotely.
That
is
my
same
application.
I
just
need
to
push
to
my
master
and
guess
what
it's
going
to
be
to
me.
My
same
application,
app
my
app
container,
my
mongodb
container
and
my
host
container,
where
I
can
define.
Where
should
I
go
and
okay,
let's
show
to
you,
I
guess
everybody
here
know
that
cloud
is
amazing
right.
There
is
no
question
about
that.
C
C
C
That
is
a
trade-off
and
when
decided
to
take
everything
you
do
by
your
bare
hand,
that
is
a
huge
complexity
and
beyond
that,
because
that
that
is
a
risk,
as
I
mentioned
before
cloud.
That
is
a
huge
complexity
and
that's
why
we
have
platform
stage.
The
whole
idea
of
platform
message
is
to
make
easier
to
you:
take
your
application
and
move
to
the
cloud
easily
on
this
case
for
sure
we
love
viata.
Why
not
take
you
up
by
our
application
and
move
to
the
cloud?
C
The
whole
idea
here
is
basically
okay.
We
are
much
more
than
hosting.
We
have
several
language
support
and
we
have
support
to
use
several
architecture
solution.
Therefore,
if
you
have
microservice,
if
you
have
monolith,
if
you
have
stateful,
if
you
have
stateless
application,
we
can
handle
the
whole
complexity
to
you
to
make
that
happen.
C
C
The
first
one
is
my
application.
Yaml
file,
as
you
can
see
here,
that's
this
looks
like
my
application
to
define
where
I
have
my
name.
I
have
my
type
as
you
can
see
here.
That's
a
java
type
where
I
can
put
more
language.
You
have
more
more
language
to
support
and
here
for
sure,
there's
the
the
version.
C
Okay,
I'm
using
java
8,
don't
worry!
You
can
downgrade
to
use
java
8..
If
you'd
like
to
test
java
11,
you
can
create
a
branch
set
as
java
11
push.
This
branch
platform
message
can
deploy
your
application
to
java
11.
You
can
do
some
tests
if
you
agree
what
you
have
just
merge
to
the
master
or
the
main
branch
and
platform
message
gonna
build
automatically
to
you.
Okay,
that's
the
version
build
is
how
your
application
gonna
build
on
this
case.
It's
running,
maven,
clean
package
relationship
thing
about
security.
C
You
need
to
make
sure
the
right
application
has
access
to
the
right
database.
For
example,
I
need
to
make
sure
that
my
marketing
application
does
not
have
access
to
financial
database
on
the
microsoft
edge.
We
need
to
make
sure
the
right
service
has
access
to
the
right
service
and
that's
why
you
have
the
relationship
to
make
sure
the
right
application
has
the
right
access
divide,
the
right
claims
and
the
last
one
is
a
common
tool
right
to.
C
That
means
your
developer
does
not
need
to
know
the
environment,
the
password,
the
user
from
from
production,
and
that's
the
right
way
right.
That's
why
we
believe
in
the
12-factor
application
again
the
type,
the
name,
the
the
type
java,
the
version,
the
command
you
run
and
the
command
to
start
the
contribute.
Sorry
in
the
comments,
you
start
my
application
and
for
sure
my
credentials,
because
security
is
important.
The
second
file
is
my
service
file,
where
I
I
can
put
what
I
want
to
on
this
case.
C
I
can
put
several
services,
such
as
relational
database
thing
about
mysql,
postgresql,
mariadb,
no
sql
database.
You
can
think
about
mongodb
solar
search,
live
search,
readys
and
so
on
in
the
last
one
in
my
route,
basically,
you
can
define
each
application.
Gonna
have
public
access.
Yes,
if
you
want
to,
you
can
have
a
bunch
of
microservice
with
just
one
with
public
access.
Again.
Security
is
really
really
important
to
us
right
when
you
think
about
clouds.
C
C
You
can
merge
like
this
one
here.
I
have
one
feature
I
can
merge
to
the
master
and
it's
gonna
automatically
built
to
me
and
you
can
do
deploy
every
time
anytime,
even
friday,
also
anywhere
right,
because
platon
message
has
25
regions.
We
have
several
holes,
we
have
several
storage
core
processor.
Remember
as
a
root
set
platform.
Message
is
a
platform
on
a
service.
Therefore,
we
need
an
infrastructure
service,
you
you
can
build
and
run
with
amazon,
aws,
microsoft,
azure,
google
cloud
orange
and
much
more
and
that's
the
whole
overview
of
platform
message.
C
So
my
containers
from
that
application
file,
my
service
that
I
have
available
and
you
you
have
several
infrastructure
options,
yeah,
there's
a
gate
native
and
if
you
wish
you
can
integrate
with
github,
gitlab
and
bt
package,
you
don't
need
to
worry
about
docker
kubernetes
anymore
platform.
Essay
is
gonna,
handle
that
to
you
and
security,
security
and
security.
C
C
We
have
some
famous
class
clients
that
you
might
know
the
economy
is
the
unity.
Yes,
our
already
did
my
demo,
because
you
know
I
love
do
live
code,
but
that
is
my
whole
point
here.
If
you
want,
you
can
click?
Look
here.
That's
my
simple
application
that
I
built
and
with
just
one
click
you
can
also
deploy
this
application
in
a
cloud
with
platform
message.
So
simple
code.
I
can
pick
the
region
here.
So
let's
check
this
region
here
and
done
so.
Basically,
it's
gonna
build
my
application
with
my
whole
environment.
C
C
We
have
support
to
several
environments,
several
java
applications,
and
thank
you.
If
you
have
any
questions,
let
me
know
if
you'd
like
to
know
more.
We
have
an
amazing
book
that
we
with
payout
did.
That
was
amazing.
There
you
can
learn
about
cloud
cloud
native
and
how
you
can
integrate
payata
with
platform
message.
So
go
to
this
qr
code
and
take
a
look
on
this
amazing
book.
That's
for
free.
C
C
C
A
Welcome:
okay:
if
there
are
no
other
questions,
then
I
guess
we
can
wrap
it
up
there.
Thank
you
so
much
rudy
and
otavio
for
your
presentations
today
to
anybody
who
wants
to
watch
the
replays
of
these
you'll
be
able
to
see
the
presentation
again
here
on
the
same
link
as
well
as
on
the
jakarta
ee
youtube
channel.