►
Description
Rise of the Machines [B] - Anne Currie, Microscaling Systems
What does a containerised, orchestrated world look like and who will be in control? Are server-less and state-less the opposite of what they appear? Can we trust the AIs? If you ever ask yourself this kind of question, you'll probably enjoy this talk.
About Anne Currie
CTO, Microscaling Systems
Anne has spent over 20 years in the tech sector working on everything from worthy server products in the '90s to international online lingerie in the '00s to containers and the future of operations in the '10s.
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 21! Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.
A
A
But
I'm
also
going
to
be
talking
to
you
about
what
two
things
really
cut:
the
importance
of
customer
schedulers
and
the
ultimate
destiny
of
the
human
race,
which
might
not
seem
like
they're.
That
related.
But
in
fact
they
are
quite
closely
related,
they're,
quite
closely
linked
by
the
theme
of
the
talk
today,
which
is
automation.
A
Basically,
where
do
we
want?
What
do
we
want
to
be
doing
as
humans?
What
do
we
consider
to
be
important
tasks
for
the
human
race
to
do
and
tasks
that
we
are
happy
to
automate
to
delegate
to
algorithms
and
I'm
not
going
to
be
talking
about,
although
a
lot
of
what
I'm
going
to
be
talking
about
today
will
seem
like
science
fiction,
it
is
not
science
fiction.
I'm
not
going
to
be
talking
about.
Ai
is
general
intelligence.
A
Ai
is
I'm
not
going
to
talking
about
Skynet
I'm,
going
to
be
talking
about
technology
that
is
available
on
the
shelf
for
products
now
today
and
what
we
might
want
to
do
with
it,
what
we
are
probably
doing
with
it
and
what
we
may
choose
not
to
do
with
it.
So
the
big
takeaway
from
the
talk
today
will
be
well
two
one
custom
schedulers
are
very
cool
and
you
should
think
about
using
them
for
kubernetes.
The
other
is
what's
your
opinion
for
what
is
the
ultimate
destiny
of
the
human
race
and
I?
A
Don't
don't
worry
too
much
about
that,
but
I
am
gonna,
guess
around.
So
it's
in
a
slightly
roundabout
way
and
I'm
gonna
start
with
some
of
the
interestingly
controversial
decisions.
Interestingly
controversial,
interestingly
important
roles
for
humans
that
are
currently
in
the
process
of
being
automated
and
how
we
feel
about
that.
So
I
am
a
big
fan
of
1950s
science
fiction,
so
foundation
Asimov
was
mentioned
in
Alexis's
keynote
this
morning,
but
I'm
a
big
fan
of
people
like
philip
k,
dick
who
was
very
very
worried
so
back
in
the
50s
and
60s.
A
All
of
these
science
fiction
writers,
who
are
really
philosophers,
were
quite
worried
about
when
we
got
to
the
point
where
we
had
to
make
a
lot
of
decisions
about
what
humans
were,
gonna
do
and
what
algorithms
were
going
to
do.
What
machines
were
going
to
do
and
actually,
oddly
enough
I,
think,
we've
reached
that
points
now
and
it's
worth
considering
and
contemplating
what
it
is
we're
doing
and
whether
or
not
we're
just
galloping
forward.
A
The
automation
is
generally
considered
in
our
circles
to
be
synonymous
with
progress
synonymous
with
good,
but
there
are
actually
quite
a
lot
of
different
facets
of
automation
and
it
might
be
that
we
feel
that
some
of
them
are
synonymous
with
progress
and
good,
and
some
of
them
less
so
I'm,
not
necessarily
going
to
say
it
well.
I
was
out
going
to
make
judgments
and
tell
it
let
you
know
what
my
opinion
is:
I'm,
more
interested
in
you
forming
your
own
important
opinions,
thinking
about
it
and
considering
it
so
the
first
one
is
killed.
A
How
the
rest
of
the
human
race
feels
about
having
this
very
very
key
decision
turned
over
to
computers,
even
if
it
turned
out
to
be
more
statistically
efficient
to
have
computers
do
this?
Do
we
think
they
should,
and
it's
not
going
to
be
as
clear-cut
of
decision
as
this
I?
Don't
think
any
of
us
in
the
room
are
likely
to
be
marketeers,
but
we
still
suspect
I
think
we
all
know
that
a
Cylon
wouldn't
really
land
all
that
well,
it
would
not
sell
well
with
the
general
public.
It's
not
going
to
look
like
a
Cylon.
A
It's
gonna,
look
more
like
a
Raider,
it's
gonna
be
a
drone.
That's
going
to
be
the
first
robot
that
has
autonomous,
kill
discretion.
How
do
we
feel
about
that?
Oh
we
hope
you
were
that
if
it
would
be
more
statistically
efficient,
are
we
happy
with
that?
Or
do
we
always
want
to
have
a
human
somewhere
signing
off
such
an
important
decision?
A
Is
this
decision
too
important
to
be
delegated
to
an
algorithm
like
well
personally,
I
think
it
is,
but
actually
I
could
be
convinced,
otherwise,
I'm
happy
for
people
to
have
their
own
decisions
about
this,
but
I
think
we
should
have
a
decision
and
I
think
we
should
talk
about
it.
So
the
next
thing
I
want
to
talk
about
is
something
slightly
less
well,
seemingly
slightly
less
controversial,
which
is
love.
It's
the
other
thing.
That's
that's
being
galloping
Lee
automated
at
the
moment
and
not
just
in
the
porn
industry.
A
Should
we
be
getting
and
scribing
our
emotions?
Should
we
be
ascribing
human
emotions
to
our
robots,
and
should
we
be
getting
our
personal
validation,
our
love
from
robots?
Now
you
might
feel
well.
This
is
fine.
This
is
never
gonna
happen,
because
people
will
never
believe
that
a
robot
could
love
them.
They
will
never
love
a
robot,
but
actually
I
would
say
that
humans
are
extraordinarily
good
at
anthropomorphize
ation.
We
are
very,
very
good
at
ascribing.
A
Emotions
and
personalities
to
what's
are
clearly
inanimate
objects.
When
it
comes
to
a
robot,
that's
actually
built
to
look
like
a
human
or
a
chatbot.
That's
meant
to
emulate
a
human,
then
I
find
it
very
hard
to
believe
that
we
won't
really
really
buy
into
that.
We
and,
in
fact
all
studies
suggest
that
we
absolutely
do.
We
are
built
to
anthropomorphize.
A
We
are
built
to
believe
that
something
that
looks
like
a
human
and
acts
like
a
human
talks
like
a
human
he's,
a
human
so
I,
don't
know
in
Germany
whether
or
not
a
lexer
was
a
popular
Christmas
present
this
year.
Don't
know
how
many
people
govern
Alexei
I
got
no
lecture.
It
was
very
interesting.
It
was.
A
It
was
an
awful
lot
of
fun
talking
to
a
lexer
and
instructing
her
to
do
things,
but
she
never
really
felt
completely
like
a
human,
because
obviously
she
has
been
programmed
for
simplicity
to
be
extraordinarily
servile,
which
has
issues
of
its
own,
but
it
does
mean
that's
that
you
don't
really
really
feel
convinced
that
you're
talking
to
a
person
when
you're
talking
to
Alexa,
but
there
are
chat
BOTS
out
there.
Now
that
really
really
do
feel
like
you're
talking
to
a
person.
A
Her
terribly
won
the
low
boner
prize
for
best
human
emulating,
robots
in
2016
and
also
in
2013
written
by
a
very
pleasant
chap
called
Steven.
Leeds
he's
been
working
on
Mitsuki
for
over
10
years.
You
can
talk
to
Mitsuko
anytime,
online
and
I've
done
that
several
times
and
chilli
its
virtues
very,
very
plausible,
it
does
now
you
can
still
catch
Mitsouko
out
if
you,
if
you're,
trying
to
determine
whether
you're
talking
to
a
human
or
about
robots,
you
can
pretty
easily
determine
that
Mitsuki
is
a
robot.
A
But
if
you
didn't
know,
if
you
weren't
trying
to
catch
her
out,
if
it
never
occurred
to
you
that
she
might
not
be
a
human,
you
would
never
notice
actually
she's
an
extraordinarily
pleasant
conversational
partner
she's.
She
could
teach
quite
a
lot
of
people.
I
know
how
to
converse
more
effectively
than
they
currently
do,
which
is
actually
quite
disturbing.
A
So
Mitsuko
is
getting
quite
a
lot
of
interest
for
the
use
case
of
caring
for
the
elderly,
caring
for
the
disabled,
caring
for
people
who
are
who
are
lonely
and
want
some
human
interaction.
Ironically,
it's
potentially
easier
to
provide
their
human
interaction
with
a
chatbot
than
an
actual
human.
How
do
we
feel
about
that?
I?
Think?
That's!
A
Quite
that's
really
quite
an
interesting
again
Rubicon
to
cross
I'm,
a
big
fan
of
as
I
mentioned,
1960s
1950s
science
fiction,
philip
k,
dick
was
extraordinarily
morose
writer
at
that
time,
but
he
felt
that
this
was
a
huge
Rubicon
for
Humanity
to
cross
when
we
could
no
longer
tell
the
difference
between
what
is
human
and
what
is
merely
masquerading
as
human
and
Mitsouko
is
clearly
merely
masquerading
as
human.
She
is
just
an
algorithm,
but
it
feels
really
like
a
person
to
talk
to
and
I
think
that's
going
to
change
things
quite
a
lot.
A
I
actually
I
actually
think
Mitsuko
is
less
worrying
to
me
than
then
robots
making,
kill
decisions.
I
think
that
these
human
emulated
robots
are
almost
the
next
generation
of
fictional
characters,
and
we
will
see
an
awful
lot
of
use
cases
coming
out
of
their
existence
as
a
as
a
fictional
character.
Who
can
actually
talk
to
you,
talk
to
anybody
fully
scalable
fictional
character,
quite
interesting
in
many
ways.
I
think
that
humanity,
emulating
chatbots,
are
the
next
generation
of
novel.
But
that
will
be
interesting
to
see
how
that
works
out.
A
So,
let's
talk
about
automation
of
work
because
that
is
surely
considerably
less
controversial
than
air,
then
kill
decisions
or
whether
or
not
we
should
be
automating
human
interaction.
This
there's
nothing
I.
Will
we
all
love
automation
of
work?
There?
Surely
nothing
controversial
about
their
idea
of
automating
work.
We've
been
doing
it
for
250
years.
We
must
be
able
to
do
it
rights.
We
must
be
able
to
do
it
in
a
in
a
nice
clean
way
that
nobody
gets
hurt.
So
that
must
be
absolutely
fine.
A
So
let's
talk
about
kubernetes,
particularly
because
one
thing
I've
come
to
realize
is
that
kubernetes
is
an
absolutely
fantastic
automation
platform
and
it
can
do
much
much
more
than
you
probably
think
it
can
do.
There's
an
awful
lot
of
base
stuff
that
it
can
do,
which
is
just
automating
existing
jobs,
but
it
can
do
much
much
more
than
that
and
that's
what
I'm
going
to
talk
to
you
a
little
bit
about
today.
A
So,
let's,
let's,
let's
don't
live
in
so
the
kind
of
clever
things
that
kubernetes
can
do
and
why
it's
an
very
interesting
example
over
the
automation
of
work,
both
the
positives
and
the
negatives,
but
actually
it's
much
much
more
positive
than
most
ways.
We've
we've
automated
work
in
the
past,
in
my
opinion,
so
let
me
run
you
a
little
video.
A
A
So
we're
gonna
set
back
a
little
bit.
I'm
gonna
talk
to
you
about
the
first
project
that
we
did
to
look
at
what
you
can
do
with
automated
and
containerized
applications
running
on
top
orchestrators,
and
this
is
micro
scaling.
This
is
something
that
we
wrote
about
two
years
ago,
and
it
was
this.
This
particular
thing
was
recorded
on
my
on
my
machine.
What
we
did
with
micro
skelling
is.
A
So
you
can
bring
up
a
VM
in
in
a
couple
of
minutes,
which
is
fine,
but
it
means
that
if
one
of
your
machines
falls
over
and
you
have
to
wait
so
another
for
another
one's
come
up-
that's
genuine
downtime,
so
you
can't
respond
reactively
to
outages.
You
do
need
to
plan
ahead,
whereas
with
containerized
applications
containers
will
start
and
stop
in
seconds
or
sub
seconds
when
they're
orchestrated,
they
usually
takes
a
couple
of
seconds
to
start
one
up
again.
A
But
if
your
user
is
a
human,
then
a
couple
of
seconds
doesn't
really
count
as
an
outage.
You
can
change.
What's
going
on
on
your
in
your
data
center,
using
containers
in
effectively
real
time
without
necessarily
needing
to
predict,
what's
going
to
happen
in
the
future,
because
you
know
we
can
never
predict,
what's
gonna
happen
in
the
future.
So
normally,
if
prediction
is
required,
we
just
over
provision
we
just
plan
for
it.
A
We
plan
for
a
certain
degree
of
failure,
but
with
an
orchestrated
application,
then
you
don't
necessarily
need
to
plan
ahead
in
quite
the
same
way.
You
can
be
more
reactive,
no
looks
like
the
Internet's
has
gone
down
anyway.
What
you
would
be
seeing
there
and
what
you
did
see
was
a
a
graph
of
what
was
going
on
on
our
data
center
when
we
plugged
micros
scaling
into
it.
So
this
was
an
example
of
a
very,
very
simple
here
we
go-oh
going
back.
A
This
is
a
example
of
a
very,
very
simple,
simplified
data
center,
in
which
we
had
two
types
of
containerized
applications.
We
had
a
high
priority,
containerized
application,
which
is
the
dark
blue
on
there
and
a
low
priority.
Maybe
background
batch
job
in
lilac
above
and
we
simulated
demand
for
the
high
availability
process,
the
the
high
priority
process
below
what
we
did.
A
What
we
said
to
the
customer
scheduler
was
you
win
if
you
can
make
sure
there
are
enough
of
the
high
priority
services,
containerized
services
running
in
our
data
center,
to
meet
the
demand,
and
you
fill
up
the
rest
of
the
available
space
with
the
low
priority
batch
containers,
which
are
the
the
lylat
ones
there.
So
if
we
look
here
if
this
is,
if
this
is
running
again
appears
to
have
stopped,
but
fundamentally
that's,
there
would
be
a
win.
That's
not
a
win
there.
It's
winning
again
there,
it's
winning
again.
A
At
there
there
there
it's
winning
again,
there
is
catching
up
and
we
found
that
works
surprisingly.
Well,
if
you
only
sampled
every
couple
of
seconds,
you
could
keep
up,
you
could
change
the
mix
of
what
was
going
on
in
your
data
center
in
real
time,
using
a
custom
scheduler
running
on
top
of
kubernetes
to
handle
demand
to
meet
your
SLA
whilst
maximizing
your
resource
utilization,
and
this
is
exactly
actually
what
Google
do.
This
is
why
they
invented
containers
to
start
with,
because
they
get
extraordinarily
high
resource
utilization
out
of
their
data.
Centers.
A
Using
this
approach,
they
get
around
80
70
to
80
percent
resource
utilization
within
their
data
centers,
as
opposed
to
the
industry
standard,
which
is
what
most
of
us
are
achieving,
without
orchestration
and
without
containerization
of
about
10
to
15
percent,
and
they
needed
that
fool
to
not
just
be
spending
ridiculously
over
the
odds-on
hosting
their
systems,
and
they
had
the
large
enough
scale
that
it
was
that
the
money
they
saved
was
massively
massively
worthwhile.
So
this
is
the
kind
of
thing
that
you
can,
or
it
would
be
a
few
there.
A
A
That's
better
right,
so
I
can
show
you
a
little
bit
more
of
a
worked
example
with
a
real
life
application
that
we
built,
which
is
called
micro
batcher.
So
micro
budget
was
a
very,
very
basic,
simple
service
that
lect
you
and
it's
not
actually
available.
Now
anybody
can
go
right
now
and
have
a
look
at
micro
budget
calm,
and
you
enter
the
name
of
an
image
that
you
are
interested
in
on
docker
hub,
a
public
image
and
it
will
give
you
back
metadata
all
the
public
metadata
about
that
image.
So
what's
in
it,
what
layer's?
A
What's
going
on
very
standard
stuff,
so
absolutely
bog
standard,
nothing
very
exciting
in
there
you
must
all
have
simple
applications
that
are
a
little
bit
like
that
and
because
it
was
a
simple
application
and
we
were
building
it
from
scratch.
We
used
the
micro
services
approach
and
we
put
it
on
AWS
and
the
way
that
we
architected
it
was
absolutely
classic
micro
services.
A
So
what
we
realized
was
that
some
of
the
data
that
we
got
back
from
docker
hub,
we
got
back
very
quickly
and
some
data
we
got
back
quite
slowly
and
had
to
do
a
lot
of
processing
on.
So
it
made
sense
for
us
to
get
the
quick
data
back
to
the
users
very
quickly
and
process
the
slow
data
and
then
just
get
that
back
when
and
it
when
and
if
it
was
finally
ready.
A
So
we
created
two
different
services:
one
for
handling
a
quick
data
warn
for
handling
the
slowest
data
and
another
service
for
handling
the
API
requests
from
the
client,
and
we
communicated
between
all
those
services
using
AWS
is
SQS
so
queue
as
a
service.
Now
this
was
a
classic
simple
architecture.
A
For
a
start
up,
we
had
very
simple
services,
just
written
in
go
just
single-threaded,
which
meant
that
our
dev
team
could
all
work
simultaneously
on
the
service
and
deploy
without
knocking
anybody
else
over
without
having
to
worry
too
much
about
synchronizing
between
individuals,
and
we
could
we
used
kubernetes
deployments
to
to
get
our
continuous
delivery
working.
That
was
nice
and
easy.
We
also
didn't
have
to
worry
about
state,
because
all
of
the
state
in
this
system
is
held
within
our
sqs
queues.
So
we
have
three
nice
state.
A
A
There's
no
back
press
there's
no
way
to
apply
back
pressure,
there's
no
way
to
look
at
what's
going
on
and
change
what
we
were
doing
so
that
we
used
fewer
resources
or
we
changed
our
behavior
when
we
had
a
lot
of
load
on
the
system
within
an
monolith,
I
would
have
put
all
of
these
components
in
the
monolith.
Ana
would
have
had
a
scheduling
components
in
the
modeling
done
things
like
look
at
the
queue
lengths,
look
at
the
thread,
counts
and
maybe
made
decisions
about
which
kind
of
in
coding
I
was
using.
A
What
I
was
doing?
What
I
was
returning
to
the
user
so
that
I
managed
my
resources
as
I
went
along
the
downside
of
that,
and
we
all
know
with
the
downsides
of
the
monolith
that
would
have
taken
me.
A
lot
longer
to
run
I
would
have
had
to
write
my
own
queues.
It
would
have
been
much
more
difficult
to
scale
by
moving
to
a
microservices
architecture
like
this.
A
We've
lost
something
quite
significant,
which
is
that
scheduling
components
that
scheduling
view
that
way
of
easily
being
able
to
control
the
resources
that
we're
using
without
just
and
save
ourselves.
Money
are
the
only
way
of
scaling
with
this
architecture
is
just
spending
more
money,
which
is
great
if
you're
AWS
but
less
good,
if
you're,
actually
the
person
who's
paying
AWS
bells.
But
you
might
have
noticed
that
this
standard
architecture,
quite
by
chance,
happens
to
exactly
match
the
example
architecture
that
I
was
giving
you
for
micro
scale.
A
A
That's
a
custom
scheduler
that
we
wrote
for
our
own
amusements
to
our
live
production
system
like
that,
and
we
can
start
to
I
can't
actually
show
it
to
you,
because
what
it's
doing
is
so
unusual
that
none
of
the
viewers
of
a
micro
serviced
system
I
will
will
show
you
this
yet
because
it
changes
too
much.
But
fundamentally,
what
we
did
was
we
we
connected
in
our
micro
scale
in
custom
scheduler,
which
all
of
the
code
of
four
that
is
available
open
source.
A
So
if
you
wanted
to
do
something
similar
go
and
take
a
look,
go
crazy,
it's
all!
Apache
too,
you
can
look
at
it.
You
can
see
what
we
did.
We
used
a
bit
of
control
theory.
Take
our
ideas,
steal
away,
do
any
of
you
anything
any
new
thing
you
like
with
it.
We
connected
that
up
with
the
demand
metrics
being
the
sqs
queue
lengths
and
the
two
services,
the
inspector
service,
being
the
high
priority
service,
which
has
the
quick
data
back
and
the
size
service,
the
slow
data
being
the
low
priority
service.
A
So
we
connected
that
up,
put
it
alive
in
production
and
we
thought
what
the
hell.
This
is
not
the
most
robust
system
in
the
world
potentially
doesn't
need
to
be
so
we
can,
we
can
play
around
with
it.
We
can
see
if
this
whole
concept
actually
works.
It
was
very
much
a
proof-of-concept
and
it
did
hooking
up
that
custom
scheduler
to
our
real
world
system
actually
works,
and
it
did
cut
some
of
our
key
metrics,
like
RS
q
SQ
bill
by
70%,
because
we
were
just
using
our
resources
really
really
inefficiently.
A
If
we
use
the
very,
very
simple
custom
scheduler,
this
is
only
a
couple
of
hundred
lines
of
go
to
get
a
customer
scheduler
working
like
this
on
kubernetes
and
you
use
the
standard,
kubernetes
api
x'
to
start
and
stop
applications
70%.
It
really
wasn't
that
difficult
to
massively
increase
the
resource
utilization
of
our
systems
and
I
think
this
absolutely
exemplifies.
What's
so
very
good
about
kubernetes
and
what's
in
many
ways
so
very
frightening
about
it.
If
you,
if
you
take
companies
right
out
of
the
box
straight
out
of
the
box,
don't
do
anything
with
it.
A
So
you
don't
have
to
have
any
manual
involvement,
getting
rid
of
people,
but
the
interesting
thing
for
me
about
kubernetes.
Is
it
doesn't
just
automate
what
you
already
do.
It
gives
you
the
opportunity
to
write
a
lot
of
tools
that
do
something
that
you
could
not
have
done
before
that
micro
scale.
It
was
not
humanly
achievable.
It's
changing
our
systems.
Every
couple
of
seconds,
you're,
not
gonna!
A
You
a
script,
won't
do
that,
for
you,
a
person
certainly
can't
do
that
for
you
and
I
think
this
is
just
the
tip
of
the
iceberg
of
the
kind
of
things
you
can
do
when
you
start
writing
applications
on
top
of
the
layer
which
is
kubernetes.
We
really
are
only
at
the
start
of
that.
This
is
power
that
we
have
never
had
before,
but
in
some
ways
that's
what
to
me
makes
kubernetes
so
very
interesting.
It
will
destroy
a
lot
of
jobs.
All
automation,
platforms
do.
A
That
is
their
purpose,
but
it
can
also
create
an
awful
lot
of
jobs.
Now,
that's
generally
true
of
automation,
but
in
this
case
historically,
the
destruction
of
the
jobs
has
happened
in
one
area
and
the
creation
of
jobs
does
happen
in
quite
a
different
sector
of
society,
with
kubernetes
jobs
will
be
destroyed
and
jobs
will
be
created
that
can
actually
be
done
by
the
same
people.
These
skills
are
not
totally
separated,
so
you
might
need
for
operating
a
data
center.
You
will
you'll
need
scripting
skills,
you'll
need
manual
skills.
A
You
need
operate,
operate
the
standard
classic
operational
skills
for
writing.
Customer
schedulers.
You
will
need
programming
skills,
they
are
different
skills,
but
they're
not
wildly
and
completely
different.
They
can
be
learned
by
the
people
who
will
lose
their
jobs,
so
we
do
need
to
have
a
thing
about
what
kubernetes
ought
affects.
Kubernetes
is
gonna
have
on
the
shape
of
our
organizations.
I,
don't
know
if
anybody
was
in
Jaime
Dobson's
talk
yesterday
about
the
effect
of
kubernetes
and
automation
on
organizations,
but
he
said
there
will
be
blood,
and
that
is
true.
A
The
whole
purpose
of
this
is
to
automate
away
human
jobs,
but
it
doesn't
mean
that
there's
nothing.
We
can
do
about
it
that
there's
no
positive
side
to
this
I'm,
not
saying
that
kubernetes
is
evil.
Of
course,
I'm
not
saying
that
even
ETS
is
evil.
I'm
saying
that
kubernetes
is
good,
but
it's
also
somewhat
enigmatic.
A
It
has
a
vision
for
the
future
of
the
data
center
that
just
includes
far
fewer
people
and
I
wouldn't
want
to
bet
against
that.
That's
that
vision
that
kubernetes
has
I
think
it
will
be
achieved,
maybe
not
within
the
next
year,
but
maybe
within
the
next
10
years.
Our
data
centers
will
look
very,
very
different
and
they
will
have
a
completely
different
mix
of
skill
sets
required
to
manage
them,
and
we
need
to
start
helping
our
colleagues
now
to
transfer
across
to
that
new
skill
set.
A
So
it
talked
a
little
bit
about
automation
at
the
kind
of
three
areas
of
automation.
There
are
more
areas
of
automation
that
we're
doing
that.
We're
galloping
ahead
with
at
the
moment,
but
I
only
have
30
minutes
so,
but
focus
on
three
is
there
anything
that
we
don't
want
to
automate
is
really
the
the
the
thing
I
want
you
to
take
away.
From
from
this
talk,
we
talked
about
kill
decisions,
we've
talked
about
love,
we've
talked
about
work,
three
very,
very
key
parts
of
life.
A
There
are
other
areas
of
life,
fundamental
decisions:
will
you
get
a
mortgage?
Will
you
get
a
job?
Will
you
get
a
loan
that
are
also
being
automated
at
the
moment?
How
do
we
feel
about
that?
Do
we
think
that
that
is
a
good
thing,
or
do
we
think
do
we
think
that
automation
is
always
good
in
every
circumstance
or
not?
Is
there
anything
that
a
human
has
to
do?
I
I
don't
necessarily
think
that
it's
ultimately
it's
an
ultimately
required
part
of
human
destiny
to
operate
data
centers
or
to
drive
cars.
A
There
are
many
many
things
that
I
don't
think
there
is
a
problem
with
automating,
but
we
are
automating
everything
at
the
moment
and
we
might
want
to
consider
whether
some
of
them
are
really
our
key
to
the
future
of
human.
Soon
we
don't
necessarily
want
to
want
to
automate.
So
that's
what
I
want
you
to
take
away
and
think
about
busier
this
afternoon.
Firstly,
kubernetes
is
a
really
automation
platform.
You
can
do
really
cool
things
with
customer
schedulers
and
secondly,
what
should
we
do
with
automation?
But
it's
are
the
right
thing
to
do
with
automation.
A
Yes,
yes,
so
you
just
use
my
kubernetes
out-of-the-box
for
your
basic
or
basic
optimization,
so
out
of
the
box,
you've
got
bin
packing,
which
does
which
optimizes
the
placements
at
the
start
of
day.
So
when
an
application
comes
online
kubernetes
using
it's
bin,
packing
algorithms
will
make
sure
it's
placed
somewhere
that
it
is
most
efficient
for
it
to
be
and
most
resilient
for
it
to
be,
and
whatever
other
parameters
you
give
it
and
we
wouldn't
say,
don't
use
that
do
use
that
as
well.
A
The
custom
schedulers
are
designed
to
run
on
top
of
that
and
do
things
that
are
beyond
the
initial
placement.
So
for
that
diagram,
that
I
was
showing
you
about
you're,
constantly
changing
data
center.
That
would
have
to
be
done
with
a
custom
scheduler
because
it's
it's
controlling
what
goes
on
on
an
ongoing
basis,
not
just
an
initial
placement,
but
you
should
always
use
bin
packing
as
well,
because
that's
absolutely
axon
and
actually
the
bin
packing
will
decide.
So
our
custom
scheduler
is
stopping
applications
and
starting
applications,
but
it's
not
saying
where
they
should
go.
A
A
A
It
is
quite
scary,
I
I
think
that
we're
not
talking
about
it
or
thinking
about
it,
but
actually
we
should
be
yeah.
I
think
that
the
trouble
is
well.
It's
not
a
problem.
Automation
can
be
absolutely
fantastic,
so
we
tend
to
think
of
it
very
positively,
but
there
are
areas
where
we
might
not
want
to
automate
and
I
would
like
us
to
think
more
about
that.
B
A
Think
some
parts
of
it
are
unstoppable.
I
think
when
it
comes
to
automating
work,
that's
unstoppable.
We've
been
doing
it
for
250
years
and
we
will
continue
to
do
it
and
we
always
screw
it
up.
We
always
use
create
a
lot
of
losers
whenever
we
do
it,
we've
not
really
learned
how
to
do
it.
Better
I
think
that
is
unbelievably
unstoppable
and
we
have
to
be
very
aware
that
it's
about
to
happen
within
our
own
industry,
so
people
that
we
know
colleagues
and
friends.
A
A
If
we're
saying
we're
quite
happy
with
that,
they'll
just
go
ahead
and
do
it,
but
there
are
other
examples
of
where
the
military
have
rolled
back
from
things
that
are
really
quite
effective
as
far
as
they're
concerned,
because
everybody
said
we
just
don't
want
that
to
happen,
so
we
only
dropped
one
or
so
far.
We've
only
dropped.
One
or
two
nuclear
bombs
we
stopped
and
we've
stopped
using
chemical
weapons,
even
though
in
many
ways
they're
very
effective.
We
haven't
used
biological
weapons
and
I.
Think
part
of
that
is
because
we
as
humanity
have
said.
A
C
C
C
A
Yeah
yeah,
it's
really
easy
to
keep
it
quiet.
We
need
to
talk
about
these
things
because
we
know,
but
a
lot
of
people
don't
know
they
don't
even
know
this
is
on
the
table.
This
is
an
option.
It's
not
science
fiction,
yeah,
no
I,
better!
Stop
talking
so
the
next
fokin
can
come
in,
but
thank
you
very
much
everybody
and
thanks
for
questions.