►
Description
Want to view more sessions and keep the conversations going? Join us for KubeCon + CloudNativeCon North America in Seattle, December 11 - 13, 2018 (http://bit.ly/KCCNCNA18) or in Shanghai, November 14-15 (http://bit.ly/kccncchina18).
Challenges to Writing Cloud Native Applications - Vallery Lancey, Checkfront (Intermediate Skill Level)
Cloud native means designing software explicitly for the cloud, not trying to deploy to the cloud in retrospect - shoving a single replica of a monolith into Kubernetes won’t cut it. Developing for cloud platforms has many requirements for tooling and behavior of the target cloud platform(s) - for example, maintaining Dockerfiles. There are also many challenges to designing a distributed system that can maintain high consistency, reliability, and availability. We’ll explain high level solutions and get into concrete code examples. Key topics are: - Bringing ops requirements into development - Designing for accurate testing - Caching and short term data - Long term storage - Service composition This talk will give developers a foundational understanding of cloud architecture patterns, data management, and requirements building, to empower attendees to hit the ground running.
About Vallery
Vallery Lancey is a DevOps Engineer (whatever that means) at Checkfront. She can be found at @vllry on Twitter.
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
Good
afternoon
everyone
we
finally
hit
two
o'clock,
so
let's
get
started
first
off
I
have
two
questions
of
the
room,
who
has
never
built
a
cloud
native
application
before
okay,
so
good
chunk
of
you
have
some
experience.
Secondly,
how
many
of
you
would
say
that
you
are
an
intermediate
developer
or
more
experienced
in
general?
A
A
Nobody
thinks
gonna
have
questions
okay,
so
I
worked
for
a
Czech
France
Czech
friend
is
an
online
booking
platform
for
small
businesses
to
enterprise.
We
deal
with
inventory
management
and
let
our
clients,
customers,
self
checkout
items.
I
do
a
lot
of
things
that
check
front
I
am
the
lead,
dev
ops
engineer,
which
means
that
I
do
a
lot
of
ops
and
a
lot
of
devs,
and
no
one
quite
knows
what
that
is.
So
I
used
to
be
the
sole
operator
these
days,
I'm
more
of
a
developer,
in
particular
I'm
in
charge
of
our
cloud
operations.
A
So
in
this
talk,
we're
going
to
look
at
three
main
aspects
of
how
to
do
cloud
stuff.
We're
going
to
look
at
what
a
cloud
native
app
is
we're
going
to
look
at
what
a
cloud
platform
is
and
what
the
implications
of
our
apps
are
and
then
we're
going
to
get
to
the
meat
of
the
talk,
which
is
how
do
we
actually
develop
for
a
cloud
platform
and
develop
for
that
behavior?
A
A
So,
firstly,
what
makes
software
cloud
native
it's
a
very
open
topic.
Cognitive
computing
foundation
is
arguably
the
authority
on
the
subject
and
they
have
a
particular
definition
that
software
has
to
be
containerized,
dynamically,
orchestrated
and
micro.
Service-Oriented
now
number
two
is
the
part
that
we
should
really
be
caring
about,
because
this
is
where
the
requirements
come
from.
If
we
have
dynamic
orchestration,
this
means
that
we
have
ephemeral
systems.
A
We
have
things
being
scheduled
up
and
down
as
need
be
so
because
of
that
it
naturally
it's
containerization
in
some
form,
be
that
actual
containers
be
the
application
images,
because
we
need
a
system
that
we
can
easily
ship
out
in
units
rather
than
trying
to
maintain
individual
VMs
and
processing
states.
It
also
means
that
service-oriented
architecture,
even
if
not
actual
micro
service,
has
become
very
valuable
because
different
systems
have
different
constraints
and
we
need
be
able
to
handle
those
separately
even
if
it's
just
a
monolithic,
app
and
its
database.
A
You
don't
have
to
touch
a
lot
to
actually
make
the
system
do
what
you
want
and
application
rollouts
are
simply
as
pushing
out
a
new
image,
rather
than
going
in
using
ansible
using
puppet
using
manual
operations
to
get
things
the
way
you
want.
That's
not
the
kind
of
thing
that
usually
should
happen
in
a
non
cloud
system.
Of
course,
this
is
your
bread
and
butter.
You
have
a
team
of
assisted
men's
going
and
changing
things.
A
A
First
thing
that
the
platform
does
is:
it
is
the
runtime
environment
somewhat
analogous
to
the
scripting
engine
of
a
scripting
language,
so
it
handles
the
actual
physical
platform
things
it
hell's
the
container
runtime.
If
you
have
a
docker
image,
you
can't
run
it
without
docker
or
without
some
kind
of
container
management
system.
So
that's
a
part
of
the
responsibility
it
handles
config
and
secret
injection
at
runtime,
and
it
handles
scaling
and
the
networking
so
we'll
get
back
to
this
later.
A
A
It's
another
thing
it
does
is
a
ephemeral
application.
This
is
why
we
really
like
cloud
platforms,
because
resources
are
just
spun
up
and
down
as
need.
Be
this
also
really
bites
us
and
it's
why
data
is
so
scary,
because
we're
used
to
data
having
a
very
constant
silo
that
never
changes
and
never
disappears
where,
as
things
changing
and
disappearing
is
the
absolute
backbone
of
any
kind
of
cloud
system.
You're,
specifically
engineering
against
that,
if
you
want
help,
isn't
data.
A
As
part
of
handling
the
network
cloud
platform
responsible
for
translating
an
actual
request
for
an
abstract
service
into
concretely
going
to
assist
sorry
specific
instance,
so
this
behavior
is
usually
fairly
abstract.
It
can
be
very
crude
or
specific.
There's
lots
of
ways
to
change
the
behavior,
such
as
things
like,
flannel
or
sto
that
are
specifically
modifying
how
that
works.
A
Usually
your
application
doesn't
have
to
deal
with
that
logic
itself,
but
sometimes
it
does,
for
example,
ingresses
they're,
usually
fairly
specific
and
limited.
If
you
want
to
have
very
specific
features,
such
as
one
instance
that
I
personally
had
trouble
with
is
custom,
runtime,
TLS
certificates
from
white
labeled
students,
white
labeled
websites
on
a
load
balancer,
that's
pretty
difficult,
because
load,
balancers
and
ingresses
are
specifically
built
in
certain
ways.
In
a
lot
of
platforms,
it
doesn't
make
them
amenable
to
easy
changes
or
modifications.
A
Okay,
so
now
we
know
a
little
bit
about
what
the
platform
is
it
kind
of
what
we're
working
with.
So
how
do
we
actually
develop
for
it?
So
in
this
talk,
because
it's
aimed
at
people
who
have
at
least
somewhat
our
amount
of
skill
with
developing
we're
going
to
try
to
focus
on
what
makes
this
different
from
developing
for
more
systems.
Essentially,
if
you
took
your
knowledge
from
ten
years
ago,
what
would
be
broken
or
bad
or
slow
in
a
cloud
environment,
so
there's
a
lot
of
things
that
we
can
focus
on.
A
First
up
with
persistent
data
storage,
I've
identified
four
fundamental
patterns
for
application.
We
can
have
only
one
replica.
We
can
charge
our
data
without
replication,
I
call
this
unreplicated
shards.
So
it's
just
when
you
have
multiple
distinct
databases.
None
of
them
are
replicated,
but
you
can
have
specific
things
on
a
specific
database.
You
can
have
multiple
replicas
with
volatile
data,
that
session
specific
or
you
can
have
multiple
replicas
with
runtime
application.
We'll
look
at
each
one
of
these
in
a
bit
more
detail
and
how
you
use
it
first,
one
is
just
don't
replicate.
A
You
usually
don't
want
this.
If
it
goes
down,
it's
lost
if
it's
getting
swapped
out
with
an
upgrade
it's
offline
for
a
couple
seconds.
You
might
want
this
for
services,
where
the
impact
is
fairly
low.
For
example,
we
have
a
fairly
small
company
and
the
people
who
handle
ops
are
one
decade
person
and
me
a
little
bit.
So
we
don't
cluster.
Our
Redis
setup,
which
we
use
for
a
couple
things
in
particular.
One
thing
we're
reticent
clustered,
is
for
our
translation
master
for
being
able
to
translate
our
internal
English
strings
into
your
customers.
Multi-Language
strings.
A
A
Next
pattern
is
unrefuted
shards.
This
is
a
pretty
common
strategy,
both
for
a
kind
of
manual
load
balancing
and
when
you
naturally
outgrow
the
ability
to
have
everything
in
one
database.
It's
when
you
pick
some
kind
of
unit,
typically
an
account,
and
you
specifically
put
on
a
certain
system.
Usually
it's
like
US
West,
one
u.s.
East
one
things
like
that.
So
it
lets
you
scale
up
your
system
as
a
whole,
but
the
interval
components
aren't
actually
scaling.
You
still
have
a
database
where,
if
it
goes
down
and
gets
overloaded,
it's
just
not
working.
A
Food
strategy
is
having
multiple
volatile
copies.
It's
really
easy
to
do
by
accident
and
I've
seen
a
lot
of
bugs
that
wind
up
being
something
is
stored
on
disk,
because
if
it's
persistent
but
there's
multiple
instances,
it's
a
good
pattern
for
caching,
but
I
would
highly
recommend
ever
planning
on
using
it.
Just
because
there's
always
going
to
be
circumstances
where
the
data
becomes
ephemeral.
When
you
don't
expect
it,
the
last
strategy
is
what
we
always
really
want.
We
want
to
be
able
just
have
a
bunch
of
databases,
everything
works
together.
A
We
hit
a
database,
we
read
and
write
to
it
and
we
don't
have
to
worry
about
having
only
one.
This
is
the
goal,
but
it's
really
hard,
especially
for
the
operations
side.
So
this
is
one
of
the
first
things
where
you
really
have
to
deal
with
the
operations
and
dev
planning
to
actually
make
sure
that
what
you
want
to
do
is
feasible
to
actually
run
so
some
databases
are
very
good
at
this.
Cassandra
is
one
of
worked
with
a
fair
batch,
so
Cassandra
is
naturally
multi
master.
A
A
Usually,
unfortunately,
databases
are
not,
as
you
all
know,
something
you
can
just
easily
swap
out.
So
you
need
to
kind
of
understand
what
your
runtime
loads
going
to
be.
What
your
needs
are
on.
Latency
and
replication
are
going
to
be
and
pick
a
database
based
on
that.
So,
if
you're
trying
to
run
something
like
Postgres-
and
you
just
have
too
much
writing
going
on,
you're
gonna
have
to
look
at
sharding
it
or
you're.
A
Gonna
have
to
look
at
changing
the
way
you
store
data
and
adopting
something
else
like
Cassandra
or
like
or
another
document
oriented
system
that
lets.
You
actually
replicate
the
scale
you
need
to
as
I
kind
of
outlined
a
bit
in
last
side.
Replicating
data
is
pretty
tough,
there's
just
a
lot
of
concerns
around
it
and
databases
that
are
more
friendly
toward
to
application.
Ten
Hannelore
this
internally,
whereas
ones
they're
less
friendly,
tend
to
outsource
a
lot
of
that
to
kind
of
custom,
scripting,
custom,
tooling
and
manual
operations.
A
You
have
to
deal
with
allocating
persistent
volumes
binding
to
those
connecting
to
either
seed
nodes
or
masters
and
dealing
with
electing
and
maintaining
those.
Ultimately,
especially
if
you're
a
small
team
third
party
tools
can
be
really
handy
for
this,
so
GCS
or
s3
for
images
is
a
really
good
example.
You
are
almost
always
okay
with
just
serving
images
from
a
CDN
in
most
use
cases,
and
suddenly
you
don't
have
to
worry
about
replicating
all
your
images
locally.
A
Our
next
topic
of
what's
difficult
is
service,
coupling,
so
there's
kind
of
two
parts
for
services,
but
first
we're
just
going
to
look
at
how
services
interact
together.
We
want
to
keep
things
they're
interacting
a
lot
together,
close
together,
so
in
kubernetes,
which
we're
probably
almost
familiar
with
deployments,
naturally
are
creating
unit
called
a
pod
which
contains
multiple
containers,
so
there's
nothing
too
complicated
there.
A
As
far
as
setting
that
up
what's
special
about
pods
is
you
create
containers
that
are
co-located
and
Co
scheduled,
so
this
one-to-one
state
between
your
containers
in
a
pod
and
they're,
always
on
the
same
machine.
So
this
is
especially
useful.
If
you
have
high
latency
concerns
for
your
connectivity,
we
want
a
couple
things
that
are
calling
one
another
law
either
one
it's
very,
very
critical,
that
a
call
goes
through
okay
or
when
overall
you're
making
a
lot
of
back-and-forth
calls.
A
So
if
you
have
a
particular
service
that
makes
many
many
calls
to
the
database
over
the
course
of
a
single
operation,
you're,
probably
going
to
want
to
be
able
to
put
those
things
in
a
pod
together,
so
that
you're
just
going
over
the
local
network
socket
as
opposed
to
hopping
to
the
next
rack
or
the
next
data
center.
It's
also
good,
if
you
have
any
kind
of
system
that
relies
on
particular
state
between
services,
rather
than
dealing
with
nasty
pinning
at
the
network
layer.
A
You
can
just
inherently
know
that
a
particular
instance
is
going
to
talk
to
another
particular
instance,
always
here's
a
quick
example
of
using
the
shared
state
to
our
advantage.
It's
a
pattern.
That's
often
used
when
there
is
frequent
content,
changes
or
content
changes
that
aren't
part
of
the
source
code.
You
can
simply
have
a
web
server
and
a
shared
disk
with
a
file
pulling
image.
That
is
taking
data
from
an
external
source,
pulling
it
on
to
the
local
disk.
This
way,
the
nginx
image
in
our
example
doesn't
have
to
ever
be
updated
with
new
content.
A
So
service
coupling
can
solve
a
lot
of
problems
around
date
and
see
at
least
primitive
ones,
but
we
can't
couple
everything
together.
We
have
a
lot
of
concerns
around
replication
of
some
services,
in
particular
ones,
with
persistent
data,
as
we
kind
of
talked
about,
there's
a
lot
of
issues
around
dealing
with
the
resources
that
spin
up
the
replication
loading
things
if
we
try
to
pin
a
stateless
service
along
with
the
database,
we're
gonna
want
to
find
that
the
stateless
service
is
hard
to
schedule.
A
A
So
suddenly,
you
might
wind
up
needing
12
units
of
CPU
to
schedule
your
pseudo
monolithic
application
when
really
you're,
trying
to
just
scale
up
the
reporting
system
and
because
you
can't
scale
selectively,
you
are
going
to
over
allocate
stuff,
as
well
as
having
trouble
just
finding
a
big
enough
resource
block
to
put
an
entire
replication
of
the
pod.
So
this
starts
getting
into
monolith
territory
as
far
as
your
runtime
concerns
related
to
services.
There's
also
internal
data
flow
I
call
the
internal
API
calls,
but
it's
a
much
more
open
subject.
A
It's
not
just
how
you
look
at
services
together,
it's
how
you
actually
transfer
data
between
those
services.
Cloud
platforms
tend
to
exaggerate
this
latency
by
means
of
either
physically
separating
things
further,
such
as
breaking
up
a
monolith
or
by
the
encouragement
to
go
for
a
more
micro
service,
oriented
design,
something
that
used
to
be
local
network
socket
or
even
just
a
function.
Call
away
is
now
a
little
bit
further.
That
latency
is
often
just
nanoseconds
to
milliseconds,
but
this
can
vastly
add
up,
depending
on
your
call
flow
and
your
architecture.
A
The
first
thing
you
can
do
is
use
threads
or
use
a
sec
check.
Front
works,
there's
a
lot
of
PHP
and,
as
those
of
you
have
unfortunately
dealt
with
PHP
know
this
isn't
very
possible,
but
you
can
get
out
of
a
lot
of
hot
water
just
by
paralyzing.
Every
single
request
that
you
are
able
to
that's
independent
so
that
you're
not
waiting
on
all
these
back-and-forth
calls.
That
said,
you
can't
always
do
that.
A
A
Ideally,
the
API
endpoints
can
be
designed
in
such
a
way
that
you
have
one
discrete
action
wrapped
up
in
one
endpoint,
rather
than
trying
to
step
through
multiple
pseudo
database
calls
you
can
create
batch
endpoints.
So
this
allows
you
to
escape
but
tiny
bit
of
networking
overhead
and
it
allows
you
to
leverage
any
shared
work
common
to
your
calls
so
doing
query,
planning
and
pre-processing
initializing
data
structures,
information
that
you
have
to
fetch
before
handling
requests.
If
you
can
make
this
common,
then
you
can
vastly
improve
your
overall
response
time.
A
This
is
really
useful
if
you're
trying
to
bulk
load-
something
like
say
if
you
have
a
social
media
application
and
you're
trying
to
load
a
whole
bunch
of
posts,
it's
really
nice
to
be
able
to
do
that
in
one
fetch
versus
in
a
single
request,
trying
to
load
50
different
things
and
making
50
different
calls
off.
I
have
a
quick
example
for
how
this
can
be
beneficial
is
C
cool
I'll
get
to
it
later.
Just
because
I
can
talk
about
some
testing
things.
At
the
same
time,.
A
A
A
You
also
need
to
be
able
to
run
them
whatsoever.
Unfortunately,
you
can
wind
up
in
a
situation
where
you
have
to
just
install
mini
cube,
to
get
anything
done.
Those
of
you
who
have
done
this
will
know
it's
not
very
friendly
for
developer
workflow.
You
can't
iterate
quickly
and
you
suddenly
have
to
know
a
lot
about
the
entire
application
and
the
operational
concerns
to
just
get
off
the
ground.
A
Ultimately,
what
you
want
to
be
able
to
do
is
create
discrete
components
of
the
application
that
can
be
run
individually
either
just
as
trees
of
services
that
call
one
another
or
with
fake
endpoints
that
aren't
necessary
for
your
purposes.
So,
if
you're
testing
chances
are,
you
can
only
run
a
service
or
two
and
just
mock-up
things
interact
with
you.
Don't
have
to
worry
about
everything,
that's
going
to
call,
but
to
do
this
we
need
to
organize
our
call
flow
in
such
a
way
that
we
don't
have
an
absurd
number
of
dependencies
for
a
given
action.
A
Here's
a
quick
example
that
will
probably
be
fairly
easy
to
understand.
As
far
as
unit
testing
goes
so
for
unit
testing.
We
want
to
be
able
to
simplify
our
actions
as
much
as
possible,
and
ultimately
here
we
have
some
business
logic,
which
is
just
statistics
about
median
that
we
want
to
build
a
test
in
detail
and
we
care
less
what
detailed
testing
of
the
overall
function
the
ocker
way
to
do
it
is
to
have
one
function.
A
A
It
specifically
split
the
logic
out
into
its
own
function,
and
that
way
we
can
call
that
function
without
worrying
about
the
database
at
all,
to
test
the
business
logic
and
then
do
a
simple
test
or
two
for
does
the
whole
database
process
work
in
terms
of
services.
We
have
a
diagram
here
that
kind
of
represents
the
same
architecture.
We
have
our
database,
an
interface
for
it,
reporting,
API
and
reporting
back-end.
The
reporting
back-end
represents
that
statistics
ought
median
call
in
the
actual
code
example.
This
is
something
that,
in
this
architecture,
it
doesn't
depend
on
anything.
A
It
doesn't
independent
database
integration
because
it's
having
data
dumped
into
it
in
individual
calls.
So
you
can
test
that
back
end
without
the
database
at
all,
and
you
can
also
split
off
different
portions
of
the
architecture.
If
need
be,
you
could
test
the
reporting
API
using
static,
payloads,
even
just
HTML
pages,
on
the
inventory,
fetch
API
and
the
reporting
back-end.
A
Local
development
has
a
lot
of
the
same
concerns
as
testing.
Does
we
need
to?
We
need
to
have
a
limited
number
of
things
we
need
to
run.
It
needs
to
be
easy
to
run
them
and
we
need
to
be
able
to
get
the
service
that
we're
focusing
on
up
quickly.
One
thing:
it's
very
nice
for
this,
especially
if
you
can
develop
small
enough
services
that
running
them
is
just
install
the
package
manager
run
the
application
is,
you
can
actually
not
use
docker.
This
has
been
talked
about.
A
A
number
talks
so
far
this
week,
developing
with
docker
or
container
runtime
is
not
very
friendly.
If
you
have
that
make
a
change
build
run
cycle,
that's
a
lot
more
awkward
than
the
change
of
line
hit.
The
button
in
the
IDE
flow,
so
one
design
that
we
do
a
check
front
is
especially
with
more
service-oriented
architecture
that
we're
exploring.
We
try
to
have
a
docker
compose
file
that
deals
with
all
the
necessary
dependencies
of
a
service
for
testing
or
development,
and
then
natively
run
the
actual
thing
that
we're
developing
on
this
way.
A
Ok,
I've
been
through
a
lot
of
content,
so
the
key
takeaway
is
should
be
that
many
things
wind
up
being
from
specific,
and
this
involves
ultimately
a
lot
of
knowledge
operations
around
the
platform.
So
you
should
be
actively
working
with
the
people
who
are
going
to
be
building
and
maintaining
your
cluster,
ideally
before
you
even
lock
into
specific
services
or
clusters
or
behaviors
as
to
what
you
need
and
how
you're
going
to
get
it.
A
What
you
really
don't
want
is
to
wind
up
with
kind
of
the
dev
ops
pipeline,
that
a
lot
of
companies
have
we're
selling
gets
built,
it
gets
thrown
at
the
opposite
team
and
it's
kind
of
well
just
run.
It
figure
it
out
because
that
doesn't
really
work.
You
wind
up
with
things
that
can't
scale
or
you
wind
up
with
things
just
aren't
going
to
be
performant
in
ways
that
could
have
been
predictable
and
negotiated
in
the
design,
phases
and
service
architecture,
winds
up
being
kind
of
the
be-all
and
end-all
of
this.
A
A
A
So
if
I
call
it
with
making
just
one
query,
it's
only
according
for
one
ID
I
get
point
zero,
one
four
milliseconds
and
if
I
query
again,
it's
bouncing
between
about
point
one
and
that
so
I
have
a
pre,
perhaps
line
that's
just
making
a
lot
of
queries
to
different
ideas.
It's
just
making
the
one
call
of
main
tie,
but
it's
throwing
in
I
think
forty
different
IDs
that
it's
looking
for,
but
because
this
is
only
one
query.
A
We're
still
seeing
it
in
the
same
time
range
it's
still
showing
up
between
0.01
and
point
zero,
one
five
milliseconds.
So
if
we
were
to
stack
that
up,
doc
could
become
very
substantial
very
quickly
if
we
were
to
make
all
those
calls
synchronously,
but
because
we're
making
one
query
we're
taking
advantage
of
the
fact
that
the
quarry
planner
is
already
running
and
we're
already
scanning
for
the
data.
It
was
a
tiny
bit
of
obviously
overhead
for
more
data
that
you're
selecting,
but
it's
almost
trivial
in
comparison,
just
making
the
call
that
many
times.
A
Okay,
so
I
have
a
few
pieces
of
suggested
reading
here.
Personally,
although
there's
no
substitute
for
experience,
I
find
it
very
helpful
to
have
tutorials
and
have
books
and
have
high-level
or
reviews
that
deliver
a
lot
of
the
concepts
to
you
so
that
you
actually
know
where
to
be
exploring
yourself.
In
particular,
I,
probably
recommend
designing
distributed
systems
which
I
read
only
a
couple
weeks
ago,
but
it
outlines
a
lot
of
kind
of
the
basic
patterns
in
cloud
systems,
kind
of
like
container
level
patterns
for
what
you
traditionally
have
as
object-oriented
patterns.
A
B
Thank
you
for
your
talk
and
at
this
conference,
I've
heard
of
some
people
who
are
starting
to
do
developments
also
on
systems
that
are
running
in
the
cloud
on
the
cloud
service
and
so
have
you
experimented
with
having,
instead
of
having
the
IDE
run
it
locally,
which
is,
which
is
what
we
do
as
well.
So
having
instead
run
the
code,
modify
the
code
on
the
containers
as
it's
running
and
then
testing
like
developing
on
that.
A
A
That
pattern
can
be
helpful,
but
it
depends
exactly
on
what
you're
working
with.
Sometimes
it
can
be
awkward,
especially
in
terms
of
package
management,
to
deal
with
that
kind
of
shared
state
and
I
found,
there's
a
bit
of
a
false
positive.
That
can
happen
where
you
have
the
correct
state
locally,
but
you're
trusting
so
much
that
the
built
container
works.
Fine,
that
you
then
have
something
that
works
on
your
machine.
You
deploy
it,
you
go,
I
was
using
the
container
image
and
then
it
fails
on
Jenkins,
okay,.
A
Nowadays,
not
much
I
officially
started
as
assistant
min,
but
I've
always
been
more
development.
Oriented,
so
I
would
say
that
maybe
good
quarter
to
a
third
of
my
time
used
to
be
spent
on
that.
But
these
days
we
buy
more
tools
or
use
more
mature
platforms
like
kubernetes
over
in-house
VM
Management.
C
I'm
totally
with
you
on
the
part
where
you
can
locally
develop
without
Cuban,
itis
or
mini
cube,
but
how
would
you
handle
service
discovery
in
that
case?
If
you
need
I
mean
if
you're
developing
on
maybe
two
services,
which
is
reality
in
a
micro
service
world
where,
in
a
perfect
world,
you
would
only
need
to
work
on
one,
but
they
do
need
to
talk
to
each
other
and
then
need
to
discover
each
other.
How
would
you
handle
that
the.
A
Practice
that
I've
found
best
for
that
is
specifically
spinning
up
a
composed
environment
or
some
kind
of
bash
launcher
for
your
containers
and
having
basically
config
level
routing,
maybe
with
defaults
for
production,
but
always
having
the
ability
to
inject
the
host
and
the
port
and
so
on,
for
whatever
you're
actually
trying
to
connect
to.
So
this
is
perfectly
fine.
If
you've
got
a
handful
of
services,
maybe
you
have
30
services
that
I
think
is
trying
to
connect
to.
This
would
be
ugly
to
manage.
A
The
point
of
trying
to
run
locally
just
is
that
it's
a
little
bit
nicer
for
the
thing
you're
actively
working
on,
but
for
the
other
dependent
services
you
may
as
well
just
throw
in
a
container
it's
easiest.
It's
not
that
I've
something
against
containers.
It's
simply
that
it's
a
little
bit
nastier
to
try
to
develop
in
one
all
the
thing
that
you're
actively
working
on
other
components.
It's
nice
and
quick
Thanks.
A
Okay,
I
guess:
I'll
wrap
it
up
there.
If
you
have
any
other
questions,
feel
free
to
approach
me
personally
or
send
me
a
message
later:
I'm
planning
on
trying
to
start
some
kind
of
series
around
development
concerns
for
modern
architecture
and
cloud
stuff,
not
sure
if
it's
gonna
be
office
hours
or
a
blog
or
whatever
really
depends
on
what
kind
of
interest
there
is.
Thank
you
all
for
joining.