►
Description
Whether you work as a data scientist, ML engineer or software developer, at some point you will need to develop applications – for your customers, products or as a support for the latest and coolest ML model that you have built.
With the introduction of the Cloud, a lot has changed in the way we work with the development and deployment of our applications.
In this talk, we look at 5 things to look for when creating an application in the Cloud age.
A
Foreign
and
welcome
to
another
Jakarta
Tech
talk,
my
name
is
Serena
and
joining
us
today
is
restom
who
will
be
presenting
on
the
topic
of
five
tips
on
creating
modern
Cloud
native
applications.
If
you
have
any
questions
for
rustom
as
we
move
through,
today's
presentation
feel
free
to
ask
them
in
the
chat
or
click
on
the
ask
a
questions
tab
without
any
further
delay.
Rustam
over
to
you.
B
Thank
you
very
much.
It's
a
great
pleasure
to
be
here
today
on
a
actually
it's
a
Pi
Day.
Today,
in
case
you
you,
you
you,
you
haven't,
you
know
noticed
like
I.
Did
it
took
me
some
time
to
actually
realize
it
was
a
paradise,
it's
a
kind
of
cool
day
to
do
this
presentation.
Thank
you
for
having
me
I
am
streaming
I'm
joining
you
from
Oslo
Norway,
and
you
know
good
morning
good
afternoon
good
evening
to
wherever
you
are.
B
If
you
want
to
write
where
you're
located
right
now,
where
you're
joining
in
in
the
chat
feel
free
to
do
so.
Today,
I
would
like
to
talk
to
you
about
this
thing
that
people
talk
about
a
lot.
They
talk
about
Cloud,
they
talk
about
Cloud
native
applications
and
I
want
to
take
a
little
twist
on
that
and
try
to
say
you
know
what
actually
you
know
makes
a
cloud
native
application,
a
cloud
native
and
I
a
few
words
about
myself
just
to
introduce
myself
so,
like
I
said,
my
name
is
rustam.
B
I
live
and
work
here
in
Oslo
Norway
work
for
a
consultancy
company
here
called
computers.
I
am
a
Google
developer
expert
for
cloud
and
also
Java
Champion,
so
I
mean
the
cloud
and
Java
is
kind
of
things
that
I
do
work
quite
a
bit
with
and
I
work
also
a
lot
with
architecture.
So
this
is
a
bit
of
a
digest
of
the
questions.
I
get
as
a
consultant
as
as
the
speaker
at
the
conferences
and
stuff
like
that,
and
also
a
bit
of
a
mix
of
things
that
you
should
be
doing.
B
You
do
not
need
to
do
all
of
those
things
that
I'm
going
to
mention,
but
you
know
the
point
is
to
doing
at
least
one
of
the
things
I'm
going
to
be
mentioning
will
at
least
my
in
my
opinion
will
improve
your
application
as
well.
So
let's
talk
about
Cloud
native
applications,
so
first
of
all
is
that
I
want
to
to
to
start
with
what
is
actually
modern
software
development.
What
is
this
Cloud
native
Publications?
It's
kind
of
called
app
modernization.
It's
called
a
modern
software
building.
B
B
The
other
one
is
a
typical
modern
applications
that
we
need
nowadays
is
something
that
can
actually
digest
data
so
typically
applications
doing
date,
the
pipeline
data
processing
and
all
those
things
they
are
very
different
in
in
a
lot
of
sense
right.
They
are
and
with
the
regular
applications,
I
call
them
regular
applications.
The
first
category
is,
the
important
thing
is
typically
would
be
performance.
You
know
so
they're
quick,
they
are
available.
B
You
know
all
these
kind
of
things,
with
a
data
pipeline
applications,
processing
and
tuning
through
data
and
doing
some
stuff
with
the
data.
It's
a
processing
time.
Obviously,
it's
a
thing
right
because
there's
a
lot
of
data
coming
in
you
need
to
process
this.
You
don't
want
to
lose
data.
You
don't
want
to
do
these
things
and
everything
and
I
mean
it's
still
a
lot
of
things.
Those
two
categories
they
still
do
have
a
lot
of
things
in
common.
So
what
is
typically
in
common
is
that
they
have
to
be
scalable.
B
B
While
you
don't
have
enough
users,
and
so
on
so
and
so
on
right,
so
you
want
to
be
those
applications,
no
matter
what
they
are,
you
typically
have
to
make
them
scalable
you
make
them
both
isolated
in
a
way
but
and
also
still
have
loose
coupling
you
want
to
make
them
reproducible
and
repeatable,
and
you
want
to
do
it
in
a
unified
way.
So
this
is
kind
of
the
the
idea
right.
This
is
the
types
of
applications.
People
come
to
us
and
say:
hey.
B
We
want
to
build
either
a
regular
application,
I
call
them
people
call
them
regular
applications
or
kind
of
data,
intensive
applications,
data
processing
applications
right
so
both
of
those
types
they
have
a
specific
kind
of
business
needs.
So
I
want
to
talk
a
little
bit
about
the.
Why
part?
Which
is
like
what?
What
is
this
thing?
I
mean?
What
why
why
do
we
want
those
modern
applications?
What's
the
point
of
doing
that?
B
Why
can't
we
just
do
it
in
a
different
way
like
we
used
to
do
I
mean
back
in
the
days
when
I
started
working
as
a
developer.
We
were
just
you
know,
you
would
create
an
application,
it
would
have
some
kind
of
server
back-end
database,
something
it
would
have
some
kind
of
front-end.
Typically,
sometimes
it
would
be
a
back-end
rendered
that
front
end
and
sent
it
over.
You
know
JSP
JS,
have
you
know
this
kind
of
things?
B
I,
don't
know,
maybe
even
PHP,
but
we
don't
talk
much
about
that
right,
at
least
as
a
Jaffa
devs.
But
you
know
there
would
be
something
rendering
and
sending
some
data
forward
and
then
you
would
just
deploy
it
in
a
server.
It
would
run
there
if
you
need
it,
you
know
more.
If
you
would
have
more
users,
you
would
have
more
loads,
you
would
just
get
a
beefier
server
and
then
you'll
just
deploy
it
on
the
bigger
server
and
you're
good
right.
B
Nowadays,
things
are
a
bit
different
right.
Now
we
scale
in
a
different
way.
Now
we
have
this
thing
called
microservices.
We
don't
have.
We
don't
have
things
like
I
mean
we
don't.
We
don't
have
to
think
about
certain
things
of
like
scaling
of
the
servers
and
creating
B
for
stuff,
but
now
we
have
to
do
microservices.
B
The
applications
of
this
they
have
to
be
fast
because
you
know
there's
a
lot
of
application,
there's
a
lot
of
competition.
There
is
a
lot
of
maybe
computer
competing
resources
and
you're
competing
products
out
there,
and
if
your
application
is
not
fast
enough,
the
users
might
go
to
something,
that's
something
else,
so
you
want
to
be
able
to
create
applications
that
are
fast.
But
there
is
another
aspect
of
this
speed
thing,
and
that
is
time
to
Market
part
and
that
isn't.
B
That
is
an
interesting
different
story,
because,
while
you
know
you
can
make
your
application
Faster
by
just
making
it
a
bit
more
beefier
and
and
cooler
and
bigger,
you
can.
Actually,
you
still
will
tell
with
the
older
approach.
It
will
take
a
longer
time
to
come
to
to
this
time
to
Market
span
of
time.
You
know
it
will
take
you
longer
to
develop,
because
you
know
you
have
to
rebuild
the
whole
thing.
You
need
to
create
a
new
version
of
your
application.
You
have
to
take
down
the
old
one.
B
B
Then
there
is
this
thing
of
agility
and
Agility
is
a
kind
of
related
to
speed,
but
then
it
is
more
related
to
responding
to
change
so
say
you
want
to
deploy
a
new
functioning,
your
application,
so
like
a
functionality,
or
maybe
you
want
to
deploy
a
newer
version
of
a
part
of
your
application
of
a
little
service
that
your
application
is
using,
because,
typically
you
would
have
some
kind
of
microservices
or
some
kind
of
set
of
smaller
Services
talking
to
to
each
other.
Now
you
don't
have
to
reply,
replace
everything
and
restart
everything.
B
B
The
other
thing,
the
third
thing
and
it
kind
of
goes
or
those
five
things
that
I'm
going
to
mention.
Now
they
go
in
from
at
least
they
try
to
sort
them
from
the
most
obvious
to
a
little
bit
more
obscure
one,
or
at
least
a
little
bit
less
obvious.
So
the
Third
thing
is
reliability,
so
reliability.
What
do
I
mean
by
that
well
I
mean
that
your
application
has
to
be
reliable.
It
has
to
be
there
when
users
need
it,
and
how
do
you
do
that?
B
You
know,
grow
in
size,
I
want
to
say,
grow
in
size,
but
in
reality
it
will
be
growing
in
in
numbers,
because
you
will
have
typically
we'll
talk
about
that
later.
But
typically,
you
will
have
a
bunch
of
small
containers
scaling,
so
you
create
more
instances
of
the
same
application
and
yeah
depending
on
the
number
of
users,
for
example
right
or
depending
on
loads,
that
it
has
to
process
or
some
other
kind
of
metrics,
and
it
also
has
to
be
available.
So
you
also
have
to
make
sure
that
it
is
safe.
B
You
have
very
local
applications.
You
don't
really
need
to
think
about
availability
like
a
global
availability,
but
if
you,
if
you're
developing
an
application
that
should
be
available
all
over
the
world,
maybe
you
want
to
also
think
about
creating
different
clusters
in
the
different
data
centers
different
places
around
the
world,
because
then
you
have
a
smaller
response
time
to
your
application
and
smaller
lag
and
all
those
things
that
you
know
closer
ping
or
lower
ping
to
your
application
brings
to
the
table.
So
that's
the
reliability
part.
B
Then
there
is
this
thing
called
resilience,
which
is
it
shouldn't
be
confused
with
reliability,
but
but
it's
again
relatively
connected
thing
and
resilience
is
about
being
able
to
respond
to
something
that
is
not
supposed
to
happen,
but
still
handling
it
in
a
kind
of
nice
way.
It
can
be
errors,
it
can
be
external
outages
or
something
like
that.
B
It
can
be
also
way
of
telling
that
your
application
is
about
to
do
something
wrong
or
do
something
bad
without
users
noticing
it,
and
that
is
a
part
that
comes
so
the
first
thing
that
I
talked
about
responding
to
errors.
That's
the
fault,
tolerance,
the
second
part.
The
second
last
thing
I
said
it's
about
observability.
So
how
do
you
make
your
application
to
actually
tell
whatever
it
is
running
on?
B
How
is
it
doing
what
is
happening
inside
the
application?
So
maybe
you
want
to
expose
some
kind
of
metrics.
Maybe
you
want
to
expose
I,
don't
know,
say
CPU
usage
or
memory
usage,
depending
on
what
your
application
is
doing
or
number
of
concurrent
users
that
are
on
that
specific
container.
On
that
specific
application
instance,
and
the
last
thing
that
is
unfortunately
quite
often
forgotten,
but
still
very,
very
important
part,
it
is
a
security
and
security
on
many
many
levels.
So
we
still
need
to
think
about
security.
B
We
still
make
you
need
to
make
sure
that
our
applications
are
secure
and
I
also
put
that
into
this
bucket
of
resilience,
because
you
know
hacker
attacks,
DDOS
attacks
and
all
those
kind
of
things
he
needs
to
be
able
to
to
to
handle
that
as
well
with
your
modern
applications,
because
well
you
your
application
and
you
they
all
live
in
this
modern
current
world,
where
all
those
threats
are
out
there
by
fault
tolerance
by
the
way,
probably
should
mentioned
that
as
well.
You
should
think
about
how
does
your
application
handle
internal
errors?
B
So
if
something
wrong
happens,
if
something
fails
inside
your
application,
would
you
do?
Do
you
just
throw
a
stack
Trace
at
the
user
and
just
hope
for
the
best
yeah?
Probably
not
the
best
option
right?
So
you
need
to
think
about
that,
but
also
you
need
to
think
about
what
happens
with
external
errors
as
well,
if
you're,
using
any
service
that
you
have
no
control
whatsoever
over
and
it
still
fails,
what
do
you
do
you
throw
again
a
stack
trace
the
user?
B
Probably
not
a
good
idea
to
do
some
other
trick
tips
and
tricks?
Well,
maybe,
and
then
we'll
talk
a
little
bit
about
that
at
the
end
or
soon
the
other
thing
that
usually
the
business
needs
Define
the
users
ask
for
or
the
you
know,
customers
ask
for.
Is
this
thing,
and
it's
actually
very
often
misunderstood
is
the
thing?
B
Is
the
concept
of
avoiding
lock-in
so
avoiding
vendor
lock-ins,
but
that
is
again
a
funny
thing,
because
people
often
take
it
very
literally
because,
for
example,
let's
say
let's
say
you
have
a
cloud
service,
a
public
cloud
that
Publix
cloud
service
has
a
a
database
offered
as
a
serverless
feature
or
as
macfully
managed
database
solution.
It
doesn't
matter
what
cloud
you're
running
on
it
can
be
your
own
on-prem
solution
or
it
can
be
some
kind
of
public
cloud
provider.
It
can
be
any
wire
public
Cloud.
B
But
the
point
is
you
have
a
cloud
service
and
you
have
this
managed
fully
managed
database
service.
A
lot
of
people
I've
seen
I've
seen
this
happen
way
too
many
times,
and
that's
why
I'm
mentioning
it
they
would
go
well.
We
can't
use
that
we're
just
gonna.
You
know
what
we're
gonna
we're
gonna
use
that
cloud
service,
but
we're
gonna
create
a
VM
virtual
machine,
we're
going
to
install
that
database
solution
onto
that
virtual
machine
and
then
we're
going
to
use
that
and
then
you
would
go,
but
but
why?
B
Why
do
you
want
to
do
that?
Because
this
is
not
the
cloud
way
of
doing
that?
This
is
how
we
used
to
do.
This
is
now
it's
different
and
then
they
would
be
like
well,
because
you
know
we
need
to
avoid
vendor
login
and
then
I
mean
you
can't
say
they're
wrong,
because
you
don't
know
the
premises,
but
the
if
the
premises
is
that
that
managed
database
solution
is
actually
based
on
open
source.
It's
fully
compatible
with
open
source
and
Alternatives
or
say
it's
postgres
or
MySQL
instance,
just
managed
by
somebody
else.
B
Then
I
think
you
should
actually
go
for
that,
because
it
will
be
managed
by
somebody
else.
You
don't
have
to
think
about
upgrading
it.
You
don't
have
to
think
about
making
sure
everything
runs
and
optimize
it
and
restarts
you
know,
taking
backups
and
all
those
kind
of
things
it
will
be
done
for
you
more
or
less
automatically,
depending
on
the
solution
that
you're
using.
B
But
if
it
is
a
specific
to
that
vendor
super
locked
in
kind
of
database,
then
you
probably
maybe
should
look
for
Alternatives
if
the
vendor
lock-in
is
important
for
you.
But
my
point
is
that
I
see
a
lot
of
people
trying
to
avoid
when
they're
looking
at
calling
everything
that
they
can
for
vendor,
locking
and
being
like
super
scared
of
that.
B
Speaking
of
that,
I
want
to
talk
a
little
bit
about
what
is
this
thing
actually
and
by
that
I
want
to
talk
a
little
bit
more
about
what
I
mean,
because
I
met
I,
threw
already
terms
like
public
Cloud,
private
Cloud,
on-prep
Solutions,
and
all
these
kind
of
things
at
you
already
and
if
you're
not
familiar
with
that,
I
probably
should
say
a
few
words
about
that
as
well.
So
the
scalable
applications
that
we're
talking
about
this
Cloud
native
applications
we're
talking
about.
They
don't
have
to
run
on
a
cloud.
B
It
can
run
on
your
own
machine.
It
can
be
running
on
your
own
laptop.
It
can
be
running
on
your
own
term
service
Etc,
but
the
thing
is
making
them.
Cloud
native
simplifies
a
lot
of
things.
It
doesn't
mean
you
have
to
run
on
the
cloud.
It
also
does
not
mean
that
it
has
to
be
fully
cloud
ready
things
it's
actually
without
going
to
the
cloud.
You
will
see
a
lot
of
benefits
that
we'll
talk
about
in
a
bit,
but
so
types
of
clouds
types
of
clouds
is
public
or
private.
B
You
know
there
is
a
lot
of
them.
There
is
well
Google,
Azure
AWS,
a
bunch
of
other
providers,
there
are
providing
public
cloud
services,
there
isn't
private
cloud
services
because
you
know
some
people
just
create
their
own
cloud
where
some
company
sources
you
know
people
they
create
their
own
versions
of
that
they
they
deploy
it
there
and
they
they
use
that
for
various
reasons
it
can
be
privacy,
it
can
be,
you
know,
data
loss,
it
can
be
regulations,
it
can
be
all
kind
of
things.
B
Then
there
is
a
thing
called
multi-cloud.
Multi-Cloud
is
a
different
providers
of
a
cloud
service,
so
say,
for
example,
you
want
to
make
your
application
super
resilient.
So
if
one
of
your
Cloud
providers
goes
down
for
some
reason,
you
know
outage
somebody,
you
know
kills
a
cable
going
into
the
database
data
data
center
or
something
happens.
You
know
power
outage
many
many
many
reasons
for
things
going
wrong.
But
if
something
happens
you
might
you
might
want
to
create
an
application
that
is
total
and
fully
100
resilient?
B
You
might
want
to
run
the
capacity
or
deploy
our
application
onto
two
different
Cloud
providers.
So
then,
if
anything
happens
to
the
infrastructure
of
one
either,
your
application
is
still
running.
We've
seen
examples
of
that
before
I
mean
we've
seen
some
smaller
Cloud
providers
having
a
fire
in
their
Data
Center
and
just
everything
going
down
for
many
many
of
their
of
their
customers
because
well
they
thought
well,
I
mean
it's
in
the
cloud.
How
bad
can
it
be
we're
just
going
to
deploy
it
here
and
just
you
know,
let
it
Let
its.
B
Let
somebody
do
all
the
job
for
us
and
well
one
way
of
doing
that,
a
normal
way
of
doing
that
less
expensive
way
of
doing
that.
It
would
be
to
try
to
spread
your
application
between
different
zones.
If
your
cloud
provider
has
it,
if
you
don't
have
it,
then
you
go
multi-cloud,
you
actually
deploy
into
different
Cloud
providers
and
you
route
the
traffic
between
those
depending
on
different
factors.
B
So
that's
multi-cloud,
and
then
there
is
the
last
thing
that
people
confuse
often
with
multi-cloud,
is
hybrid
clouds
and
how
hybrid
clouds
is
a
different
kind
of
thing.
It's
almost
the
same
as
multi-cloud,
but
not
really.
It
is
a
cloud
plus
on-prem
services.
So
sometimes
like
I
said,
there
are
many
reasons
we're
doing
this
kind
of
things,
but
very
often
you
would
see
reasons
like
regulation.
So,
for
example,
EU
regulations
that
say
sensitive
data
cannot
leave
the
premises
of
you.
Then
you
would
go
either.
A
B
That,
then,
you
might
actually
create
your
own
data
centers
or
you
actually
keep
the
data
or
keep
some
processing
or
whatever.
That
would
be
on
your
own
servers
and
using
cloud
services
to
do
some
other
stuff,
for
example,
serving
the
front
end
or
serving
the
whole
application.
Without
that
sensitive
data
with
serving
that
sensitive
data
out
of
your
own
on-prem
Solutions,
it
can
also
be
things
like
Hardware
requirements.
B
So
say
you
have
an
application
that
runs
on
a
super
specific,
very,
very
fancy,
gpus
or
I
needs
a
specific
kind
of
Hardware
like
I,
know
tpus
or
something
like
that.
Well,
then,
maybe
you
need
to
have
a
hybrid
Cloud
again,
so
most
of
the
things
that
are
running
on
the
cloud,
but
some
of
the
hardware
is
not
available
in
the
cloud.
B
So
then
we're
going
to
put
it
on
our
servers,
we're
going
to
deploy
it
there
and
we're
going
to
serve
the
output
results
or
whatever
to
users
through
the
cloud
or
through
some
other
ways
of
doing
that.
So
there
are
three
different
ways
of
creating
those
scalable
applications
and,
again,
like
I,
said
I'm
going
to
repeat
it
again,
because
it's
kind
of
important
you
do
not
have
to
put
your
application
in
Cloud.
It
can
be
fully
on-prem
solution
as
well
all
right.
B
There
and
yes,
I
know
it's
a
wall
of
text
to
stop
you
from
reading
all
that
wall
of
text,
and
by
this
time
you
probably
stop
listening
to
me,
you're
actually
reading
that
stop
doing
that,
stop
reading
it
I'll
help.
You
don't
worry
so
I
have
highlighted
some
words
that
are
important
here:
I'm
keeping
the
text
but
I'm,
highlighting
the
words
we're
talking
about
scalable
applications,
we're
talking
about
public,
private,
hybrid
clouds
and
so
on,
so
and
so
on.
B
To
actually
make
it
a
little
bit
even
easier
for
you,
I
did
remove
the
routes,
the
rest
of
the
words,
but
now
you
are
actually
getting
a
gist
of
what
we're
building.
If
you
look
a
little
bit
closer,
you
can
even
group
this
words
in
different
categories,
and
the
categories
are
that
you
have
seen
in
the
header
earlier.
I,
don't
know
if
you've
been,
you
know
if
you
noticed
my
headers,
that
I
used
so
far,
I
I,
actually
so
far,
I
used
this.
What
and
how
and
why
in
different
places.
B
So
what
are
we
building?
Well,
it's
a
scalable
applications
running
on
public,
private
or
hybrid
clouds.
Okay,
how
do
we
do
that?
Well
we're
going
to
talk
about
how
in
a
second-
and
why
do
we
want
to
do
that,
and
this
is
the
business
needs
that
we've
been
talking
about
right?
Well,
because
we
want
them
to
be
Loosely
coupled
because
we
want
to
deploy
new
versions
so
fast
and
quick
and
you
know
being
able
to
be
independent
from
each
other
and
all
that
obviously,
coupled
resilient,
we
talked
about
resilience,
manageable,
observable
with
robust
automation.
B
We
didn't
talk
that
much
about
automation,
we'll
do
so
very
soon
responding
to
quick
changes,
so
frequent
changes,
predictable
and
minimum
toil
so
minimum
toil
goes
kind
of
hand
in
hand
with
robust
automation
as
well,
because
if
you
automate
a
lot
of
things,
you
don't
have
to
spend
a
lot
of
time
doing
it
manually
and
again,
you
know
going
back
to
the
way.
I
started
my
career
working
as
a
developer.
B
When
was
that,
like
16
17
years
ago,
it
was
a
lot
of
toil
it,
we
would
have
a
manual
procedures,
would
have
a
document
to
describe
in
how
you
would
deploy
applications.
How
you
would
do
that
you
need
to
maintain
those
you
need
to
follow
those
you
need
to
follow
manually,
all
the
steps,
and,
if
you
just
forgot
about
one
tiny
little
step,
one
tiny
little
dot,
one
tiny
little
step
space
somewhere,
you
would
be
in
trouble.
B
You
would
be
like
what's
happened,
so
automation
is
very,
very
good
for
that,
because
computers
they're
good
at
doing
mundane,
boring
tasks.
We
humans
are
not
so
much
I
mean
we
might
do
it.
Sometimes
some
of
us
might
even
enjoy
doing
that,
but
we're
still
prone
to
doing
some
smaller
or
bigger
errors.
A
lot
of
misconfigurations,
a
lot
of
outages
that
we've
seen
online
in
later
years
is
also
very,
very
often
are
made
by
a
human
kind
of
error.
Configuration
error.
Somebody's
forgot
to
do
something.
B
Somebody
wasn't
careful
enough
doing
something
or
something
like
that.
Computers,
usually
don't
do
that
if
you
tell
them
exactly
what
it
needs
to
be
done
so
robust,
automation,
okay,
so
that
was
the
cloud
native
definition
right
now
is
the
actual
five
tips
that
I
have
been
promising
to
you
in
the
beginning
of
this
presentation,
and
that
is
those
five
things.
So
how
do
you
make
your
application,
Cloud
native,
because
now
I
I
hope
I
sold
you?
The
idea
of
why
do
you
want
to
do
Cloud
native
I
hope,
I
sold
you
the
idea?
B
What
is
that
thing
is,
and
now
I'm
I
want
to
to
to
explain
how
do
you
get
there?
So
how
do
you
get
there?
Well,
first
thing
kind
of
obvious:
again:
they
go
from
most
obvious
to
a
little
bit
less
of
this
and
the
first
one
is
loose
coupling
because
again
you
want
to
have
it
independent
as
independent
as
possible
from
the
different
parts
of
your
applications.
We
talked
a
lot
about
this
in
the
last
some
years.
Last
quite
a
few
years.
B
Actually-
and
it
was
you
know
the
splitting
up-
the
monolith
talks,
how
many
of
you
have
seen
the
how
many
of
you
have
seen
tons
of
those
talks-
and
this
is
the
this
is.
This-
is
the
kind
of
the
splitting
up
the
model.
This
is
the
result
of
that
loose
coupling
thing
right,
creating
microservices
is
cool
and
nice,
and
everybody
talks
about
that,
and
it's
like
super
modern
and
super.
You
know
in
right
now,
but
it
comes
to
the
cost.
B
B
It
also
typically
would
involve
some
kind
of
service
mesh.
You
know
there's
a
lot
of
different
different
ones
out
there.
Probably
the
most
talked
about
is
istio,
but
it's
not
the
only
one.
There
is
a
bunch
of
others,
but
still
you
need
to
think
about
how
data
is
communic
thrown
back
and
forth
between
services.
Do
you
encrypt
your
data?
You
should
you
use
things
like
zero
trust,
for
example,
to
make
sure
that
nobody
can
listen
your
stuff?
Well,
you
should
do
you.
How
do
you
do
that?
B
How
do
you
make
sure
that
you
have
correct
certificates
between
your
services
and
they
can
actually
talk
to
each
other
just
over
Network?
How
would
you
create
your
networks?
There's
a
lot
of
things
that
you
need
to
think,
and
this
is
the
cost
of
doing
that.
But
the
point
is:
if
you
create
loose
coupling
you
need,
you
will
have
a
little
bit
of
cost,
but
you
will
have
also
a
lot
of
gain.
You
will
have
a
lot
of
positive
gain
in
a
way
that
you
can
re
redeploy
services
on
Independent
each
other.
B
You
can
create
a
different
updates
and
upgrades
of
different
parts
of
it.
You
can
even
use
different
programming
languages.
You
know
you
write
one
in
in
Java,
the
other
one
in
kotlin
and
the
third
one,
and
something
else
you
can
actually
do
that
as
well,
which
is
can
be
fun
to
some
extent,
but
maybe
not
go
crazy
with
that
as
well,
but
that's
a
totally
different
story.
B
So
the
second
thing
let's
go
about,
let's
go
to
the
next
one,
so
the
second
thing
is
creating
containers.
Containers
is
nothing
new
with
they've
been
around
for
quite
some
time.
A
lot
of
people
talked
about
that
a
lot
of
people
put
a
kind
of
equality
sign
between
the
word
containers
in
Docker.
It
doesn't
have
to
be,
it
can
be
other
kinds
of
containers,
but
the
point
is
another:
oh
actually,
speaking
of
equal
signs,
a
lot
of
people
say
they
talk
about
containers
as
a
reproducible,
something
right
they
often
talk
about.
B
Reproducible
builds,
but
actually
no
yeah.
Well,
let's
see
recruit.
This
will
build.
You
know
now.
I
can
actually
build
it
here
and
there
and
it
will
be
the
same,
but
it's
not
only
that
it's
actually
also
about
reproducible
deployments,
because
you
know
that
you've
built
that
container.
That
is
a
big
one,
big
artifact.
B
You
can
scan
it
for
security,
you
can
breaches
and
security
halls
and
all
this
you
can
scan
it
for
a
bunch
of
other
things,
and
you
can
let
it
go
through
your
CI
CD
pipeline
as
one
big
chunk,
and
it
will
go
all
the
way
to
production
and
it
will
actually
bring
you
not
only
reproducible
builds,
so
you
can
build
everywhere
and
it
will
be
the
same,
but
you
also
will
have
a
reproducible
deployment,
which
is
a
very
nice
thing.
So
now
nobody
has
an
excuse
of
works
for
my
machine
kind
of
thing
anymore.
B
So
now,
if
it
works
on
my
machine,
it
should
probably
work
on
your
machine
as
well
as
long
as
we
have
a
similar
architecture
underlying
architecture
for
for
for
running
those
containers,
and
you
can
even
make
it
portable
in
between
different
things
right.
You
can
run
it
on
a
Docker
podman.
You
know
different
component
kubernetes,
whatever
you
might
want
to
run
it
on,
so
it's
cool.
It
gives
you
also
the
ability
of
making
things
portable.
B
So
if
something
goes
down,
if
something
breaks,
you
can
easily
deploy
the
same
container
to
some
other
machine,
some
other
platform,
whatever
that
is
with,
hopefully
no
modifications
or
maybe
smaller
modifications.
So
that's
that's
that
right.
We
talked
a
little
bit
about
automation.
Already.
Let's
talk
a
little
bit
more
about
this.
B
Oh
actually,
containers
one
thing
to
mention
about
containers
is
that
also
it
will
help
you
with
avoiding
vendor,
locking,
in
a
sense
that
when
you
deploy
your
applications
to
a
very
specific
application,
server
or
specific
platform,
then
it
will
be
very
hard
for
you
to
move
to
something
else.
Whenever
you
want
to
do
or
if
you
want
to
do
that,
if
it's
container
it
will
be
make
it,
it
will
make
it
easier.
It's
not
going
to
be
guaranteed,
just
grab
your
container
run
somewhere.
B
Maybe
you'll
need
to
do
some
small
tweaks
to
it,
but
it
will
be
easier
to
move
because
it's
everything
is
kind
of
is
isolated
in
the
tiny
little
box.
So
automation,
automation
is
good
thing
and
you
should
automate
all
kinds
of
things
all
that
you
want,
and
you
should
automate
some
more
after
you're
done
just
when
you
think
you've
done
automating
take
another
look.
Try
to
automate
some
more
and
automation
by
automation.
I
mean
automate
things
like
deployment
automate
things
like
testing
automate
things
like
all
kind
of
testing.
B
Really
because
you
have
different
levels
of
testing,
you
can
do
like
unit
tests
and
the
static
code
analysis
test.
You
can
do
security,
vulnerability,
kind
of
tests.
You
have
all
kind
of
things
that
you
should
think
about
and
you
can
and
very
much
should
automate
as
well.
Why
do
you
do
that?
Well,
we
talked
a
little
bit
about
that
as
well.
You
just
will
save
time,
it's
kind
of
boring
to
do
the
same
thing
over
and
over
again,
but
it's
also
less
prone
to
errors.
B
Because,
again,
like
I
said,
computers
are
good
at
doing
boring
stuff.
We
humans,
learning
not
so
much
and
it
will
reduce
the
amount
of
toil.
That
means
you
save
time.
You
have
less
errors.
You
have
less
probabilities
of
Errors.
If
you
want
to
do
it
gradually,
because
a
lot
of
people
come
to
me
and
say:
look
we
don't
know
where
to
start.
We
want
to
do
all
of
those
things,
but
you
know
our
budgets
are
not
enough.
Our
project
managers
don't
want
to.
B
B
So
actually
people
telling
you
what
to
do
or
asking
or
paying
you
to
do
things
actually
see
the
results
of
that
and
ask
you
to
do
more
of
that.
So
that
is
a
kind
of
tip
start
where
it
hurts
more
automate
things
that
are
usually
failing
the
most
automate
things
that
are
the
boring,
the
most
boring
things
that
everybody
hates
the
most
in
the
project
or
you
know
whatever
just
start
somewhere.
That
gives
you
the
most
value.
B
So
that's
automation.
There
are
different
tools
for
different
kinds
of
automation.
There
is
the
tools
for
doing
automation
in
a
sense
of
deployment.
There
are
tools
of
doing
automation,
of
creating
infrastructure
as
code
infrastructure.
So
there
is
things
like
pulling
me.
There
are
things
like
terraform.
There
are
things
like
some
deployment,
scripts
and
CI
CD
scripts.
To
do
this
automation
of
builds.
There
are
different
plugins
that
can
be
pulled
in
by
that
automation
that
they'll
do
the
automated
static
code
analysis.
B
The
dependencies
checking
licenses
checking
a
lot
of
things
that
you
can
actually
automate
and
make
your
life
easier.
Checking
security,
vulnerabilities
I
mentioned
that
already
what
else
static
code
analysis,
yeah
well
I
mean
you
can
do
a
lot
of
things
there.
You
can
automate
a
lot
just
make
sure
that
you
don't
go
overboard
all
at
the
beginning,
just
start
small,
add
a
little
bit
and
a
little
bit
and
see
what
gives
you
value
and
stick
to
that.
Okay.
B
So
that's
automation.
Let's
talk
a
little
bit
more
about
resilience.
Resilience
is
a
funny
animal.
We
talked
a
bit
about
that
already.
The
point
is:
make
sure
how
so
make
sure
what
happens
when
something
fails.
It
can
be
something
inside
your
application.
It
can
be
also
something
outside
of
your
control.
What
do
you
do?
Do
you
want
to
just
you
know?
Let
your
application
fail
and
die,
and
just
why
and
crawled
up
on
the
floor
in
the
server
room
somewhere
and
just
like
you
know,
being
full
panic
and
Go
full
Kernel.
B
Panic
thing:
well,
maybe
not
maybe
want
to
to
do
it
gracefully.
Maybe
you
don't
want
to
expose
well.
Definitely
you
don't
want
to
expose
your
stack
traces
to
users.
Maybe
you
don't
even
want
to
say
that
something
went
wrong.
Maybe
you
just
want
to
say:
hey,
you
know
what
we're
you
know.
I've
received
your
request,
we're
going
to
handle
it.
B
You
know
thanks
I'll
tell
you
when
it's
done,
maybe-
or
maybe
you
want
to
do-
maybe
you
want
to
fail
over
to
something
and
a
lot
of
libraries
and
a
lot
of
Frameworks
actually
give
you
opportunities
to
do
that.
So
there
is
things
like
exponential
back-offs.
There
are
things
like
retries.
There
are
things
like
fallbacks.
There
are
things
like
retries
of
a
failing
service
and
because
all
of
those
things,
obviously
you
can
write
them
by
hand.
B
But
there
is
a
lot
of
logic
that
goes
in
there,
that
you
don't
want
to
rewrite
and
write
actually
to
begin
with,
because,
for
example,
let's
say
what
happens
to
your
application
if
something
goes
down
and
one
part
of
your
application
goes
down
and
then
one
other
part
starts
retrying
and
hammering
that
other
part
with
requests,
there's
a
lot
of
requests
coming
in
it
fills
up.
The
network
fills
up
the
application.
Server
fills
up
everything
everything
grinds
to
the
whole.
You
don't
want
to
do
that.
B
You
want,
for
example,
to
introduce
exponential
backups;
it
will
try,
often
in
the
beginning,
and
will
kind
of
slow
down
the
retries,
not
to
DDOS
your
own
applications.
That's
a
simple
example
for
that
right.
There
are
things
like
that
that
will
help
you
with
all
this
and
I'll
talk
a
little
bit
more
about
this
in
the
context
of
jakarti
and
other
Eclipse
Foundation
things
that
are
under
the
umbrella
of
eclipse
foundation.
So
yeah,
that's
the
full
tolerance.
Observability
observability
is
the
ability
to
tell
you
how
your
application
is
doing,
based
on
some
specific
metrics.
B
B
We'll
talk
about
that
later
in
in
a
little
second
last
thing
last
thing
is
serverless
and
serverless
is
a
kind
of
again
a
little
bit
obscure
and
a
little
bit
slightly
misunderstood
kind
of
thing
that
I
see
going
as
a
pattern
as
a
kind
of
trend
through
through
the
time
lately.
It's
people
think
that,
oh
to
start
to
do
serverless,
we
need
to
run
on
a
cloud
or
we
don't.
What
does
it
actually
mean
people?
You
know
struggle,
sometimes
with
that
as
well.
B
You
can
reduce
your
costs
of
operation
by
using
less
Hardware
or
renting
less
Hardware,
if
you're
going
all
on
public
cloud
and
if
you're
not
doing
that,
you
can
actually
still
do
a
serverless.
So
there
is,
there
are
a
bunch
of
projects
out
there.
For
example,
a
k
native
is
a
good
example
where
it
is
built
on
top
of
a
kubernetes
on
the
bottom.
B
B
Json
websockets!
You
know
all
this
kind
of
things:
security,
stuff,
Jakarta
9-
was
pretty
much
namespace
transition,
but
then
there
is
new
features
and
updates
coming
each
course
10
and
so
on.
But
the
point
is
this
is
a
bunch
of
stuff
that
is
added
on
top
of
regular
Java.
That
simplifies
your
your
use,
your
development
of
your
application
in
bunch
of
libraries.
As
you
see
here,
and
then
there
is
some
stuff
that
comes
on
top
of
that
against
things
like
micro
profile,
but
there
is
also
other
options.
There
are
like
spring.
B
There
are
some
other
things
that
are
implemented
in
different
ways,
but
the
point
is
with
all
of
those
and
especially
micro
profiles
that
I've
been
using
quite
a
lot.
You
will
actually
get
a
lot
of
those
things
that
you
see
here.
You
will
get
obviously
containers
you'll
get
loose
coupling
that's
up
to
you
to
actually
implement,
but
you
will
get
a
lot
of
things
like
fault
tolerance,
observability,
metrics
configuration
all
of
those
things
would
be
coming
to
you
out
of
the
box
using
one
of
those
libraries.
B
B
At
least
that's
my
my
my
my
opinion
with
this
I
would
like
to
say.
Thank
you.
That's
all
I
have
of
the
material
of
the
of
the
of
the
slides,
but
I
would
be
happy
to
to
chat
and
ask
any
questions.
If
you
have
any
questions,
please
ask
them
in
the
in
the
chat
or
the
using
ask
the
question,
but-
and
thank
you
all
for
joining
me
and
thanks
for
coming
all.
A
A
So
if
you
are
interested
feel
free
to
fill
up
the
form
that
I
will
be
putting
in
the
chat
momentarily
and,
of
course
your
feedback
is
super
important
to
us.
So
once
we
end
the
crowdcast
session,
you're
gonna
see
a
green
thumbs
up
or
a
red
thumbs
down,
so
kindly
provide
us
your
feedback
and
your
thoughts
about
what
you
think
about
these.
These
types
of
talks
and
again
some
I,
don't
see
any
questions.
But
thank
you.
Thank
you
so
much
again
and
you.