►
From YouTube: What does cloud-native mean anyway? (sponsored by IBM)
Description
For the last few years the terms cloud-native and microservice architecture have been used interchangeably. However recently people have ceased to view microservices as the go-to solution for all problems, reflecting a growing maturity in our understanding of how to best take advantage of the benefits of cloud computing.
While microservices have many benefits, they also bring their own challenges and better understanding (and some failed microservices projects) have led to a more critical evaluation of suitability of microservices to all problems. This evolved understanding has resulted in a new interest in the place for monoliths in the cloud. Whether referred to as macroservices, or cloud-native monoliths there is a gap forming between the terms cloud-native and microservices that wasn’t there before.
What does this gap mean? How are cloud architectures evolving? How does Eclipse, through Jakarta EE and Eclipse MicroProfile, fit into this new world? Join me as I look at microservices and monoliths in the context of cloud-native architectures.
Speaker(s):
Alasdair Nottingham (IBM)
A
Good
afternoon
my
name
is
alastair
nottingham
and
my
day
job.
I
was
working
for
ibm
as
the
lead
architect
for
the
open
liberty
project
and
the
openmt
project
is
commonly
used
by
ir
customers
to
build
cloud
native
applications
and
for
the
last
few
years,
there's
been
kind
of
this
assumption
that
people
have
a
common
understanding
of
what
cloud
native
means
and
a
big
part
of
that
is.
A
It
means
microservices,
but
this
year
in
particular,
but
growing
over
the
last
years,
has
been
this
kind
of
idea
that
perhaps
microservices
aren't
the
panacea
that
they
were
previously
believed
and
therefore
it's
it's
a
good
time
to
sit
back
and
think
you
know
what
does
cloud
native
really
mean
because
you
know
for
some
people,
cloud
native
means
spring
boot,
but
obviously
that
that
can't
mean
cloud
native,
because
you
can
build
cloud
native
javascript
applications,
no
problem,
so
it's
not
about
a
particular
technology
per
se.
It's
it's
about
something
else.
A
So
what
we'd
like
to
talk
about
with
you
today
is
what
what
does
that
mean
and
as
a
starting
point,
I
thought
I'd.
Do
a
quick
search
online
and
I'd
go
and
see
what
some
kind
of
key
companies
who
sell
software
around
cloud
native
have
to
say,
and
the
first
one
I
came
to
is
vmware
and
you
know
vmware
are
the
company
behind
via
vmware
virtualization
and
the
townsville
kubernetes
platform,
but
also
cloud
foundry
and
spring
boots.
And
you
know
I
thought
well,
you
know
they.
A
They
have
a
long
history
of
being
in
the
cloud
native
space.
So
what
what
do
they
say-
and
I
found
that
definition
interesting,
because
it
isn't
saying
that
it's
a
thing
it
talks
about
it
as
being
an
approach
to
building
and
running
applications
and
that
it's
about
exploiting
the
advantage
of
the
cloud
computing
delivery
model.
A
Now
I
I'm
still
not
quite
sure
if
I've
followed
what
their
view
of
the
cloud
computing
delivery
model
was,
but
one
of
the
things
that
I
noticed
on
the
definition
is
they
have
this
graphic
which
I'm
showing
here,
and
it
shows
the
importance
of
devops
the
importance
of
continuous
delivery,
the
importance
of
containers
and
the
importance
of
microservice
architectures,
and
really
it's
that
bottom
left.
Microservice
architectures.
That
I'm
really
saying
is
that
necessarily
inexplicably
linked
with
cloud
native.
A
So
I
I'd
read
the
vmware
definition
and
I
I
went
and
looked
at
the
the
microsoft
one
and
the
microsoft
you
know
these
are
these
articles
that
define
cloud
native.
They
say
a
lot
of
different
things
and
I'm
just
pulling
out
a
few
points
in
this
one.
I'm
pulling
out
that
it's
about
speed
and
agility,
which
I
I
thought
was
a
very
interesting
point
and
I'm
going
to
come
back
to
that
that
later,
but
you'll
notice
that
they
have
this
graphic,
which
again
I've
reproduced.
A
And
as
my
kind
of
final
look,
I
I
went
to
see
what
red
hat
say
and
red
taps
webpack's
website
was
actually
interesting
because
it
starts
out
pretty
strongly
saying
cloud
native
applications
are
a
collection
of
small,
independent
and
loosely
coupled
services.
Almost
it
doesn't
say
they
are
microservices
that
description.
A
Pretty
much
says
they
are
microservices
small,
independent,
loosely
coupled
that's,
basically
the
byline
of
microservices
and
again
later
on
in
that
page
you'll
see
devops
and
containers
and
microservices
they
actually
pull
in
apis
as
the
fourth
one,
perhaps
because
they
view
continuous
delivery
as
a
part
of
devops,
but
you'll
notice.
All
of
the
all
of
these
kind
of
companies
have
a
similar
vein,
which
is
it's
about
how
you
develop,
how
you
deploy
microservices.
A
The
interesting
thing
about
the
red
hat
definition
is
very
right
at
the
bottom.
Almost
at
the
end
it
has
this
sentence.
You
don't
always
have
to
start
with
microservices
to
speed
up
application
delivery
as
part
of
cloud
native
apps,
and
I
think
that's
quite
important.
Now,
they're,
obviously
thinking
in
terms
of
well,
some
people
have
applications
and
they
just
want
to
take
them
off
virtual
machines
and
run
them
on
containers,
and
they
want
this
definition
to
kind
of
encompass
that.
A
But
I
think
also
it
it's
a
start.
It
was
the
first
time
when
I
really
saw
an
acknowledgement
that
you
know
microservices
weren't,
necessarily
100
the
best
way
to
get
value
out
of
the
cloud
and
having
read
these,
I
decided
well
who
better
to
look
for
a
definition
from
than
the
cloud
native
computing
foundation,
because
you
know
it's
in
their
name.
A
You
would
think
that
they
would
actually
know
how
to
to
to
how
it
defines
what
cloud
native
really
means
and
you'll
actually
notice
that
I've
been
hyphenating
cloud
native
and
that's
because
one
of
my
colleagues
is
kind
of
an
english
fan
and
he
says
under
proper
english,
it
should
be
hyphenated
the
cloud
native
computing
foundation.
In
fact,
a
lot
of
the
other
definitions
are
very
inconsistent
in
the
the
use
of
of
hyphen
versus
not
but
their
definition.
A
A
A
Okay
functions
as
an
approach
to
software
delivery
is
absolutely
the
most
cloud
native
thing
that
you
could
probably
come
up
with
and
the
reason
I
say
this
is
because
in
you
know
mostly
I
you
know
you
can
deploy
functions
on
premise,
but
mostly
people
who
deploying
functions,
they're
deploying
functions
in
a
cloud
and
they're
paying
based
on
usage
and
how
many
calls
to
the
function
are
made
and
that
that
doesn't
work.
If
you're
running
servers
on
premise,
you
don't
get
the
kind
of
benefits
because
you
have
to
pay
for
the
hardware.
A
A
If
you
get
kind
of
a
coarser
grain
than
that
you
get
to
microservices-
and
I
I
know
it
kind
of
might
seem
amusing
to
refer
to
microservices
somewhat
coarser
than
a
coarser.
But
you
know
you
tend
to
have
more
functions
than
you
tend
to
have
microservices,
and
this
is
where
really
the
industry
has
been
trying
to
derive
the
cloud
value
in
this
microservice
area,
and
this
is
the
one
where,
whilst
there's
been
a
lot
of
notable
successes,
you
know.
A
Spotify
netflix
are
two
good
examples
where
companies
have
got
a
lot
of
value
out
of
microservices.
It's
also
a
trap.
There's
a
there's,
a
continuity.
There
are
pros
and
cons
of
all
of
these,
and
some
of
the
early
adopters
of
microservices
have
been
talking
about
something
which
combined
some
of
those
microservices
together
to
be
deployed
into
a
number
of
la
corso
grained,
and
you
know
these
could
be
described
in
a
couple
of
ways.
A
A
And
all
of
these
could
be
built
to
be
cloud
native.
How
is
an
interesting
question
in
some
cases?
It's
more
obvious
than
others,
but
there
is
nothing
intrinsic
about
these
architectures
that
mean
they
can't
be
done
in
a
way.
That's
cloud
native,
and
it's
not
just
me
saying
this,
there's
actually
quite
a
few
people
in
the
industry
who
are
essentially
saying
one
size
doesn't
fit
all
what
you
build
needs
to
be
appropriate
for
your
organization,
and
you
know
some
people
say
you
know
monolith.
A
First,
some
people,
you
know
kelsey
hightower,
predicts
that
in
2020
everyone
will
be
doing
monoliths,
I'm
not
sure.
If
that
was
I'm
not
sure,
I
would
say
everyone
is
doing
monoliths,
but
I
think
there
is
a
growth
in
interest
in
architectures
that
aren't
microservices.
Hence
this
talk
and
interestingly
there's
this
tweet
here
from
somebody
at
uber
and
they're,
moving
many
of
our
micro
services
to
what
to
what
copy
construct
calls
macro
services
and-
and
that
is
because
there
is
a
certain
scale
too
many.
A
A
What
we're
here
for
is
to
deliver
innovation
and
and
value
and
stability
to
our
to
our
user
base
and
microservices
work
best
in
environments
in
you
know,
in
environments
where
that's
not,
you
know
in
some
environments,
but
not
all
essentially
and
there's
some
interesting
surveys
recently
that
say
that
kind
of
interest
in
microservices
is
actually
declining.
Now
this
is
not
a
major
decline.
This
could
you
know
this
is
a
small
decline
and
if
it
was
a
decline
on
if
this,
this
cartoony
survey,
this
is
comparing
2019
to
2020.
A
There's
a
decline
in
microservices.
It's
not
a
particularly
significant
one
in
the
survey
basis.
What
is
interesting
is
the
huge
growth
in
the
monolith
area
and
it's
essentially
doubled
the
number
of
people
responding
who
have
an
interest
in
in
the
monolith
area,
whereas
a
few
years
ago
that
was
considered
to
be
something
no
one
wanted
to
admit
being
involved
in,
and
it's
not
just
it's
not
just
eclipse.
That
is
seeing
this
kind
of
renewed
interest
in
in
monolith.
Jamie
coleman,
who
works
for
ibm,
doing
developer
advocacy.
A
He
did
a
twitter
on
twitter
survey
and
he
actually
found
that
you
know
there
was
a
strong
interest
in
monoliths
and
also
there
was
a
pretty
strong
interest
in
macro
services.
This
kind
of
idea
that
microservices
everyone
is
trying
to
get
to
microservices
is
perhaps
no
longer
no
longer
the
the
thing
it
was
a
few
years
ago,
and
the
big
kind
of
key
reason
for
this
is
there's
been.
You
know
out
as
with
when
more
more
people
try
to
deploy
and
deliver
microservices.
A
A
Calls
procedure
calls
are
much
more
efficient
than
an
http
network
trip.
That's
just
science,
that's
just
physics,
so
there
are
downsides
to
having
lots
and
lots
of
microservices
that
need
to
be
managed
and
deployed,
and
if
you
can't
do
that
independently,
because
perhaps
you
got
your
abstractions
wrong,
perhaps
your
domain
model
is
wrong.
A
A
So
if
microservices
aren't
100,
always
the
best
way
to
get
clout
native
applications
out
there.
What
what?
What?
Why
is
that?
And
you
know
one
of
the
things
I
like
coming
back
to
is
conway's
law
and
conway's
law
effectively
says-
and
this
is
the
official
definition
on
the
screen,
but
it
effectively
says
that
your
software
architecture
essentially
will
model
your
organizational
structure,
and
I
I
have
seen
in
so
many
ways
that
this
is
this
is
true
and
and
it's
it's
essentially
an
aspect
of
human
nature.
A
A
As
microsoft
said,
the
reason
people
are
investing
in
the
cloud
is
for
two
reasons:
one
is
they
think
it's
more
cost
effective
and
the
second
is
just
for
the
promised
benefits
of
speed
and
agility,
and
the
speed
and
agility
is
really
important,
because
that's
how
you
deliver
innovation
and
improvements
for
your
company
for
your
application,
whatever
it's
not
just
about,
you
know
getting
more
requests
to.
Second,
it's
about
how
quickly
can
you
update
and
deploy
both
new
function,
as
well
as
bug
fixes
and
in
order
to
get
that
benefit?
A
You
need
to
look
at
multiple
different
things:
it's
not
just
a
technology
problem
and
if
we
look
at
the
architectures
that
we
defined
earlier
as
monolith
macro
service
microservice
functions
in
certain
different
criteria,
they
they
very
they
they
change.
So,
and-
and
you
know
there
are
more
criteria,
I'm
sure
than
just
as
shown,
but
here,
but
this
is
just
a
a
set
of
them-
I'm
going
to
ignore
the
pricing
one,
because
traditionally
you
know
people
who've
developed,
monoliths
they've
run
in
a
kind
of
capital
expenditure
ways.
A
A
What's
more
interesting
is
when
you
start
going
up
here
and
you
look
at
things
like
operational
complexity.
If
you
have
a
monolith,
the
operational
complexity
is
fairly
low
because
you
have
one
system.
If
you
have
microservices,
you
have
lots
and
lots
of
different
independent
systems
that
are
cross-communicating.
A
The
other
thing
is,
as
you
you
know,
delivering
modular
software
is
a
challenge.
It
is
hard
and
there's
no
getting
away
from
that
and,
as
you
you
know,
it's
not
relatively
low
as
a
requirement
for
a
monolith
to
have
good
modularity
I
mean
you
should
you
should
always
have
good
modularity,
but
if
you
don't
have
good
modularity
in
a
microservice,
your
microservice
is
going
to
end
up
as
a
as
a
distributed
monolith
and
that's
not
somewhere.
You
want
to
be
so.
The
needs
for
modularity
go
higher.
A
A
A
A
If
you
have
a
small
number
of
teams,
there'll
be
a
point
where
they
can't
manage
that
many
microservices
anymore,
because
there
are
just
too
many
for
the
teams
involved,
and
these
should
all
factor
into
how
we
think
about
architecture
and
how
we
choose
an
architecture
for
any
particular
application
when
we
think
about
some
of
the
characteristics
cloud
native-
and
this
is
no
by
no
means
a
exhaustive
lift.
The
things
that
we're
looking
for,
I
think,
are
quickly
creating
and
connecting
new
instances
the
repeatability.
A
So
it's
very
easy
for
you
to
redeploy
in
case
of
failure
or
prove
that
a
change
hasn't
caused
a
regression
or
scale
up
and
scale
down
loose
carpenting
between
your
discreet
systems,
whether
you've
got
a
set
of
monoliths
communicating
or
low.
Hundreds
of
micro
services
is
very
important
resiliency
for
failure,
so
the
ability
to
cope
with
the
downstream
service
going
away,
as
well
as
having
a
good,
quick
time
to
recovery,
and
none
of
these
none
of
these
say
you
have
to
have
a
microservice.
A
A
If
you
want
to
know
more
about
the
technologies
and
micro
function
country
and
how
you
could
use
them
to
build
cloud
native
applications,
the
openmpt
project
team
that
I
lead,
we've
built
a
bunch
of
guides.
They
all
use
liberty,
but
what
you
learn
could
be
applied
to
another
runtime.
If
you
don't
want
to
go
into
production
with
with
liberty
and
with
that.
A
Thank
you
very
much
for
attending
this
talk
and
I
hope
it's
given
you
some
food
to
think
about
whether
or
not
microservices
are
the
right
project
for
you
moving
forward,
and
now
I
can
take
questions
hi.
So
I've
got
a
couple
of
questions
from
the
talk
the
first
one
is.
Would
you
say
that
graphql
is
more
cloud
native
friendly
over
typical
rest
interface
calls,
and
I
don't
think
I
would
define
graphql
as
being
more
or
less
cloud
native.
A
I
I
view
them
as
kind
of
complementary
you'd
use
them
in
slightly
different
scenarios,
but
both
have
a
place
within
a
cloud
native
domain.
So
graphql
is
very
good
when
you've
got
a
complex
data
model,
that's
accessible
via
a
http
request,
but
you
don't
need
all
of
the
data
at
any
one
time.
So
it's
very
good
at
being
efficient
on
the
network.
Client
hop.
A
But
if
you've
got
a
relatively
simple
api,
then
rest
would
just
be
fine,
and
if
the
data
that's
being
transmitted
is
pretty
much
always
always
going
to
be
used,
then
I
don't
see
a
huge
reason
why
you
would
use
graphql.
So
I
would
say
it's
less
about
whether
or
not
that
api
is
more
or
less
cloud
native
friendly.
It's
more
about
the
data
architecture
of
your
application.
A
A
The
second
question
I
have
is
when
microservices
are
more
tightly
coupled.
Does
this
lend
itself
to
taking
a
macro
service
approach
and-
and
I
would
say
absolutely
if
you've
got
tight
coupling
between
the
microservices
you're
you're
really
bordering
into
the
territory
of
distributed
monoliths,
you
might
be
able
to
manage
it
if
it's
a
small
number,
but
any
time
that
you
find
yourself
being
forced
to
deploy,
updates
to
microservices
in
combination.
A
It's
invariably
a
pointer
to
it
not
being
a
microservice
but
a
distributed
monolith
and
in
those
kind
of
situations
from
a
management
perspective.
It's
probably
better
for
you
to
merge
them
into
a
single
micro
service,
because
then
you
can
get
compile
time
checking
and
you
can
get
and
other
things
involved
in
those
interactions
as
as
well-
and
the
third
question
I
had
is:
is
it
valid
to
consider
creating
a
monolith
for
the
cloud
from
new?
A
This
is
you
know,
depending
on
what
you're
building
it
may
be,
that
the
easiest
way
for
you
to
go
is
to
try
and
create
a
a
modular
monolith,
a
well-defined
monolith
which
could
then
be
decomposed
later
into
microservices,
so
think
of
it.
In
terms
of
you
build
a
monolith
because
that's
that's
the
most
effective
way
to
be
efficient
up
front
and
then
you
with
but
design
in
a
way
that
allows
you
to
refactor
into
macro
services
or
micro
services
over
time,
and
I
think
that's
all
the
time
I
have.