►
Description
Larry Garfield presents:
The days of hand-crafted artisanal servers are long over. Modern web applications need to be able to run on many different servers without code changes. Not just different hosting providers, but different environments on the same hosting provider. Whether you’re using a legacy dev/stage/prod setup or a modern branch-is-environment host, modern hosting imposes some requirements on your application design but also offers a huge potential for new and powerful tools.
In this webinar, we’ll explore some key guidelines for building a cloud-friendly application, as well as look at some architectural options that a modern hosting platform enables.
Get Social!
Website: jakarta.ee
Subscribe: https://www.youtube.com/user/EclipseF...
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: https://www.meetup.com/jakartatechtalks
A
A
If
you'd
like
to
follow
along
at
home,
here's
a
link
in
the
chat
where
you
can
do
so
said.
My
name
is
larry
garfield.
You
may
know
me
online
as
krell.
If
you
want
to
make
fun
of
me
on
twitter
during
the
talk.
That's
why
you
do
so.
I
generally
encourage
that
I
am
starting
next
week
a
staff
engineer
for
typo3.
A
I
actually
come
mostly
from
the
php
community,
not
from
the
java
community,
but
what
we're
talking
about
here
is
fairly
language
agnostic,
so
yeah
been
around
the
php
community
for
a
long
time
in
a
number
of
different
roles.
I've
also
written
a
number
of
books
on
software
development
in
php,
and
I
until
recently
worked
for
platform
sh,
which
is
a
continuous
deployment
cloud
hosting
company,
on
which
much
of
this
talk
is
based.
A
Just
for
my
experience
there
working
with
different
applications.
So,
let's
talk
about
clouds,
wrong
clouds.
I'm
talking
about
cloud
hosting
here
like,
as
I
said,
I
worked
at
platform
sh
and
part
of
my
job.
There
was
working
with
a
lot
of
different
applications
to
make
them
play
nicely
with
platforms,
cloud-based
hosting
solution,
which
meant
I
got
to
work
with
a
lot
of
different
applications,
some
of
them
very
good
and
some
of
them.
A
If
you
can't
see
anything,
nice
don't
see
anything
at
all,
so
I
won't
mention
those-
and
this
gave
me
a
very
broad
perspective
on
what
works
and
what
doesn't
in
modern
hosting
now.
Why
does
this
matter?
Well
because
cloud-based
hosting
is
where
things
are
going
everyone's
talking
about
cloud,
this
cloud,
that's
cloud
hosting
cloud
native.
You
know
that's
where
everything
is
moving
these
days,
technologically
okay.
What
does
that
mean?
What
do
we
mean
when
we
say
cloud?
A
A
The
cloud
is
a
marketing
term.
That
means
someone
else's
hard
drive.
It
goes
back
to
the
90s
actually
a
bit
earlier,
where
the
network
between
two
computers
was
represented
by
a
big
pink
cloud
in
block
diagrams
on
people's
marketing,
slides
to
say,
hey,
and
then
this
problem
goes
away
because
the
cloud
takes
care
of
it
to
just
stuff.
A
This
is
a
business
model,
it's
not
a
technological
model;
it
is
simply
outsourcing
by
another
name.
We're
not
really
going
to
be
talking
about
that
much
here,
but
it's
important
to
understand
the
distinction
between
someone
else's
hard
drive,
the
cloud
and
cloud
computing
cloud
computing
is
a
style
of
software
architecture
and
software
deployment
that
abstracts
away
physical
infrastructure.
A
A
The
core
idea
here
is
to
have
logical
systems,
logical
computer
systems
that
exist
in
software,
not
in
hardware.
So
you
have
a
logical
computer
system.
You
can
work
with
as
though
it
were
a
computer.
That
is
divorced
from
physical
box
sitting
on
a
desk
or
on
a
rack
somewhere,
and
what
this
enables
then
is
disposable
application
design.
A
No,
your
application
instance
is
a
snapshot
of
your
code
at
a
given
point
of
time,
and
when
you
want
to
update
it,
you
delete
it
and
install
the
new
one
instead
and
just
rebuild
from
scratch,
which
gives
you
a
lot
of
flexibility
and
a
lot
of
new
options
for
maintaining,
deploying
and
managing
your
applications
that
didn't
exist
before,
but
not
all
applications
play
nicely
with
that
model,
especially
older
ones
that
were
written
on
the
assumptions.
You
would
have
just
a
single
server
running
somewhere
and
that's
it
don't
always
play
well
in
this
type
of
environment.
A
A
First
of
all,
and
most
importantly,
split.
Your
code
from
content
seems
obvious,
but
you'd
be
amazed.
How
many
systems
don't
get
this
right
now?
What
do
we
mean
by
code
and
content
code
means
stuff
provided
by
the
developer?
It
could
be
source
code,
it
could
be
configuration
files,
it
could
be
any
number
of
things,
but
it
is
provided
by
a
developer.
A
A
A
A
Content,
meanwhile,
is
provided
by
end
users
could
be.
You
know
that
administrator
using
the
system
could
be.
You
know,
users
posting
comments
whatever
it
is.
It's
provided
by
users
of
the
system,
usually
ad
hoc,
without
any
formal
testing
and
auditing
process.
Although
there
might
be
one
and
its
canonical
definitive
version
lives
in
a
database
of
some
kind
or
on
a
file
system
could
be
an
sql
database
could
be
could
be.
A
local
file
store
could
be
s3
doesn't
matter,
but
whatever
it
is,
it
is
writable
at
runtime.
A
If
you
do,
you
will
have
problems,
it's
amazing.
The
number
of
systems
that
get
this
wrong
remember
your
application
is
disposable.
That's
the
point.
Your
data,
however,
is
not.
If
your
data
is
disposable,
you
don't
actually
have
a
production
system,
yet
you're
still
testing,
but
once
you
are
in
production,
this
is
kind
of
the
workflow
you're
going
to
be
working
with.
A
You
have
your
development
environment,
your
local
laptop
or
whatever,
and
you're
pushing
working
on
code,
making
updates
push
and
pull
to
get,
and
then
at
various
times
you
will
take
a
snapshot
of
what
is
in
git
and
run
that
through
a
build
process,
and
that
build
process
could
be
downloading
additional
dependencies.
It
could
be
compiling
jar
files
or
war
files
or
compiling
typescript
to
javascript,
compiling
sas
or
less
into
css
all
kinds
of
things
that
turn
stuff
in
version
control
to
thing
I
actually
run,
and
that
can
be
all
kinds
of
different
operations.
A
You
really
don't
have
an
in-between
option
between
dev
workflow
code,
workflow
and
content
workflow,
so
make
sure
that
those
things
are
very
very
clearly
divided
and
you
don't
have
anything
that's
kind
of
sort
of
in
between
or
things
that
are
a
little
of
each
in
one
directory.
You
will
have
problems
with
those
okay,
that's
all
well
and
good.
How
about
configuration
is
configuration
code
or
is
it
content?
A
The
whole
point
of
those
applications
is
to
let
people
configure
it
through
the
ui
in
some
fashion,
which
is
cool
and
useful
and
means
that
that
configuration
is
content,
not
code,
because
it
lives
in
the
database
and
is
entered
by
a
user,
which
means
you
can't
use
a
code
workflow
for
it,
because
it
is
not
code
again
either.
One
of
these
is
okay.
A
You
may
have
stuff
that's
a
system
where
some
of
your
configuration
follows
one
workflow
and
some
follows
the
other
workflow
and
that's
fine,
but
you
need
to
be
clear
which
is
which,
because
you
can't
mix
and
match
you
can't
have
something
that
is
both
code
controlled
and
data
controlled,
because
which
one
wins.
It's
not
an
easy
answer.
A
A
It
is
horribly
over
engineered,
I'm
making
it
sound
very
simple
here
there
are
thousands
of
annoying
little
edge
cases
in
that
system
that
make
everything
really
really
hard.
98
chance.
You
do
not
need
something.
That's
complicated.
Instead,
just
look
at
your
configuration
decide.
Is
this
owned
by
a
developer,
or
is
this
owned
by
end
users
and
commit
to
it
being
one
or
the
other
either?
One
is
a
fair
answer,
but
it
has
to
be
one
or
the
other
just
kind
of
decide
which
one
it's
going
to
be.
A
Next
point:
what
happens
at
runtime
stays
at
runtime?
What
does
that
mean?
Well,
we
said
before
you're
going
to
deploy
a
new
version
of
your
application
image
to
data.
That
is
already
there,
which
means
the
data
and
related
services,
like
your
database
or
your
search
index,
and
their
data
are
already
waiting
for
you
in
that
environment.
A
Your
application
exists
separate
from
that
environment
and
needs
to
be
able
to
plug
into
separate
environments
too,
for
example,
dev
stage
prod.
If
you
have
a
staging
server,
that
is
a
different
environment
than
production,
but
you
want
to
use
the
same
application
image.
You
want
to
use
the
same
application
artifact
to
plug
it
in
there,
which
means
the
application
now
needs
to
work
in
both
production
and
staging.
A
Without
modification
you
probably
have
a
test
server
of
some
kind
or
ideally
several
test
instances
on
different
branches,
because
well,
everyone
has
a
testing
server.
Just
some
people
are
lucky
enough
to
have
a
separate
production
server.
So
you
want
to
have
a
separate
test
environment
from
production.
A
So
your
application
needs
to
be
able
to
handle
any
environments
configuration
it
could
be
in
which
means
it
needs
to
have
no
knowledge
of
the
environment
on
its
own.
You
kind
of
hard
code,
any
environment,
specific
information
into
your
application,
because
it's
environment,
specific
it's
going
to
change.
It
will
be
different.
A
This
also
means,
as
a
side
note
that
any
updates
to
your
application
involve
a
restart.
They
involve
taking
turning
off
the
application,
deleting
it
putting
in
a
new
version
and
starting
it
if
your
application
takes
two
seconds
to
boot,
cool
that
that's
really
easy.
If
your
application
takes
five
minutes
to
boot,
which
some
older
java
tomcat
applications
do
I've
seen
java
applications
take
several
minutes
to
start
up.
That's
not
gonna
fly.
That's
five
minutes
of
downtime
every
time
you
wanna
make
an
update.
A
If,
on
the
other
hand,
your
application
takes
a
second
or
two
to
update,
then
just
temporarily
blocking
incoming
requests,
holding
them
at
the
edge
router,
upgrading
the
application
and
then
letting
requests
in
again
users
don't
notice
any
downtime.
They
say.
Oh,
this
request
took
three
seconds
instead
of
100
milliseconds,
once
every
so
often.
A
The
way
to
solve
this
is
dependency,
injecting
your
environment.
By
that
I
mean
database
credentials
should
not
be
in
your
code
or
version
control
anywhere.
They
are
environment.
Specific
and
database
in
this
case
also
means
any
other
services
you're
talking
to
your
cache
server
your
index
search
index
and
so
on.
A
A
The
same
is
true
of
domain
names.
Your
production
environment
is
going
to
have
some
domain
name.
Your
test
server
is
not
going
to
be
running
on
the
same
domain.
It
kind
of
can't
so
your
application
needs
to
not
have
domain
names
hard
coded
into
it.
Ideally,
you're
working
with
a
cloud
hosting
system
where
every
branch
can
be
a
test
environment,
which
means
you
have
an
arbitrarily
large
number
of
possible
testing
sites
with
their
own
domains.
A
You
can't
even
hard
code
in
you
know
prod,
example.com
and
testing.example.com,
because
there
could
be
17
testings
instances
at
the
same
time,
all
with
their
own
domain
name.
You
cannot
hard
code,
these
things
in
the
code
or
really
in
the
database
either.
If
they're
in
the
database,
then
guess
what
you
clone
the
data
to
from
your
production
site
to
your
staging
site,
and
now
all
of
those
entries
in
the
database
are
wrong
and
that's
not
good.
A
A
Sometimes
those
wrapper
libraries
as
well
cool
whatever,
but
all
environment.
Specific
configuration
gets
injected.
This
way,
which
is
kind
of
an
interesting
problem,
because
you
don't
necessarily
control
what
those
environment
variables
are
going
to
be
called
on
a
given
host.
Your
application
may
expect
db
underscore
url,
but
one
host
may
give
you
database
underscore
url.
A
A
So
you
need
some
way
somehow
to
translate
the
hosts
environment
variables
into
your
application's
environment
variables.
It's
very
simple
logic
generally,
but
you
need
somewhere
to
put
that
as
an
example
at
platform
sh,
we
have
a
series
of
utility
libraries
that
just
wrap
environment
calls
and
put
a
nicer
veneer
on
top
of
them
to
make
it
easier
to
call
get
end
and
deserialize
some
of
the
values
that
we
have
stored.
That
way.
A
So,
in
the
case
of
if
you're
using
java
spring,
then
you
load
up
a
platform,
api
library,
you
call
get
credential
for
the
database
service
format,
it's
for
mysql,
cool
and
now
you've
got
my
sql
database.
You
can
then
go
and
do
stuff
with
and
when
you
are
on
a
new
environment,
you'll
get
a
different
set
of
credentials
and
so
you'll
get
a
different
database
that
you
connect
to
for
a
different
environment
and
the
rest
of
the
code
is
no
different.
A
If
you're
writing
in
kotlin
cool
same
same
library
works
on
kotlin
2.,
it's
one
of
the
nice
things
about
kotlin.
If
you're
in
javascript
there's
one
for
javascript
that
talks
in
this
case
we're
hooking
it
up
to
express
so
same
thing.
You
know:
grab
the
mysql
connection,
get
the
credentials
out,
it'll
tell
it
the
port
to
listen
on
and
so
on.
A
If
you're
in
go
same
idea,
we've
got
a
go
application,
a
go
library,
it
wraps
things
up
that
way
and
just
sets
it
as
a
package.
Variable
details
will
vary
by
language
details
of
vary
by
host.
The
point
is
the
details
vary,
so
your
application
needs
to
be
built
on
the
assumption
that
you
have
somewhere
to
put
this
kind
of
glue
code-
it's
small,
but
it
has
to
live
somewhere.
A
Okay,
great.
What
about
local
developments,
because
you're
not
going
to
replicate
your
entire
hosting
platform
on
your
local
environment?
Probably
the
standard
answer
there
dot
m
files,
there
are
dot
and
reader
libraries
in
every
language,
usually
several
that
you
can
use
the
idea
of
dot
n
files
if
you've
not
used
them
before,
I'm
not
exactly
sure
who
was
using
them.
First,
you
have
an
application
that
reads
from
the
environment,
but
you
also
have
a
file
called.env
on
disk
and
then
on
application
start
it
checks
all
right.
Is
there
a
variable
defined
in
env?
A
A
You
know
payment
gateway,
key
equals
and
in
my
local
environment
those
values
will
get
used
and
they
will
talk
to
whatever
my
local
development
system
is
and
the
application
is
fine
and
doesn't
know
the
difference
and
that's
good,
but
that
is
for
local
only
do
not
ever
put
your
dot
in
files
into
git
your
dot
end
files
are
for
local.
They
belong
in
your
git,
ignore
in
production.
You
read
from
actual
environment
variables,
do
not
put
env
files
with
actual
credentials
on
disk
and
certainly
do
not
put
them
in
your
in
your
version.
A
Control
and
also
do
not
put
non-environment
specific
stuff
in
there.
Application
name
or
the
main
admin
user,
or
other
things
like
that
that
are
just
application.
Configuration
that's
going
to
be
the
same
in
every
environment,
do
not
belong
in
environment,
specific
configuration.
This
is
a
separate
pool
of
data.
It
needs
to
be
managed
separately,
do
not
mix
the
two.
A
This
also
applies
to
trusted
domains.
A
lot
of
applications
have
a
setting
where
you
can
say
only
accept
requests
for
this
given
host,
which
helps
avoid
security
holes
where
you
can
cache
poison
by
sending
a
request
to
a
server
with
a
bad
host
header.
So
if
your
host's
header
says
evil.com,
then
if
your
application
accepts
that
it
may
then
use
evil.com
to
generate
its
own
urls
and
then
what
gets
cached
is
a
page
that
has
a
whole
bunch
of
links
to
evil.com.
Whatever
and
great,
you
now
have
a
cross-site
scripting
attack.
A
A
A
A
Fundamentally,
here
your
application
should
be
told
about
its
environment,
not
hardcode
or
assume
things
about
it
in
this
environment.
The
same
way
you
want
classes
and
and
services
to
be
dependency
injected
with
their
dependencies
for
testing
purposes.
Exact
same
principle
applies,
of
course.
Sometimes
you
need
to
ask
the
user
to
configure
connections
that
are
environment
specific
and
that
gets
problematic
first
of
all.
Well,
just
don't
doing
that
through
the
ui
is
a
bad
idea,
except
for
when
you
get
to
installers,
because
well
everything
needs
an
installer
of
some
kind.
A
A
A
If
you
know
you
don't
know
what
the
host
is
going
to
be,
make
sure
that
there's
a
place
for
host
specific
glue
to
get
put
in
before
you
actually
run
the
installer
and
then
the
installer
can
check
and
say.
Oh,
I
already
have
database
credentials
they're
from
the
environment,
I'm
just
going
to
skip
over
that
step
and
not
even
ask
the
user,
so
you
hit
install.
Oh
look.
Database
is
already
there
I'll
use
that
we're
moving
on,
and
then
you
don't
actually
download
any
code
from
the
installer.
A
A
That
also
means
applications
that
do
self
update
not
going
to
fly
because
then
well,
are
you
updating
through
the
ui?
Are
you
updating
it
through
version
control?
You
can't
do
both.
You
have
to
pick
one
or
the
other,
and
a
good
application
will
either
have
two
modes
that
are
mutually
incompatible
unless
you
use
one
or
the
other
or
just
be
updating
code
through
version
control,
but
having
an
application
that
you
can
only
update
in
place
is
a
security
hole
period.
Full
stop,
no
exceptions.
A
You
are
you
need
to
have
your
best
interest
in
mind,
and
that
means
insulating
yourself
from
any
third-party
service
that
you
are
depending
on
including
your
host
itself
as
well
as
especially
any
of
these
other
services,
because
they
may
disappear
out
from
under
you.
Their
terms
of
service
may
change.
A
A
A
If
you're
building
your
system
on
postgres,
then
fine,
if
you
can
download
your
database
and
then
upload
it
to
some
other
host,
you
can
now
pay
anyone
to
host
postgres
for
you,
and
that
keeps
them
honest
that
gives
you
an
esky
patch.
That
means,
if
you
need
to
migrate,
you
don't
need
to
re-architect.
Your
system
do
not
rely
on
third-party
services.
You
cannot
easily
replace
with
someone
else
that
is
a
ticking
time
bomb
that
will
blow
up
in
your
face.
A
It
has
blown
up
in
the
face
of
a
lot
of
companies.
You
don't
want
to
be
one
of
them
and
finally,
no
talk
about
the
cloud
would
be
complete
without
talking
about
microservices,
because
well
clouds
enable
microservices
right.
That's
what
they're,
for
I
mean
microservices
and
clouds
go
together
like
peanut
butter
and
jelly
great,
what
it's
a
microservice
well
according
to
wikipedia.
There
is
no
industry
consensus
yet
regarding
the
properties
of
microservices
and
an
official
definition
is
missing
as
well.
A
A
The
best
consensus,
somewhat
based
on
martin
fowler,
who
coined
some
of
the
terms
and
wikipedia
together
microservice
design,
is
built
around
single
purpose:
components
that
talk
to
each
other
over
dumb
pipes,
ipc
grpc,
you
know
some
kind
of
generic
protocol
not
like
mysql,
has
its
own
protocol
and
postgres
has
its
own
protocol.
Those
are
these:
are
generic
public
formats
they
are
built
by
separate
teams.
Each
component
has
a
separate
team
that
builds
it
and
they
have
independent
releases.
A
So
you
can
release
a
new
version
of
your
user
service
without
having
to
think
about
your
payment
gateway
service.
You
can
update
the
payment
gateway
service
and
not
have
to
worry
about
the
user
service.
There
are
separate
teams
working
independently
to
the
point
that
they
are
all
third-party
services,
just
like
we
were
talking
about
before
that
might
as
well
be
google
or
the
team
down
the
hall
or
the
team
across
the
country.
A
A
Now
this
does
have
a
number
of
benefits.
It
means
that
each
team
and
each
system
can
use
different,
tooling
and
a
different
language.
Even
depending
on
what
you're
doing
you
can
implement
your
web
front,
end
in
php
and
your
user
backend
in
java
and
your
payment
gateway
and
go,
and
everything
works
fine,
because
they're
all
just
talking
to
each
other
over
http,
it
means
you
get
small
focused
teams
for
each
component.
A
Every
component
has
its
own
product
manager,
its
own
developer,
its
own
architect,
its
own
ux
person.
If
necessary,
you
get
very
strong
separation
of
concerns,
because
the
user
stuff
goes
over
here
in
this
code
repository
and
the
product
stuff
goes
over
here.
In
this
completely
different
repository,
it's
going
to
keep
those
two
separated.
A
It
also
means
you
can
scale
them
separately.
If
you
need
to
throw
more
hardware
at
your
web
front,
end:
okay,
fine!
You
can
do
that
and
it
doesn't
affect
your
payment
gateway
at
all.
You
want
to
rewrite
your
user
service
from
node
to
go
because
reasons
you
know
you
need
the
more
performance,
then
cool
that
does
nothing
to
your
payment
gateway.
A
A
A
There
are
a
lot
of
drawbacks
to
this
process
biggest
one
network
latency.
It
takes
a
nanosecond
to
call
a
function
in
the
same
application.
Moving
that
same
function,
call
from
one
computer
to
another
is
now
in
the
microsecond
or
millisecond
range
orders
of
magnitude
slower,
and
you
have
a
lot
more
points
of
failure.
Points
plural
here,
because
you
know
the
the
potential
for
a
function
call
to
break
calling
another
function
called
just
random.
Entropy
is
like
one
in
a
trillion.
A
It's
basically
looking
for
sun
spots
and
gamma
radiation,
calling
from
one
computer
to
another
over
a
network,
there's
only
about
15
pieces
of
hardware
that
could
go
wrong,
plus
all
of
the
software
managing
it.
That
could
go
wrong.
You're
dealing
with
orders
of
magnitude
higher
potential
you
could
need
to
assume
one
out
of
every
thousand
requests
is
just
gonna
die
mysteriously
for
no
good
reason,
and
you
have
to
build
for
that.
A
If
you
need
to
refactor
something
and
move
code
from
the
payment
gateway
into
the
web
front
end,
or
vice
versa,
it's
substantially
harder
because
it
could
easily
be
in
a
different
language.
So
guess
what
you
can't
just
move
the
code
around
you
can't
just
refactor
it
you
have
to
rewrite
it
completely
in
a
different
language.
A
A
A
This
is
more
of
an
issue
in
php,
but
even
in
a
system
like
java
or
go,
you
still
have
to
go
through
the
effort
of
running
your
router
multiple
times
on
every
request,
because
you're
running
it
once
in
every
system
that
you
talk
to,
and
it's
really,
if
one
of
your
of
your
micro
services
going
down
means
the
others
don't
work,
then
it's
not
a
micro
service.
It's
a
distributed
monolith,
which
means
all
the
downsides
of
monoliths
and
all
of
the
downsides
of
a
distributed
system
and
none
of
the
upsides
of
any
of
them.
A
A
better
alternative
is
what
I
like
to
call
a
multi-modal
monolith.
What
is
a
multi-modal
model?
Besides
being
a
mouthful
to
say,
I
can't
believe
I
got
through
that
a
multi-modal
monolith
is
built
by
a
single
team,
so
you
have
one
set
of
developers.
Building
this
thing
it's
built
in
discrete
components,
because
all
good
software
these
days
is
built
in
discrete
components
that
run
together,
cooperate,
but
they
all
deploy
as
once,
they
do
not.
You
don't
have
separate
teams
doing
their
own
deploys
an
update
updates
all
the
pieces
at
the
same
time,
usually
you'll.
A
A
A
You
have
a
task.
Come
in
you,
your
that,
you
need
to
do
that.
You
don't
want
to
block
the
web
request
for
say
sending
a
bunch
of
emails,
for
example,
toss
those
into
a
queue,
and
then
you
have
a
q
worker
sitting
there
that
chews
through
that
process
and
and
takes
care
of
whatever
those
are
separately
and
doesn't
block
the
web
request.
A
A
A
You
could
do
this
in
a
single
single
language.
You
could
just
do
this
in
multiple
languages.
You
could
put
these
all
in
the
same
container
or,
but
you
could
also
put
them
on
different
containers.
You
have
the
same
application
image.
You've
built
the
same,
compiled
image,
you've
built
and
you
spin
it
up
once
in
end
user
web
mode,
and
you
spin
it
up
a
second
time
without
recompiling
in
admin
mode
and
the
third
time
for
running
a
queue
worker
that
doesn't
even
accept
http
requests.
A
So
now
you
can
scale
independent
parts
of
the
system
on
their
own
mult,
add
multiple
workers
at
multiple
web
front
ends
and
the
others
keep
working
if
you're
getting
a
lot
of
traffic.
On
the
your
user
front
end,
your
admin
is
a
separate
container,
possibly
even
on
separate
hardware.
So
it's
not
going
to
get
overloaded.
A
A
A
given
web
request
is
going
to
hit
the
admin
system
and
not
anything
else
that
may
trigger
off
some
qt
processing,
but
that
just
goes
to
a
q
service
and
then
the
worker
works
attaches
to
that
separately.
So
you
only
do
the
work
needed
to
respond
any.
You
have
no
per
request
inter-service
communication.
A
In
summary,
then,
don't
assume
things
the
way
to
be
cloud
friendly
is
to
not
assume
things
do
not
assume
the
environment.
Your
application
is
going
to
run
in,
do
not
assume
the
number
of
web
heads
it's
going
to
have
do
not
assume
the
connections
you're
going
to
have
to
databases
to
third-party
services,
to
payment
gateways
to
search
indices,
don't
assume
the
domain
name.
Your
application
is
going
to
run
on
you,
don't
know
any
of
these
things
in
advance.
A
Don't
assume
that
you
can
write
anywhere
to
the
disk
arbitrarily
you
can't
that's
a
security
hole
have
very
clear,
narrow
places
you
can
write
to.
That
is
for
data.
Only
don't
assume
third-party
services
will
exist
forever.
They
won't
none
of
them.
Do
you
need
to
be
able
to
migrate?
You
need
to
be
able
to
shift
gears
at
a
moment's
notice
when
a
third
party
decides
to
change
things
out
from
under
you
and
don't
assume
that
your
use
case
is
big
enough,
that
you
need
to
go
full
on
micro
services.
A
A
B
Awesome
well,
thank
you
larry.
While
we
just
wait
for
any
questions
to
come
in
here,
I
will
move
through
some
housekeeping
stuff
now
and
then
we
can.
We
can
jump
into
questions
so
again.
Yeah.
Thank
you
for
that
awesome
presentation
entertaining
as
always
the
next
jakarta
tech
talk
happens
on
may
10th.
We
have
per
min
borg
joining
us.
He
is
the
cto
and
founder
of
speedment
and
he'll,
be
presenting
jpa
streamer
expressing
hibernate
jpa
queries
with
java
streams,
and
you
can
register
for
that
session.
Using
the
link
I
just
posted
in
the
chat
jakarta.
B
Ee
has
also
extended
the
deadline
for
submissions
for
the
jakarta
ee
developer
survey.
We
certainly
hope
you
will
consider
providing
you
input
to
help
the
java
ecosystem
and
to
help
the
stakeholders
better,
understand
the
requirements,
priorities
and
perceptions
of
enterprise,
developer
communities,
and
you
can
complete
the
survey
by
again
using
the
link
I
just
posted
in
the
chat.
B
B
So
I
will
post
a
survey
at
the
bottom
here
that
you
can.
Let
us
know
how
we
did
today
and
I
did
see
that
we
just
had
a
question
come
in
and
the
question
is
for.
I
guess
me:
are
you
supplying
a
transcript
of
the
presentation?
Where
can
I
go
to
download
it
as
of
yet
we
do
not
have
transcripts
of
this
presentation,
I'm
not
sure.
If
larry,
you
have
one
for
your
for
yourself,
but
I
guess
yeah.
I
can
turn
it
over
to
you.
A
A
B
Yeah
to
build
on
that,
we
will
be
making
this
session
available
on
the
jakarta
youtube
shortly
after
this
presentation
concludes
and
again,
you
can
always
revisit
this
presentation
by
using
the
link
in
your
current
browser
and
and
you'll
be
able
to
watch
the
recording.
I
see
we
have
a
question
that
comes
in
from
carlos
herrera.
He
asks
what
do
you
think
about
docker
and
kubernetes
configuration
and
credential
management.
Considering
your
point
about
safe,
unsafe,
tooling,
approach.
A
A
They
are
specific
products
of
for-profit
companies,
though
so
you
do
have
to
be
a
little
bit
careful
there.
The
bigger
point
is
your
application
should
be
independent
of
your
containering
system.
I
have
seen
applications
that
are
built
mostly
ruby
applications.
I
see
done
this
way
that
they're
built
in
ruby
and
javascript
and
whatever,
but
the
only
supported
way
to
run
them
is
docker
and
the
only
thing
you
offer
to
for
people
to
run
it
is
docker
container.
Don't
do
that.
That
is
terrible.
There
are
lots
of
ways
to
run
software
that
are
not
docker.
A
Docker
is
not
the
end-all
be-all
if
you're
using
a
cloud-based
host.
Many
of
them
are
not
based
on
docker
platform.
Sh,
where
I
used
to
work
did
not
use
docker
as
its
its
containering
system.
There
are
more
to
containers
than
just
docker,
but
if
your
application
is
only
available
in
docker
as
a
docker
image,
guess
what
you
cannot
run
it
anywhere,
that
is
not
docker
based.
A
So
that's
a
downside
and
different
way
if
your
application
can
run
with
an
arbitrary
container
system-
and
you
tie
it
into
docker
or
kubernetes
for
specific
deployments-
that's
fine!
You
can
move
those
configuration
settings
to
a
different
host
if
you
need
to,
or
if
you
move
to
a
host
that
doesn't
use
docker,
you
can
port
those
pieces
of
the
configuration
to
that
new
host
without
having
to
modify
your
application
code.
A
B
Yeah,
I
think
so.
I
think
it
was
a
good
question
and
a
good
answer
again.
If
you
have
any
more
questions,
please
feel
free
to
get
them
in
we're
just
about
to
wrap
up
here.
So
again,
thank
you,
larry
for
for
joining
us
today
it
was.
It
was
a
great
presentation
and
yes,
please,
watch
the
recording
on
on
youtube
afterwards
at
the
jacardi
youtube
channel
and
feel
free
to
register
or
sign
up
to
present
our
next
jakarta
tech
talk
not
see
any
more
questions
so
again.
Thank
you.
Everybody
and
final
word
from
larry.