►
From YouTube: Application Development on Steroids - Peter Gwaka
Description
This talk will describe what a serverless architecture is and how to make use of a serverless backend in your application. It will cover the services that are provided by a serverless architecture and how they add value in the rapid creation of an application.
This talk was recorded at the Jozi.JS meetup group on 22 November 2018.
https://www.meetup.com/Jozi-JS/events/254136610/
Disclaimer: The opinions in this talk are those of the individual and do not necessarily represent those of this channel, the meetup group, or it’s sponsors.
A
Good
evening,
everybody
for
those
that
don't
know
me,
my
name
is
Peter
last
time.
I
was
here,
they
weren't,
so
many
new
faces
I
think
there's
a
lot
of
new
faces
now.
I
work
at
binary,
digital
and
tonight
I'm
here
to
talk
about
this
buzzword
service.
How
many
of
you
have
heard
of
the
service
service
architecture?
So
it's
been
a
big
buzzword
in
2018
and
hopefully
tonight
we
will
get
to
unpack
and
define
what
a
service
architecture
is.
A
So
this
is
a
bit
of
an
impromptu
presentation,
but
hopefully
you
know
together
we
can
kind
of
like
figure
out
what
a
cephalus
architecture
is
so
like
I
said
before,
2018
seems
to
be
like
the
year
of
a
service
architecture,
and
we
hear
a
lot
of
talk
about
service
of
actually
using
your
own
in-house
service.
So,
let's
probably
take
a
look
at
you
know
where
service
architecture
started
well,
not
necessarily
started,
but
where
the
whole
phenomenon
keep
came
about
and
why
exactly
people
are
leaning
towards
more
of
a
service
architecture?
A
Okay,
so
looking
through
the
history
glass,
this
is
one
of
the
more
familiar
kind
of
architectures
with
most
developers.
It's
a
monolithic
architecture
and
the
definition
of
monolithic
from
what
wikipedia
says
is
formed
of
a
large
single
block
of
stone.
So
I
think
that
accurately
defines
what
this
particular
architecture
entails
in
the
sense
that
your
code
base
is
essentially
a
large
cohesive
unit
of
code,
where
you
have
different
components
that
talk
to
each
other
and
share
the
same
resources
and
memory
space.
So
what
are
the
pros
and
cons
of
this
particular
architecture?
A
Well,
that
is
one
of
the
main
drawbacks
of
this
particular
architecture
and
the
big
issue
around
this
kind
of
architecture,
like
you
mentioned,
is
scalability
and
as
well.
All
the
dependencies
are
tightly
coupled
together,
so
which
makes
it
very
hard
for
you
to
separate
different
services
and
actually
scale
them
independently.
Some
of
the
good
sides
of
this
particular
architecture,
as
they
say
that
shared
memory
is
better
than
inter
process
communication,
which
could
be
fairly
true
but
to
a
large
extent,
as
your
application
grows.
A
You'll
find
that
you
will
encounter
a
couple
of
problems
around
memory
and
communicating
with
the
different
services
because
they
are
all
tightly
couples
together
and
you
have
a
lot
of
side
effects
and
you
won't
actually
know
what
is
happening
underneath
the
hood.
So
to
put
all
of
this
into
context,
I'm
gonna
tell
you
a
story
about
a
friend
of
mine,
so
meet
my
friend
Dave
Dave
is
a
developer
and
Dave
was
a
big
star.
Wars
fan.
A
So
a
couple
of
years
ago,
Dave
approached
me
and
said:
like
look,
you
know,
I've
been
thinking
of
actually
creating
my
own
blog
site.
So
would
you
assist
me
in
actually
creating
this
site?
So
then
I
can
blog
about
what
I
love
the
most,
which
is
Star
Wars
and
he
loves.
He
loves
blogging
about
Star
Wars.
So
we
went
on
and
started
creating
this
blog
website,
a
very
simple
site
that
we
two
point
on
to
a
monolithic
architecture
and
everything
was
going
well.
A
A
So
what
happened
was
Dave
ended
up
getting
the
Star
Wars
merchandise,
to
sell
on
his
on
his
blog
site,
so
immediately
they've
realized
that
he
has
to
build
some
kind
of
a
some
some
kind
of
a
shopping
cart
surface
on
his
blog
site,
so
that
kind
of,
like
scaled,
the
whole
block
site,
but
anyway,
Dave
went
on
and
spent
some
weeks.
Creating
this
shopping
cart
service
that
he
bundled
into
this
monolithic
application.
So
after
you
know
deployed
this
particular
service,
I
started
to
get
more
traffic
on
the
sites.
A
More
people
started
to
actually
take
interest
in
purchasing
Star,
Wars,
apparel
and
different
merchandise,
and
we
started
to
actually
incur
some
problems
where
our
application
was
not
running
out
of
memory
space
and
we
had
a
whole
bunch
of
services
that
were
now
adding,
as
you
continuously
want
to
enhance
the
user
experience.
So
this
lift
Dave
and
I
in
a
very,
very
tricky
situation
where
we
start
to
think
of
how
can
we
scale
this
application
and
that's
when
we
started
to
look
into
what
they
call
a
service-oriented
architecture?
A
So,
as
you
can
see,
this
architecture
has
a
style
that
is
based
on
services
and
that's
pretty
much
the
definition
of
a
service-oriented
architecture
where
each
particular
service
is
a
well-defined
unit
of
functionality
that
is
soft
contained,
meaning
that
each
particular
service
is
deployed
to
its
own
server
or
its
own
virtual
machine
or
its
own
container.
In
a
sense
and
looking
at
this
architecture,
we
can
already
see
some
of
the
advantages
of
it
in
the
sense
that
we
can
actually
individually
single
out
certain
services
and
actually
scale
them.
A
So
imagine
like
from
having
a
very
simple
blog
post
blog
site.
We
now
had
a
site
that
had
a
blog
functionality
and
it
also
has
some
kind
of
shopping
cart
service,
and
you
can
imagine
where
you
have
a
shopping,
cart
service
you're,
most
likely
going
to
have
a
payment
service.
So
we
now
had
two
separate
services
that
were
actually
running
and
were
scaling.
A
We
could
actually
cope
with
so
in
that
instance.
What
do
you
do
you
probably
look
into
getting
more
developers
that
can
work
on
different
services,
which
is
great
for
the
service-oriented
architecture
and
you'll
find
that
in
these
kind
of
developer
teams,
where
you
have
different
teams
that
focus
on
a
specific
service,
it
is
a
lot
easier
to
scale
that
service.
It's
a
lot
easier
for
that
team
to
actually
focus
on
delivering
that
particular
service.
A
It's
very
it's
very
easy
as
well
to
remove
a
service
or
add
a
service,
because
it's
not
going
to
affect
everything
else
in
the
application.
So
this
is
pretty
much
a
service-oriented
architecture
where
the
services
are
decoupled
from
the
application.
They
are
pretty
much
standalone
and
they
work
on
their
own
and
you
can
have
specialized
developer
teams
that
could
probably
write
services
in
Java,
JavaScript
or
C
sharp
or
any
other
language
that
will
suit
that
particular
service.
A
So
this
is
a
basic
architecture
for
keeping
Nettie's
where
you
have
you're
keeping
it
is
master
and
you
have
a
couple
of
nodes.
You
obviously
have
to
configure
you're
keeping.
It
is
master
to
know
like
how
many
nodes
as
we're
supposed
to
run
on
when
it's
at
low
capacity
and
then
how
many
nodes
should
actually
spin
up
when
the
traffic
increases,
which
is
quite
a
bit
of
work,
you
know
so
looking
at
it
like
provisioning
servers
is
a
lot
of
work
like
as
a
developer.
We
don't
want
to
spend
so
much
time.
A
Provisioning
servers
worrying
about
how
much
traffic
is
actually
going
to
my
server.
You
know
when
should
I
scale
up
when
should
I
scale
down,
you
have
different
services,
some
services
consume
more
resources
than
others,
and
some
consumed
less
and
actually
figuring
out
when
to
run
something
and
when
not
to
run.
Something
becomes
a
very
very
you
know,
time-consuming
and
tedious
task
here
are
some
of
the
questions.
You'd
have
to
ask
yourself
if
you're
into
provisioning
service
and
as
you
can
see
these
are.
These
are
just
a
few
of
the
questions
that
you
know.
A
We
would
probably
ask
ourselves
when,
whenever
we
starting
a
new
project
or
a
new
application
like
number
one
is
what
size
servers
are
right
for
my
budget
I
mean
it's
really
hard
to
know
upfront
right.
So
you'd
probably
start.
You
know
provisioning
servers
a
little
bit
in
the
dark.
You'll
have
a
rough
idea,
and
probably
if
you
have
a
bit
more
experience,
you
know
you
might
have
a
good
idea
of
how
much
you
might
need
and
how
many
servers
you
might
need
and
the
questions
go
on
like
what
size
servers
are
right
for
my
performance.
A
How
can
I
control
access
to
my
servers,
utilization
of
my
servers
and
scaling
out
or
scaling
up,
and
how
will
I
deploy
my
codes
to
these
particular
servers?
There
are
so
many
varying
questions
which
are
just
a
nightmare
to
continuously
country
continuously.
Ask
so
we
asked
ourselves
all
these
questions
whilst
we're
thinking
of
what
is
the
best
way
to
actually
scale
this.
The
Star
Wars
blog,
slash,
shopping,
cart
to
the
point
where
Dave
was
just
done.
A
So
this
is
kind
of
like
a
brief
introduction
to
you
know
what
we
are
currently
using,
some
of
us
or
most
of
us
and
and
some
of
the
drawbacks
with
that
come
with
provisioning,
your
own
server.
So
it
leaves
the
question:
what
is
a
server
less
architecture
like
I
said
some
say
that
means
no
server.
Some
say
that
there
is
a
server,
but
the
name
is
service,
so
doesn't
quite
make
sense.
Yet
right.
A
So,
like
many
trends
in
software,
there
is
no
one
clear
view
of
what
service
is,
but
there
is
one
school
of
thought
that
is
around
service,
which
is
highlighted
in
the
following
definitions,
so
AWS
says:
serverless
computing
allows
you
to
build
and
run
applications
and
services
without
thinking
about
service.
That
is
like
a
very,
very
basic
definition
from
a
well
known
service
provider,
and
we
would
hope
that
they'll
probably
define
it
a
little
bit
further,
but
this
is
what
they
had
to
say
that
we
don't
want
to
think
about
service.
A
We
don't
have
to
think
about
service
and
that's
basically
yet
another
interesting
site
called
service.
Calm
also
says
that
what
service
really
means
is
that
as
a
developer,
you
don't
have
to
think
about
those
servers
like
if
you
really
think
about
it.
They
had
to
add
about
those
servers.
I
think
the
word.
Those
kind
of
like
highlights
their
hatred
for
provisioning
service,
because
it's
such
a
nightmare,
you
have
to
do
dev
ops.
You
have
to
do
all
whole
bunch
of
things
and
figure
out
what
is
happening.
A
What
is
failing
and
what
is
going
right,
so
it
becomes
a
bit
of
a
problem.
You
know
within
a
particular
organization,
but
moving
forward.
Another
guy
called
Michael
Roberts,
who
is
the
co-founder
of
Symphonia,
explained
service
architecture.
Has
the
following.
You
say:
service
architectures
are
application
designs
that
incorporate
third-party
back-end
as
a
service
and
as
well.
They
also
encode
Brij
ephemeral
containers
on
a
functions
as
a
service.
Now
ephemeral,
pretty
much
means
something
is
short-lived.
A
It
doesn't
last
long,
it's
just
there
for
a
particular
time
and
it's
taken
down
and
this
these
two
services
or
I,
don't
know
what
to
call
them
yeah,
but
pretty
much
services
have
kind
of
like
been
the
building
block
of
what
we
call
a
service
architecture.
So
the
whole
idea
around
ephemeral
containers
is
to
be
able
to
execute
something
when
it's
actually
needed
and
pretty
much
put
it
away
or
destroy
the
whole
container
when
you're
not
using
it
like.
A
Let's
take
a
very
good
example,
you
might
have
a
service
that
is
cold,
maybe
three
times
in
a
month.
You
know
it's
not
really
very
popular
and
you
have
a
running
vm
or
a
running
server.
That
is
dedicated
to
just
simply
run
that
particular
service.
How
much
would
you
pay
every
month?
You'd
pay
excess
right,
because
it's
constantly
running
listening
for
someone
or
something
to
actually
call
it
in
this
particular
instance.
A
So
some
of
the
benefits
like
are
saying,
significantly
reduced
operational
costs
and
possibly
less
complexity
around
your
server
architecture,
because
you
don't
have
to
really
worry
about
it.
There's
somebody
else's,
you
know
doing
all
the
maintenance
and
worrying
about
whether
something
is
failing
or
something
is
actually
working,
and
eventually
this
leads
to
you
spending
more
time,
focusing
on
what
you
do
best,
which
is
writing
code.
A
How
are
you
together?
So
what
have
we
established
like?
First
of
all,
we've
established
that
service
architecture
encompasses
two
different,
but
overlapping
areas,
which
is
back-end
as
a
service
and
functions
as
a
service,
so
back-end
as
a
service
is
typically
used
by
rich
client
applications,
which
includes
your
single
page
applications.
I'm
sure.
A
A
lot
of
you
are
probably
writing
or
deploying
simple
single
page
applications
which
allow
you
to
utilize
such
kind
of
a
service
and
the
whole
ecosystem
is
cloud-based
and
accessible
and
back-end
as
a
service
provides
your
basic
functionality
that
you
continuously
write
for
every
single
project
take
a
wild
guess,
authentication.
Every
time
you
have
to
authenticate
a
user
and
allow
them
to
see
certain
things
within
your
application
and
for
every
project.
You're
constantly
writing
the
same
thing
over
and
over
again
with
slight
variations,
of
course,
and
another
very
popular
thing
is
databases.
A
We
always
have
to
store
data
some
way
somehow
and
we
always
have
to
worry
about
having
our
own
database
server
and
how
it's
gonna
talk
to
our
application,
and
the
list
goes
on
so
looking
at
functions
as
a
service,
so
functions
as
a
service
allows
developers
to
write
their
own
code,
because
if
you
think
about
a
service
platform
right,
you
have
a
third
party
providing
everything
for
you.
Well
pretty
much
everything,
but
a
lot
of
the
times.
We
wanted
write
our
own
custom
code
right.
A
But
the
most
important
thing
is:
we
don't
have
to
worry
about
the
infrastructure
we
just
simply
deploy
to
this
particular
platform,
and
these
platforms
are
very
smart
and
they
probably
use
the
latest
tech
and
obviously
like
some
of
the
big
guys
like
Amazon,
Google
and
Microsoft,
probably
use
a
equal
ten
arise
system
where
a
function
is
called
at
a
particular
time
and
as
as
soon
as
that
particular
function
executes
the
whole
container
is
just
destroyed
and
we
don't
have
to
waste
money
and
resources
continuously
listening
for
someone
else
to
actually
call
that
particular
function.
So.
A
Server,
this
kind
of
architecture,
where
you
have
your
front-end
logic,
which
is
obviously
some
kind
of
single
page
app
or
something
some
kind
of
application.
And
then
you
have
some
database
structure
and
you
have
some
security
measure,
which
is
probably
authentication,
and
you
have
some
back-end
logic,
which
is
a
whole
bunch
of
containers,
listening
or
waiting
to
or
listening
for
event
triggers
to
execute
that
particular
service.
A
So
we
kind
of
like
just
to
destroy
that
whole
container
afterwards
and
after
that
we
have
Microsoft
Azure,
which
was
Microsoft's
response
to
AWS
lambda,
which
is
a
pretty
much
the
exact
same
thing
as
AWS
lambda.
It's
only
that
you
know
they
have
a
different
way
of
handling
what
happens
to
a
container
if
that
function
hasn't
been
cold
for
a
while
and
there's
a
bit
of
a
delay,
I
guess
in
the
way
that
they
call
functions.
A
I
haven't
quite
researched
much
about
Microsoft
Azure,
but
from
what
I
read
that
it's
pretty
much
exactly
the
same
as
as
AWS
lambda
trailing
at
number.
Three
is
Google
App
Engine.
Now
this
is
a
very
interesting
platform.
If
anybody
has
ever
played
on
the
Google
cloud
platform,
Google
App
Engine
actually
is
a
great
solution
for
developers
to
create
fully
fledged
applications
without
having
to
worry
about
performance
and
scaling
so
pretty
much.
They
will
take
care
of
your
hosting.
A
They
will
take
care
of
your
scaling
and
manage
also
a
whole
bunch
of
other
things
that
they
have
included
in
the
package
and
Google
App
Engine
as
well
also
offers
automatic
scaling
in
case
that
your
application
starts
to
get
more
traffic.
They
actually
know
how
to
automatically
scale
your
infrastructure,
okay,.
B
A
After
that,
we
have
Google
Cloud
functions,
so
these
are
like
part
of
the
same
company,
but
two
separate
services
that
are
actually
being
provided
and
Google
Cloud
functions
is
very
similar
to
AWS
lambda.
It
is
pretty
much
a
container
system
where
functions
are
run
when
some
event
is
triggered
and
that
function
executes
and
the
container
is
no
longer
available
as
well.
A
So,
lastly,
we
have
IBM
open
whisk,
which
is
pretty
much
as
well
a
functions
as
a
service
and
pretty
much
exactly
the
same
as
AWS
lambda
and
the
others.
The
only
difference
is
that
this
particular
service
you
can
actually
host
it
on
your
own
local
service,
if
you're
really
into
service
that
much
so
it
just
really,
it
just
really
depends.
A
So
these
are
some
of
the
industry
leaders
and
we
all
know
these
well-known
names.
They
pour
in
a
lot
of
money
and
a
lot
of
resources
to
get
all
these
things
going,
and
they
are
kind
of
like
solving
the
problems
that
developers
are
facing
every
single
day
and
one
of
the
problems
that
we
face
is
service,
because
sometimes
there
really
is
no
point
of
always
constantly
provisioning
service
and
constantly
having
to
go,
go
through
the
whole
DevOps
and
deployment
pipeline.
A
You
know
because
we
are
serving
in
a
world
where
clients
are
key
right
and
you
know
clients,
clients
want
their
stuff
like
yesterday,
so
that
is
pretty
much
the
top,
the
top
five,
the
top
five
in
this
game.
So
we
want
to
draw
some
attention
to
the
Google,
App
Engine,
specifically,
actually,
wall
of
Google
as
a
provider
and
some
of
the
advancements
they
have
made
in
this
particular
area
of
service
architecture.
A
A
You
know
just
to
kind
of
like
test
out
the
whole
platform
and
see
how
everything
works,
and
it
was
then
officially
launched
in
2011
and
since
then,
almost
every
other
month
and
every
other
year,
they
have
been
adding
a
whole
lot
of
stuff
support
for
different
languages.
Support
support
for
different
platforms.
I
will
probably
mention
a
couple
of
the
key
things
that
I
think
were
really
important.
That
allowed
us
to
get
to
a
place
where
we
could
utilize
a
service
architecture.
So
one
of
the
key
things
that
Google
did
was
in
June
2014.
A
Moving
on
to
that
the
same
year,
a
little
bit
later
in
October,
they
acquired
what
we
call
firebase.
Now
we
all
know
Fabrice
right,
very
popular
Google
platform,
and
this
was
acquired
in
2014.
Now.
The
interesting
thing
is
that
firebase
I
think
firebase
was
launched,
must
have
been
in
2010
or
2009
by
two
guys,
and
it
was
first
called
evolve,
and
this
then
evolved
to
firebase,
because
what
they
realized
is
that
a
lot
of
people
were
actually
using
their
platform
for
things
that
they
hadn't
created.
A
They
quite
hadn't
created
their
platform,
for
mainly
they
were
trying
to
a
lot
of
people
to
have
like
real
time
chatting
system
like
some
kind
of
a
real-time
caching
system,
and
then
developers
ended
up
using
it
to
pass
data
to
you
know
different
applications
and
that's
how
they
then
created
something
called
firebase,
but
will
dig.
It
will
dig
a
lot
more
into
that
a
bit
later,
so
fast
forwarding
a
little
bit
too
20:15.
I
think
this
is
also
a
very
important
element.
A
The
Google
App
Engine
launched
something
that
they
called
the
preemptable
VMs.
Now
we
saw
earlier
in
the
service-oriented
architecture
that
you
know
each
particular
service
will
have
its
own
particular
VM
or
a
particular
container.
So
preemptable
VMs
are
pretty
much
the
same
as
ordinary
virtual
machines,
but
the
only
difference
is
that
they
can
be
shut
down
when
they're
not
being
used,
and
they
can
be
spun
back
up
when
they
need
to
be
used.
And
what
does
this
help
with?
A
A
All
right
so
like
I
mentioned
earlier.
Oh
sorry,
one
last
thing
that
I
actually
left
out
is
that
Google
cloud
functions
was
introduced
in
2017,
and
this
also
became
a
package
as
as
part
of
the
Google
cloud
platform
system.
So
you
can
imagine
a
combination
of
the
App,
Engine
and
Google
cloud
functions.
A
Gonna
have
a
look
at
the
firebase
architecture,
and
this
is
pretty
much
what
a
fabrics
architecture
is
it's
very
simple
as
compared
to
some
of
the
diagrams
that
we
saw
earlier,
you
have
a
bunch
of
devices
or
interfaces,
and
then
you
have
firebase
doing
its
magic
and
you
have
some
managed
VMs
and
a
containerized
system.
Now
this
is
a
very
high-level
diagram.
A
It
doesn't
show
much
detail
on
how
everything
works,
underneath
the
hood,
which
is
very
difficult
to
find,
because
you'd
have
to
kind
of
like
dig
through
a
lot
of
different
things,
to
really
understand
how
everything
pieces
together,
but
I
think
from
this
kind
of
like
history.
We
now
have
a
slight
understanding
of
how
everything
kind
of
like
was
pieced
together
to
form
to
form
firebase,
which
is
which
is
actually
what
I'm
currently
using
for
most
of
my
projects.
A
Right
now
so
firebase
offers
us
similar
services,
like
I,
said
that
you
know
we
have
our
back-end
as
a
service.
You
know
which
allows
us
to
authenticate
and
allows
us
to
add
things
to
the
database
without
provisioning
service,
and
it
also
gives
us
good
storage
facility
that
we
don't
also
have
to
provision
as
well
and
the
good
thing
is
you
only
pay
for
what
you're
actually
using
so,
which
is,
which
is
a
big
plus
on
the
pockets
of
most
either
startups
or
organizations
running
a
lot
of
service.
A
So
this
is
pretty
much
like
what
would
what
a
back
end
as
a
service
diagram
would
look
like.
We
have
no
idea
what
they're
doing
in
the
backend
there
and
different
platforms
will
probably
provide
different
services
like
I,
said.
Authentication,
databases
and
storage
are
just
three
of
the
wide
range
of
services
that
they
actually
provide.
So,
oh
you
just
simply
worry
about.
A
Is
writing
your
code
on
the
front
end
and
everything
else
is
handled
by
firebase
I've
already
explained
exactly
what
a
back-end
as
a
service
is-
and
this
is
a
typical
example
of
a
functions
as
a
service.
What
we
have
here
is
some
kind
of
database.
That
is
that
a
message
is
being
written
to
and
we
have
an
event
trigger
that
will
trigger
a
function
as
as
soon
as
a
message
is
written
and
it
will
standardize
that
function
and
return
it
back
to
the
database
so
think
about
it.
A
This
way,
you
can
actually
have
a
image
uploading
functionality
where
you
can
upload
any
size
image
and
you
can
have
a
function
trigger
that
will
listen
and
get
that
particular
image.
Resize
it
and
then
load
it
back.
So
you
won't
have
to
worry
about
resizing
things
upfront,
it
can
all
be
done
in
the
backend
and
a
user
will
never
have
to
know
that
this
is
actually
what
is
going
on.
A
A
A
All
right,
like
I,
was
explaining
earlier
on.
This
would
be
your
configuration
and
then
you
would
initialize
each
of
the
particular
services
that
you
actually
want
to
use
like
I
was
saying
the
database
and
the
storage
and
the
functions
depending
on
what
you
actually
want
to
use
within
your
application.
Now
I'm
going
to
exit
from
this.
A
Is
pretty
much
it
like?
You
would
literally
have
a
water
listener
and
just
simply
listens
to
see
if
someone
is
authenticated
or
not,
and
this
will
automatically
send
you
the
users
unique
ID
that
will
show
you
that
a
person
is
authenticated
or
not.
Now,
if
you
really
think
about
this
and
how
much
code,
we
would
write
initially
to
just
get
authentication
up
and
running
in
any
application.
A
A
A
B
A
To
provision
servers
and
create
your
deployment
pipeline
and
make
sure
that
you
have
the
right
operating
system
and
the
right
dependencies.
You
are
just
literally
ignoring
all
that
and
just
simply
deploying
your
application
for
users
to
start
using.
So
we're
not
worried
about
servers.
We
now
know
that
that
day
is
a
back
end
as
a
service
which
is
pretty
much
all
the
services.