►
From YouTube: Leveraging AWS Fargate for running cost-friendly containerized application by Nwani Victory
Description
The Elastic Kubernetes Service (EKS) is one of the managed services within AWS for running container workloads. Although being a highly scalable service, a major drawback is the cost of operation involved. What could be the way out for startups and developers looking to utilize the scalability features that AWS provides to Kubernetes? — AWS Fargate is the way! Through this talk, listeners will be introduced to the AWS Fargate service. Listeners will learn how AWS Fargate was designed to reduce the cost of using Kubernetes through the ECR and EKS. The AWS pricing calculator will be used to show the cost of running Kubernetes through AWS Fargate over a 6months interval. Towards the talk conclusion, listeners will be walked through the steps of using AWS Fargate with a sample Node.js API built using the Fastify framework.
---
KCD Africa 2022 is the 2nd iteration of the Kubernetes Community Days Africa, a CNCF-powered free community event. Visit https://kcdafrica.com for more information.
B
B
C
All
right
so,
first
off
this
stock
is
pretty
much
important
because
minimal
britain
expenditure
is
often
the
goal
for
every
startup.
Every
small
project
and
every
solo
developer.
Having
a
minimal
operating
expenditure
is
something
that
they
look
forward
to
and
they
work
towards
and
just
to
define
that
first
operating
expenditure
refers
to
the
money
that
you
pay
to
run,
to
use
a
service
while
running
your
application.
C
C
These
services
are
built
heavily
for
you
pay
a
lot,
and
that
is
why
they
try
to.
They
make
sure
that
you
have
a
minimum
of
personal
expenditure,
because
you
do
not
want
to
get
built
heavily
at
the
end
of
the
month
and
so
today,
within
the
next
few
minutes,
I'll
be
speaking
on.
How
fargate
helps
developers
who
are
interested
in
running
container
applications
have
very
minimal
operating
expenditure
and.
C
Okay,
so
before
I
move
into
what
fargate
is
I'd,
first
of
all
like
to
take
a
step
back
and
talk
about
containers,
because
fargates
is
a
service
for
running
containers,
so
first
off
containers
are
everywhere.
We
all
use
containers
either
we
use
it
directly
in
running
our
applications
or
which
is
indirectly
for
those
who
work
with
services
such
as
hero
code
netlify.
C
Those
are
customers
and
services
underneath
they
use
containers
also
in
running
the
applications
and
over
the
years,
containers
have
proven
to
be
very,
very
beneficial
for
software
development,
it's
literally
every.
We
also
have
tools
that
are
used
by
millions
of
developers
for
running
containers
and
in
comparison
to
virtual
machines,
which
we
use
here
for
running
applications.
Containers
are
lightweight,
they
are
cloud
native
because
they
fit
well
into
the
cloud
architecture
and
with
that
they
are
very
scalable.
C
They
are
platform
agnostic
also,
so
you
can
have
a
single
container
run
across
multiple
cloud
platforms,
but
there
is
an
issue
with
containers
and
that
is,
containers
do
not
run
on
thin
air.
These
containers
they
run
somewhere
either
locally
on
your
computer,
while
you
are
building
your
application
or
on
the
cloud
using
your
either
on
prem
service
or
a
full
cloud
provider
like
aws,
microsoft,
zero
or
the
google
cloud
platform,
and
so
there's
always
an
infrastructure
that
is
powering
up,
and
this
introduces
some
problems.
C
First
off
this
infrastructure
has
to
be
created,
it
has
to
be
updated
and
when
is
an
issue,
it
has
to
be
patched
alongside
being
monitored,
constantly
to
know
when
to
roll
out
an
update
to
your
underlying
infrastructure
that
powers,
your
containers
and
also
this
con.
This
infrastructure
needs
to
grow
as
your
application
skills,
as
you
scale
from
thousands
to
millions
of
requests.
C
The
underlying
infrastructure
for
your
containers
needs
to
grow
also,
and
this
means
that
you're
paying
more
and
you're,
also
having
toy
from
an
srs
standpoint
toy
refers
to
the
manual
work
that
you
do
repeatedly.
So,
as
your
underlying
infrastructure
is
growing,
there
are
several
things
that
you
need
to
do.
Probably
if
you
spin
up
a
new
server,
you
have
to
install
certain
tools
on
them
before
you
can
run
your
containers
on
them.
So
these
are
problems
that
people
face
before
they
can
use
containers,
and
this
is
where
fargate
comes
in.
C
So
what
exactly
is
fargate
well.
Fargate
is
a
computing
service
on
the
aws
and
the
major
purpose
that
the
main
purpose
for
fargate
is
that
it
provides
the
right
compute
capacity
for
your
cluster
on
aws
fargate
introduces
the
eight
the
serverless
computing
model
as
targets
manages
and
takes
care
of
your
compute
infrastructure.
C
So
generally,
we
know
that
in
the
serverless
model
you
are
basically
using
a
third-party
service
to
run
your
application,
but
you
have
no
idea
of
that
service.
All
you
do
is
just
put
your
application
there.
It
runs
it.
It
takes
care
of
it
and
you
probably
paid
to
use
it,
and
this
is
the
same
ideology
that
fargate
brings
in
to
containers.
C
So
aws
is
the
one
that
manages
the
underlying
infrastructure
for
your
containers
and
just
to
be
clear
here.
When
I
say
on
the
line
infrastructure,
I
mean
the
computing
instances
on
aws
computing.
Sensors
are
the
ec2
virtual
machines
that
you
spin
up,
or
that
is
been
spinned
up
for
you.
If
you
use
some
cloud
formation
to
create
a
a
a
cluster,
so
fargate
is
currently
available
for
the
elastic
container
service
and
the
elastic
kubernetes
service.
The
eks.
C
C
So
now,
back
to
the
question:
is
fargate
really
cost
friendly?
I've
seen
a
lot
of
arguments
about
this
online
and
what
I
would
say
is
it
depends
largely
on
your
use
case.
It
depends
on
how
you
plan
to
use
fargate.
Some
people
have
come
up
to
say
that
oh
is
expensive,
but
one
thing
I'd
like
I'd
like
everyone
to
keep
in
mind
when
you
think
about
this
is
that
cost
does
not
just
cost
is
not
only
the
amount
you
pay.
Cost
also
includes
the
labor
and
time
you
spend
in
running
your
your
cluster.
C
So
if
you
are
spending
a
whole
lot
of
time
managing
these
clusters
manually,
you
can
also
count
that
as
your
cost,
because
it's
more
like
a
time
and
labor
cost
so
in
the
long
run,
pays
off
because
it
reduces
the
time
that
you
spend
in
managing
this
infrastructure
other
than
you
being
the
one
to
manage
them.
Why
not
just
ship
it
off
to
aws
to
manage
it
for
you,
while
you
pay
them
some
money
for
it,
then
also,
if
you
want
to
reduce
your
cost,
you
also
have
the
far
gate
spot
for
four
tolerant
applications.
C
Although
this
spot
is
only
available
for
the
ecs,
not
eks,
so
if
you
are
familiar
with
aws,
we
have
spot
instances
which
allows
you
to
use
spare
compute
instances.
They
are
given
to
you,
but
this
can
be
shut
down
at
any
time.
And
that's
why
there's
a
catch
here
forget
spot
should
only
be
used
for
fault,
tolerant
applications,
because
it
could
be
shut
down
within
a
two
minute
notice
period.
C
C
Okay,
yeah
yeah,
it
seems
like
I
went
off
for
this
okay,
for
so
for
using
the
eks
you're
being
built
based
on
the
clusters
that
you
have
running,
and
you
can
look
at
more
details
on
the
calculation
here.
We
have
the
money
being
generated
here
and
this
is
justice,
so
for
it
it's
like
there's
a
whole
lot
of
things
being
abstracted
for
you
and
aws
just
gives
you
a
single
bit
for
you
to
pay.
Now,
let's
take
a
look
at
fargate.
C
C
And
you
can
see
the
pricing
has
gone
up
and
that's
just
to
demonstrate
that
you're
paying
exactly
what
you
request
for.
It's
not
like
when
you're
using
the
eks
alone,
where
the
eks
gives
you
a
lot
of
things.
So
aws
is
just
giving
you
a
single
view,
but
with
fargate
you're,
paying
just
what
you
request
for
and
what
you're
going
to
making
use
of
so.
B
C
C
But
if
you
feel
tired
having
to
manage
the
line
infrastructure
for
your
clusters,
I
will
tell
you
to
use
fargate
if
you're
wondering
who
are
images
of
fargates.
There
are
three
success
stories
on
the
aws
documentation
for
fargate.
We
have
samsung
koala
and
vanguard,
who
migrated
their
very
large
workloads
into
fire
gates,
but
before
you
move
to
fargate,
there
are
several
constraints
that
I
should
keep
in
mind,
although
they
are
not
much,
they
are
relating
to
networking,
mostly.
C
Okay,
so
the
coins
there
are
18
constraints
to
keep
in
mind
before
migrating
your
workloads
into
far
gate.
Some
of
these
notable
constraints
are,
first
demon
sets,
are
not
supported
for
fire
gates.
So,
if
you
are
making
use
of
demon
sets,
you
should
think
twice
before
moving
to
the
far
gate
or
you
can
make
use
of
stickers
for
your
cluster,
then
two
each
board
has
some
level
of
isolation
as
they
run
within
each
virtual
machine.
C
C
C
For
example,
you
could
have
a
profile
for
the
dev
section
environments
and
each
profile
consists
of
a
namespace,
a
selector
and
some
optional
labels.
Now
this
is
great
because
you
can
have
pods
within
several
profiles.
The
the
concept
of
the
concept
of
bringing
in
profiles
is
for
you
to
organize
the
pods
within
your
cluster.
So
if
you're
like
a
development
pod,
you
can
sorry
if
you're
having
a
development
profile,
you
can
have
certain
ports
within
that
profile.
If
you
have
that
for
staging,
you
can
have
the
pods
within
that.
C
Also
so
having
several
profiles
allows
you
to
organize
the
ports
within
your
cluster
and
there's
there
are
maximum
of
five
selectors
within
each
profile.
So
the
use
of
these
selectors
are
to
organize
the
profiles.
Just
sorry,
the
use
of
each
selectors
are
to
organize
the
ports,
just
like
I've
said
so
when
you
create
a
new
pod,
there's
a
selector
attached
to
it.
If
you
want
the
port
to
be
within
dev,
you
add
the
selector
for
that.
So
there's
like
a
system
where
you
can
organize
these
things
by
yourself.
C
Then
the
scheduling
of
the
cluster
pods
into
fire
gates
is
made
through
the
use
of
kubernetes
controllers
for
those
that
are
familiar
with
kubernetes.
You
know
that
controllers
watch
the
state
of
the
cluster
so,
as
you
create
a
new
port
within
that
cluster,
it
checks
if
the
if
the
selectors
match
between
the
profile
and
the
port
you're
creating
if
it's
match
it,
pushes
it
into
that
profile
that
you've
created
all
within
fargate.
C
C
Yeah
apologies.
I
had
a
rain
fall
earlier
on
all
right,
so
I
stopped
it
using
the
using
far
gates
for
the
eks,
and
the
ek
ctl
tool
is
what
we
use
to
create.
The
fargate
profile,
which
runs
the
pods
so
below.
Here
is
an
example.
Image
of
the
fargate
command
being
used
to
create
a
fargate
profile,
and
one
of
the
things
that
I
love
about.
Fargate
is
how
flexible
it
is.
C
So
the
first
step
to
using
fargate
is
to
have
a
docker
image,
because
the
image
is
your
workload,
the
application
that
or
service
you
want
to
run
on
fargate.
So
this
is
like
a
preliminary
step
before
creating
the
file
gate
cluster
having
a
docker
image,
then
pushing
it
to
the
ecr,
which
is
the
elastic
container
registry.
C
When
you
create
your
workload,
you
specify
the
url
to
the
ecr
repository
in
the
deployment
service.
So
if
you
are
new
to
this,
there
are
several
help
commands
within
the
aws
console
that
will
show
you
how
to
do
this.
An
example
of
it
is
shown
here
within
this
image,
so
so
actually
using
fargates.
The
first
step
is
to
create
the
eks
cluster
and,
like
I
said
earlier
on,
you
have
to
specify
the
far
gates
flag.
C
Otherwise
it
would
be
created
as
a
normal
cluster
without
the
fargate
support,
so
you
execute
the
eksctl
create
command.
Then
you
specify
the
forget
flag
attached
to
that
command.
Underneath
eksttl
uses
cloud
formation
with
some
templates
to
create
the
cluster,
and
it
takes
a
lot
of
time.
I
have
to
mention
that
if
you
want
to
create
a
cluster,
you
probably
want
to
do
something
else
on
the
side,
because
it
will
take
about
20
to
30
minutes
roughly
before
the
cluster
is
fully
created.
C
C
He
would
see
the
ek
ctl
attached
to
the
name
of
the
cluster
that
you
created
here.
A
random
name
was
generated
because
I
did
not
specify
the
name.
If
I
had
specified
that
name.
You
would
have
seen
it
here,
but
yeah,
a
beautiful
unicorn
is
random
name.
It
was
generated
for
the
cluster
now
the
next
is
to
create
a
profile.
C
So
the
image
on
the
left
side
here
shows
the
field
for
a
profile.
The
profile
is
created
as
a
cluster
config
type.
Then
we
have
the
metadata,
which
consists
of
the
name,
which
is
here
I
use
fargate,
facified
cluster
and
basically,
within
this
demo
we
would
be
imagining
that
I'm
trying
to
push
a
fastify
application
to
the
eks.
C
So
fastify
is
a
new
year's
framework
for
creating
servers
up
for
creating
back-end
applications
pretty
much
similar
to
express.js.
That
sounds
familiar
so,
within
this
section
here
within
the
fargate
profile
field,
I
have
two
profiles
being
specified.
First,
is
the
facified
default
profile
with
a
namespace
selector?
C
Then?
Second,
one
is
the
facified
approach
profile.
So,
like
I
said
earlier
on,
within
this
talk
in
a
single
cluster,
you
can
have
several
profiles
for
several
environments
that
you
have
within
your
application.
Here
I
have
the
default
environment,
which
is
dev,
and
I
have
the
second
one
which
is
prod.
C
C
C
C
C
The
after
doing
that,
when
you're
sure
you
have
the
load
balancer
controller
installed,
you
can
now
proceed
to
create
the
load
balancer.
This
is
very
similar
to
the
load
balancers
that
you
might
have
created
in
the
past.
If
you
use
eks
a
lot
but
there's
a
major
difference
here,
and
that
is,
it
has
some
annotations
which
specify
the
ip
target
type.
So
you
can
see
three
annotations
there
and
after
that
we
have
the
selector
which
matches
with
the
previous
ones.
C
Then
the
ports
that
you
want
to
expose,
which
is
post
5050,
that's
where
the
first
five
application
would
be
running
and
that's
the
the
last
step
after
this.
When
you
apply
all
these
configurations,
you
would
have
a
cluster
that
runs
and
that
generates
very
minimal
bill
for
you,
because
you're
only
using
what
you
request
for.
Unlike
the
regular
clusters,
I
would
probably
have
two
instances
with
it.
This
would
probably
have
just
one
for
I
do
then,
as
your
application
grows,
as
you
create
more
pods,
those
instances
will
be
created
automatically
by
aws.
C
A
Yeah
yeah,
in
other
words,
it
happens,
any
question.
Anyone
if
you
have
questions
later
or
you
are
watching
this
later
on
youtube,
and
you
want
to
ask
victory
questions
you
can
reach
out
to
him
on
twitter
at
I.
I
am
one
on
twitter.
Let
me
also
display
the
name,
so
it
shows
yeah.
Okay,
is
this
zero
one
that
we
is
added
or
which
one
is
incorrect?
Let
me
fix
it.