►
From YouTube: Container Platforms as Equalizers: Running Health Services Across the World - Jamie Hewland
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Container Platforms as Equalizers: Running Health Services Across the World - Jamie Hewland, Praekelt.org
Praekelt.org creates and operates a number of health and youth-related services which are hosted on containerised clusters around the world, often in countries without an established cloud provider presence. This means that the infrastructure reliability and tooling that may typically be available are not. In addition, as a small team managing clusters in several isolated datacenters around the world, achieving commonality is challenging. While we started using container orchestration because we wanted to increase resource utilisation and deployment agility, we have found the real value has been in our ability to abstract many of the differences between clusters. Now, as we move towards Kubernetes, we will share lessons for shifting developers between different container orchestrators as seamlessly as possible by using Spinnaker as a common continuous deployment tool.
To Learn More: https://sched.co/GrRj
A
Great
okay
and
it
gets
started,
and
thanks
for
coming
to
my
talk
container
platforms
as
equalizers
running
health
services
across
the
world,
so
it's
startup,
I'm,
just
gonna,
introduce
myself
from
the
company
I
work
for
my
name
is
Jamie
I'm
based
in
Johannesburg
in
South,
Africa
and
I'm,
a
site,
reliability,
engineer
and
recently
I've,
also
taken
on
the
role
of
tech
ambassador,
which
is
a
fancy
name
for
I,
spend
a
bit
of
my
time.
Making
talks
like
this
and
writing
and
editing
a
technical
blog.
A
That's
my
Twitter
handle
and
github
Q&A,
which
mean
that
I
work
for
a
nonprofit
organization
called
break
out.
The
dog
was
founded
in
2007
and
it's
based
in
South
Africa,
and
we
aim
to
use
mobile
technologies
to
solve
some
of
the
world's
largest
social
problems
and
the
way
we
do
this
is
we
use
open
source
technology
and
pretty
much
everything
we
make
is
also
open
sourced
and
we
build
scalable
platforms
that
give
people
access
to
information
and
services,
particularly
on
mobile
devices,
and
particularly
with
regards
to
healthcare.
A
I
also
just
want
to
talk
very
briefly
about
nonprofits
and
like
the
way
they
work.
What
we
do
is
we
develop
projects
in
partnership
with
our
funders
and
various
other
stakeholders
and
there's
lots
of
different
projects
going
on
at
any
one
time.
We
just
there's
never
like
one
thing
happening,
and
these
projects
vary
in
size,
so
some
of
them
can
be
quite
large
and
last
a
long
time
or
even
indefinitely
and
can
be
like
at
a
national
scale
or
in
some
cases
we
do
much
smaller
things.
A
That
say
like
a
a
targeted
study
on
a
very
targeted
group
for
a
certain
amount
of
time,
so
they
vary
on
the
right
or
some
of
sort
of
better
known
services
it
and
have
that
much
time
to
talk
about
them.
But
I
will
talk
a
bit
about
monthly
later
in
the
presentation,
so
I'm,
one
of
the
things
I've
kind
of
enjoyed
doing
as
yNN's
kind
of
tech.
A
Ambassador
role
is
spending
some
time
and
looking
back
at
some
of
the
technical
decisions
we've
made
and
why
so
I'm
going
to
talk
a
bit
about
how
we
ended
up
using
containers
and
container
orchestration.
So
this
is
back
in
2014
and
earlier
so
the
influence
to
get
us
onto
containers
kind
of
came
from
two
areas
in
the
companies.
A
So
some
of
our
projects
fall
under
what
I
call
like
the
youth
projects,
and
these
have
historically
mostly
been
sort
of
mobile
sites,
specifically
targeted
at
like
really
low
in
phone,
sometimes
not
even
smartphones,
so
sometimes
sites
like
even
without
JavaScript,
and
they
often
integrate
with
social
media,
and
they
have
a
focus
on
education
in
general
and
particularly
sexual
and
reproductive
health.
And
in
this
case
we
wanted
to
be
able
to
run
lots
of
these
sites
and
talk
about.
Why
so?
A
The
way
we
used
to
do
this
way
back
in
the
day
is
like
you
start
up
a
VM.
You
set
up
your
app
and
we're
Python
shop
and
we
need
lots
of
Django
stuff,
and
so
you
have
a
web
server
an
app
and
a
database
of
some
kind,
and
this
is
very,
very
basic
and
not
cloud
native,
and
but
sometimes
this
kind
of
made
sense,
because
you'd
have
a
funder
and
that
funder
would
fund
some
projects
in
each
project.
A
You
just
give
it
a
server
or
a
VM
and
sometimes
the
project
and
lasts
that
long,
and
then
you
just
shut
down
the
VM
when
you're
done
it's
kind
of
simple
to
manage,
and
but
eventually
you
end
up
doing
more
of
these
when
they
start
looking
similar.
So
you
use
configuration
management
which
is
very
like
ten
year
old
technology
and
this
sort
of
works.
You
can
just
punch
out
more
of
these
things,
but
you
have
some
problems.
You
have
like
multiple
databases.
You're
now
managing,
and
you
also
like
a
big
thing-
is
resource
utilization.
A
So
the
next
thing
we
did
we've
kind
of
just
run
lots
of
sites
on
each
VM
and
then
kind
of
break
out
the
dart
base
into
a
better
manage
separate
unit,
and
obviously
this
also
has
issues.
It's
like.
How
many
do
you,
how
many
sizes
you
put
on
each
server.
You
know
it's,
you
know
if
one
server
goes
down,
suddenly
you
lose
a
lot
of
sites,
and
how
do
you
get
like
the
rights
code
to
the
right
server,
given
that
you've
kind
of
arbitrarily
chosen?
A
Where
to
run
these
things,
and
so
it's
kind
of
obvious
that
this
is
kind
of
heading
towards
container
orchestration,
so
for
these,
like
youth,
related
projects
and
mobile
sites,
what
we
wanted
to
do
is
first
of
all,
just
make
more
efficient
usage
of
resources.
It's
very
important.
We
want
to
automate
recovery
when
a
host
went
down
and
we
wanted
to
also
just
make
it
easier
to
deploy
code.
A
So
then,
from
the
other
side,
we
have
some
projects
which
kind
of
fall
under
the
umbrella
of
health
projects,
and
these
are
historically
been
much
more
messaging
based.
So
we
reach
and
interact
with
users
of
the
technologies
that
work
on
just
any
phone
like
SMS,
USSD
and
most
recently
Watsa,
and
these
projects
have
been
more
focused
on
maternal
health
and
early
childhood
development.
A
So
back
in,
like
2014
and
earlier
we
had
this
thing
called
Bumi.
You
can
kind
of
think
of
it
as
like,
a
very
customized
Twilio.
It
was
a
tool
for
working
with
SMS
and
USD,
integrating
with
various
aggregators
and
carriers
in
different
parts
of
the
world.
You
could
develop
message,
flows
and
message
sets
for
users
in
a
web
UI
when
JavaScript,
and
it
had
this
like
fancy
message
store
where
stole
the
messages
in
react
in
AWS
and
island.
A
You
have
like
a
2g
or
3G
quite
high
latency
network,
so
this
became
problem
and
here's
a
list
of
some
of
the
ping
times
between
AWS
data,
centers
and
Johannesburg,
where
I'm
is
the
best
you
can
do,
is
basically
180
milliseconds
somewhere
in
Central
Europe,
which
is
not
great,
and
you
may
be
wondering,
is
there
really
no
way
closer
and
better?
And
the
answer
is
no.
There
are
no
like
kind
of
first-class
cloud
data
centers
anywhere
in
Africa,
yet
that
tweet
is
a
little
bit
of
this
from
2016.
A
This
is
a
technology.
We
use
quite
a
lot
at
the
time
and
we
still
use
today
and
is
maybe
not
so
familiar
to
people
in
the
States
or
in
Europe,
but
it's
basically
supported
on
pretty
much
every
mobile
phone
ever
made.
If
you
have
a
dial
like
a
star
number
like
star,
1-2-3
hash
can
bring
up
like
a
menu,
and
you
can
do
some
very
basic
interactions
and
we
actually
use
this
to
provide
health
information
to
people
yeah
and
it's
session
based.
It's
also
very
latency
sensitive,
has
a
maximum
duration
and
build
by
time.
A
So
latency
can
be
an
issue.
So
for
these,
like
health
projects,
what
we
wanted
to
do
was,
first
of
all,
just
lower
the
latency
by
moving
our
infrastructure
closer,
so
that
actually
uses
also.
Another
thing
is
that
these
services
are
typically
we
do
them
in
partnership
with
government
organisations.
We
need
the
dice
to
be
in
country,
and
also
this
arm
Connect
platform
in
particular
in
South
Africa,
was
kind
of
really
gaining
traction
at
this
time.
A
So
we
wanted
to
be
able
to
scale
to
support
these
new
users,
and
so
finally,
we've
done
two
containers
and
we're
into
2015
still
quite
far
back.
So
at
my
organization,
there
are
a
few
things
that
made
this
a
lot
more
urgent.
In
2015,
we
partners
partnered
with
Facebook
and
their
free
basics
platform,
to
provide
certain
services
for
free
to
users
on
the
internet
web
platform
and
Facebook,
when
it's
launched
in
a
lot
of
countries
really
quickly.
So
we
wanted
to
deploy
the
easiest
way
to
do.
A
That
was
to
just
deploy
lots
and
lots
of
copies
of
these
like
Django
mobile
sites.
We
also
start
an
incubator
with
a
hundred
new
sites.
We
suddenly
had
this
like
explosion
in
sites
and
then
on
the
health
side.
Like
I,
said,
new
services
in
South,
Africa
were
kind
of
taking
off
and
also
protection
of
personal
information
act.
A
papi
is
kind
of
our
local
equivalent
of
gdpr,
which
was
starting
to
come
into
effect.
So
we
really
need
that
to
be
in
country
and
in
the
cloud
native
space
yeah.
A
A
So
at
that
point
we
decided
to
choose
containers
and
invest
on
this,
and
at
the
time
we
actually
didn't
choose
given
a
chance.
We
chose
me
Susan
marathon,
and
there
are
few
reasons
for
this
and
the
main
ones,
probably
just
it
seemed
simpler.
The
few
up
front
technology
decisions,
peer,
independent
components,
less
sort
of
micro
service
II,
like
design
you
don't
have
to
buy
into
a
networking
model
for
IP
per
pod,
or
anything
like
that
and
marathon
marathon
provides
this
really
nice
abstraction.
A
For
well
really
simple
abstraction
for
running
apps,
where
you
just
run
a
certain
number
of
instances
of
now.
It
also
had
an
emphasis
on
things.
We
were
interested
in
like
resource
constraints.
Again
we
wanted
to
make
good
use
of
resource
good
use
of
our
resources,
and
it
also
had
high
availability
features,
which
we
thought
would
be
great
for
running
containers
in
not
so
reliable
hosting
environments
and
here's
just
an
example
of
some
kind
of
truncated,
JSON,
American,
app
definitions,
very
simple:
there's,
like
a
name
some
number
of
instances,
some
amount
of
CPU
and
memory.
A
This
is
a
list
of
this
is
from
actually
an
internal
like
learning
session
at
the
time.
So
this
is
exactly
the
language
we
use
to
talk
about
these
projects
and
I
just
want
to
highlight
a
few
things
quickly.
So
government
multi-stakeholder
national
information
system,
again
all
about
being
like
in
country
very
important,
using
open
source
technologies,
as
we
always
had,
and
then
co.design.
We
use
sort
of
code
design
process
to
develop
our
services.
A
A
We
also
had
this
idea
of
like
this
national
scale
platforms.
We
want
to
be
able
to
scale
to
support
a
whole
nation
of
users,
and
the
biggest
thing
in
the
end
was
really
that
we
had
this
common
platform
in
different
countries,
so
whether
we
were
deploying
in
South,
Africa,
Nigeria,
Uganda
or
AWS
an
island,
we
were
be
able
to
do
largely
the
same
way,
and
this
did
actually
work
for
us
who
worked
quite
well
allowed
us
to
kind
of
get
Minimum
Viable
Product
set
up
in
these
different
countries
very
quickly.
A
As
soon
as
my
team's,
like,
yes,
Ori
team,
had
deployed
this
container
orchestration
software
and
the
developers
could
get
started
really
quickly
and
get
things
running
quite
fast.
We
could
also
migrate
between
different
hosting
providers,
which
do
not
be
really
important
at
times,
and
we
can
ultimately
kind
of
treat
all
these
different
environments
as
very
similar,
but
in
retrospect
this
was
also
a
really
ambitious
project.
I
think
we
kind
of
tried
to
do
too
many
things
too
many
new
things
at
once
so
on.
A
So
we
kind
of
spent
too
many
innovation
tokens
as
they
say,
but
we
did
deploy
this
to
a
few
different
places
so
against
Thailand,
South,
Africa
and
mob
connect
with
mum
connect,
and
that
was
not
a
platform
to
handover.
We
still
maintain
that
today
because
we're
South
African
base,
but
in
2015
and
2016
we
built
hello
mama
in
Nigeria
and
then
later
in
2016
2017.
A
We
built
family
connect
in
Uganda.
There
was
some
some
parts
of
this
didn't
work
up
as
nicely
as
we
heard
so
high
availability
great,
but
it
only
works
up
to
a
point.
So
here
are
some
of
the
fun
issues
we
had
with
the
hosting
provider
in
Nigeria,
and
you
know,
like
missus,
did
do
quite
well.
In
retrospect,
I
mean
it
did
manage
to
save
us
in
a
few
cases,
but
not
all
cases
and
when
a
complicated
distributed
system
fails.
A
A
A
So
this
buttons,
a
Nigerian
Ugandan
platforms,
have
actually
been
handed
over
now.
I,
don't
have
much
time,
don't
really
have
time
to
talk
about
it,
but
the
link
that
I've
written
the
bird
and
yeah
I
just
want
to
move
on
to
the
lessons
we
learned
from
this.
So
getting
closer
to
the
present
day.
If
you're
building
infrastructure
to
hand
over
to
somebody,
you
know
wondered
what
are
the
concerns?
Did
we
actually
do
the
best?
We
could
have
I
think
the
first
thing
we
did.
A
The
first
problem
we
had
was
we
overestimated
the
scale
of
the
platter
of
the
projects.
We
had
this
idea
of
like
this
national
scale
project
and
meant
it
was
very
big.
Also
this
common
platform.
It
certainly
benefited
us,
but
did
it
benefit
the
people?
We
were
handing
over
to
so
we're
handing
over
quite
a
complex
system
yeah.
A
So
we
kind
of
warned
the
situation
for
a
bit
I.
Think
where
we
had
this
container
Orchestrator
shaped
hammer.
Everything
looks
like
a
nail
yeah.
So
what?
What?
With
the
ideal
system
look
like
I'm,
I'm,
still
really
not
sure
I
mean
maybe
not
contain
orchestration,
strange
thing
to
say:
Keep
Calm
and
you
know
it.
A
Would
it
be
a
distributed
system
or
would
you
just
try
your
best
to
try
and
fit
that
all
on
just
a
simple
web
server,
and
but
we
still
want
Portability,
and
can
we
do
that
without
container
orchestration
and
how
many
of
these
new
tiny
technologies
were
willing
to
give
up?
I,
don't
think
we'd
be
able
to
move
back
to
a
time
before
containers
in
our
organization
but
yeah
but
I.
Think
for
me
the
takeaway
is
that
we
should
have
really
done
is
co-designed
the
infrastructure
as
well
as
the
end
service.
A
So
historically
we
just
do
this
fancy
design
process
with
the
eventual
product
that
you
know
the
user
is
receiving
on
their
mobile
phone.
But
if
we're
going
to
be
developing
infrastructure
to
handover
to
then
the
inheritors
of
that
infrastructure
also
end
users
and
we
need
to
design
for
them,
and
we
shouldn't
really
be
to
dictate
dictating
the
technology
that
others
should
use
without
the
input
and
yeah.
A
So
we
are
actually
going
to
be
doing
this
again.
We
have
still
very
early
stages,
but
we're
looking
at
deploying
this
global
mums
platform
to
some
new
countries,
and
this
will
be
more
whatsapp
based.
Things
have
changed
in
the
last
few
years
and
finally,
I
just
want
to
actually
talk
about
Cuba
native
look
forward
a
bit
so
to
present-day
and
I
think.
A
A
So
when
we
talk
about
cloud
native
technology,
you
know
which
cloud
is
a
native.
It's
really
like
the
cloud
that's
available
outside
of
Africa,
so
going
forward.
I
think
what
we're
planning
to
do
is
where
we
can
use
the
cloud,
and
there
are
some
cases
where
we
don't
have
to
have
stuff
in
country.
Kubernetes
provides
this
common
API
really
between
different
cloud
providers
and
previous
talk
in
this
venue
was
great
to
kind
of
talked
about.
This
idea
of
you
know:
there's
never
before
beans
kind
of
common
API
from
all
the
cloud
providers.
A
We've
just
been
building
things
that
we
wouldn't
have
to.
If
we
were
in
kubernetes,
we
don't
necessarily
need
every
single
fancy
new
feature,
but
we
need
to
not
be
spending
so
much
time,
building
stuff
for
our
cluster
and
Kelsey.
How
Hightower
has
said
the
price
of
admission
to
these
modern
platforms
like
kubernetes,
is
docker
docker
images
and
thankfully
we've
kind
of
paid
that
now
and
yeah,
so
we've
kind
of
had
to
build
some
of
these
things
on
on
mises,
and
it's
not
great
at
first.
A
A
So
this
is
still
kind
of
more
complicated
given
it
is
still
more
complicated
than
we
like,
and
it
still
moves
very
fast
and
we
would
like
for
there
to
be
some
kind
of
defect
or
distribution
kind
of
like
Anna
bunt
kubernetes
at
the
moment
is
just
like
hundreds
of
products,
and
we
can't
really
pick
one
and
say
this
is
what
we're
going
to
use
for
all
our
health
platforms
and
everybody
who
inherits
these
platforms
is
just
going
to
have
to
use
that.
But
maybe
if
there
were
something
more
standard
that
would
be
possible.
A
But
our
strategy
is
really
when
we
can
use
the
cloud
just
use
a
managed
service
and
keep
it
very
simple
and
probably
no
service
meshes
for
a
little
while
so
for
one
of
our
major
projects
on
the
more
youth
side
project,
we
have
solid
using
spinnaker
because
we
can
use
the
clouds.
We
can
start
thinking
about
these
like
higher
level
abstractions
and
it's
kind
of
great,
because
you
can
tie
it
together.
All
these
various
services
that
we
use.
A
We
often
use
like
the
free
and
open
source
versions
of
things
like
github
and
trailers,
and
we
still
currently
deployed
a
mesosphere
DCs
with
this,
and
so
what
we're
trying
at
the
moment
is
deploying
both
DCs
and
kubernetes
as
a
way
of
sort
of
testing
and
proving
communities
and
yeah.
So
the
cool
idea
of
kind
of
the
cool
part
of
being
able
to
think
about
these
higher
level
abstractions
is
that
you
can
change
the
stuff
underneath,
which
is
what
we're
doing
and
eks
amazon's
kubernetes
services,
what
we're
planning
to
use
for
this
and
then.
A
A
Azure
is
supposed
to
be
coming
to
South
Africa
like
this
month,
but
I
haven't
really
heard
anything,
and
then
AWS
has
a
full
data
center
coming
to
Cape
Town
in
2020,
which
is
cool
but
there's
still
a
whole
lot
of
continent
kind
of
between
South
Africa
and
Europe.
So
we'd
like
to
see
cloud
in
more
places,
yeah
and
that's
about
it.
Thank
you
well,
having
and
yeah
special
thanks
to
the
Linux
Foundation
for
paying
for
my
travel.