►
From YouTube: Keynote Session Sponsored by CircleCI - Microservices: Just Another Tool in the Toolbox - Rob Zuber
Description
Keynote Session Sponsored by CircleCI - Microservices: Just Another Tool in the Toolbox - Rob Zuber, CircleCI
In the world of software development, we love to have strong opinions about architecture. Monoliths are great. Microservices will fix everything. “Micro” is too small, you need macroservices. It goes on and on. How can so many smart people have such wildly different answers? Can it mean anything except that there is no single right answer?
In this talk, CircleCI CTO Rob Zuber will discuss why context is everything, how to evaluate your options by returning to first principles, and why you should focus more on transition states than end states. Examples of CircleCI’s own architectural hits and misses will be reviewed with the lucidity of hindsight in order to discuss the decision-making tools and leadership approaches that could have improved the outcomes.
0:00 Intro
1:33 CircleCI's journey to Microservices
2:35 What problems do you need to solve?
3:47 Find the architecture for you today
5:50 Fitness Function
7:37 CircleCI's architectural values
11:07 Examples for reevaluating values
14:14 Summary: When to switch to Microservices?
A
B
B
I
also
joined
a
panel
of
all
the
speakers
at
the
end
of
the
day
and
throughout
the
day
I
noticed
two
themes
in
the
questions
that
were
asked
both
at
the
end
of
each
talk
and
in
the
panel
first.
When
should
we
switch
to
microservices
or
event
driven
architecture
or
whatever
else
was
on
people's
mind?
And
second,
how
do
I
convince
management,
the
types
of
people
asking
these
questions
work
for
me
they
may
work
for
you.
They
may
be
you.
B
I'm
rob
zuber
cto
of
circleci,
and
I
want
to
talk
to
you
today
about
microservices,
but
in
the
context
of
two
bigger
points.
First,
determining
the
patterns
and
approaches
that
are
most
appropriate
for
you,
your
team,
your
product
and
your
architecture
and
second,
how
to
align
your
organization
around
these
approaches.
So
no
one
feels
like
the
only
thing
standing
between
them
and
good
architecture
is
management.
B
At
circleci
we
started
on
the
journey
towards
microservices
in
an
effort
to
solve
a
very
specific
set
of
problems.
We
had
operational
scaling
issues
where
multiple
instances
of
the
same
monolith
were
conflicting
with
each
other
causing
challenges
as
we
tried
to
grow
our
customer
base.
So
we
decided
to
pull
out
a
small
set
of
services
to
deploy
only
a
few
of
certain
services,
while
still
having
hundreds
of
instances
of
others.
Then,
as
we
started
to
derive
value
from
these
services,
we
changed
our
perspective.
B
B
B
Or
it
could
be
a
risk
in
deployment,
so
similarly
you're
unable
to
make
effective
deployment
changes,
perhaps
because
you
have
unattended
side
effects,
perhaps
because
you
find
that
there's
too
many
things
changing
at
once,
because
you
have
all
of
your
pieces
together
in
one.
These
are
real
problems
and
if
you
took
an
80,
20
pareto
approach,
as
you
start
to
dig
into
those
problems,
you
might
find
that
your
biggest
problems
are
solved
after
you've
deployed
two
new
services.
B
So
you
still
have
your
monolith
and
you've
made
a
couple
small
changes,
and
at
this
point
your
problem
is
no
longer
the
one
that
you
started
out
with
and
you
might
move
on
to
something
else:
that's
more
important
to
solve
for
the
business
and
based
on
the
way
that
we
tend
to
talk
about
architecture
in
this
industry.
Many
people
might
say
but
wait.
That's
not
a
microservices
architecture
and
the
question
that
I
want
us
all
to
ask
is:
who
cares
it's
your
architecture
or
it's
my
architecture?
B
B
What
you
should
have
is
the
architecture
that
best
combines
the
patterns
and
approaches
that
are
needed
to
solve
the
evolving
challenges
of
your
business
and
what
made
sense
for
you
five
years
ago
might
not
make
sense
to
you
for
you
today
and
what
makes
sense
for
you
today
might
not
make
sense
for
you
in
five
years.
Do
you
have
to
be
making
complete
cutovers
at
each
one
of
these
points?
No,
it's
very
very
challenging
to
do
a
complete
cut
over
of
your
entire
code
base
or
architecture.
B
I
recently
read
building
evolutionary
architectures.
I
was
really
excited
about
this
book,
but
when
I
finished,
I
felt
a
little
bit
underwhelmed
like
a
significant
opportunity
to
advance
our
thinking
had
been
missed,
and
my
primary
reason
for
feeling
this
way
is
that
they
introduce
a
fundamental
concept
that,
in
my
mind,
felt
like
a
game.
Changer
and
then
I
think
they
failed
to
take
it
to
its
full
potential,
and
that
concept
is
the
fitness
function.
B
B
B
B
We
determine
this
through
architectural
values,
and
so
we
sat
down
as
a
team
and
identified
what
our
architectural
values
are.
And
specifically
we
came
up
with
these
functionally
decoupled
fault-tolerant,
operator-friendly,
maintainable
and
economic,
and
we
found
that
it
was
a
little
difficult
for
these
on
their
own
to
really
connect
with
people.
B
While
there
is
value
in
the
items
on
the
right,
we
value
the
items
on
the
left
more
now.
It's
important
to
note
these
probably
aren't
your
architectural
values
they
might
be,
but
more
likely,
you're
thinking
to
yourself,
my
engineering
team
does
great
work
by
focusing
on
things
that
are
interesting
or
we
don't
have
product
market
fit
quick
to
launch
is
the
only
thing
that
matters
to
us
and
that's:
okay,
great
news.
You
have
that
reaction,
because
you
actually
know
what
your
architectural
values
are.
B
You
feel
it
as
soon
as
you
think
about
it,
but
if
you
haven't
already,
you
should
take
a
minute
to
write
them
down,
because
the
really
important
question
is:
does
your
entire
organization
understand
those
values?
Do
you
all
have
agreement
and
are
you
aligned
on
those
architectural
values,
because
the
alternative
is
that
there
are
folks
in
your
organization
who
are
trying
to
implement
whatever
they
just
read
in
in
their
last
cool
blog
post?
B
So
first
take
a
moment
and
write
these
down
your
architectural
values,
not
our
architectural
values
and
then
have
a
conversation
with
your
team.
Make
sure
that
you're
all
in
alignment,
if
you're
an
engineering
leader
you
want
to
make
sure
that
you're
thinking
about
this
in
the
same
way
that
folks
on
your
team
are
and
if
you're
an
engineer
in
one
of
those
teams,
you
want
to
make
sure
that
you
have
a
clear
understanding
and
shared
understanding
with
the
team
that
you're
working
in
to
drive
that
alignment
and
at
circle
ci.
B
For
example,
we
realize
that
our
original
implementation
of
permissions
management
was
not
aligned
with
our
functioning
decoupled
value.
It
made
sense
when
we
built
it,
but
we
had
shifted
away
from
from
something
that
aligned
with
our
core
values
or
in
fact
our
values
had
shifted
based
on
the
scale
of
our
business
and
the
implementation
that
aligned
initially
no
longer
aligned
and
was
out
of
alignment
enough
that
we
wanted
to
stop
and
make
some
investments
in
truly
functionally
decoupling
that
model.
B
So,
for
example,
we
focus
on
the
value
of
operator
friendly
and
that's
more
important
to
us
than
many
other
sas
businesses,
because
we
also
offer
an
on-prem
version
of
our
product.
So
we
have
an
unbounded
number
of
operators.
Unlike
many
sas
companies
who
have
only
operators
working
within
their
own
within
their
own
organization,
and
so
we
need
to
be
cognizant
of
that,
but
we
made
a
decision,
for
example,
to
deploy
honeycomb
to
increase
observability
within
our
cloud
offering
within
our
sas
offering,
and
we
didn't
have
an
initial
model
to
make
that
work
for
server
deploys.
B
But
it
forced
us
to
have
the
conversation
up
front
about
where
that
gap
would
be
have
a
sense
of
the
design
that
we
were
going
to
implement
later
and
commit
to
the
full
scope
of
work.
Even
though
we
could
realize
the
value
sooner
in
our
cloud
environment
with
that
initial
approach.
So
truly
understanding,
not
just
what
aligns
with
our
values,
but
when
we
are
making
conscious
choices
to
drift
away
from
our
values
allows
us
to
have
very
conscious
upfront
conversations
and
drive
us
consistently
in
the
right
direction,
whether
you're
an
engineer
or
an
engineering
leader.
B
B
Not
only
prevents
those
tech
centered
conversations,
but
it
empowers
teams
to
make
great
decisions
that
are
in
line
with
those
values
without
having
to
escalate
and
have
complex
tech,
centered
conversations
and
speaking
of
those
conversations,
let's
all
be
clear
that
we,
the
engineering
leaders,
created
this
problem
for
every
single
one
of
those
questions
that
I
received
on
that
qcon
panel.
My
answer
was
some
form
of
what
problem
are
you
trying
to
solve?
When
should
I
switch
to
microservices?
B
What
problem
are
you
trying
to
solve?
When
should
we
switch
to
an
event-driven
architecture?
What
problem
are
you
trying
to
solve
and
trust
me?
I
was
not
popular,
but
I've
heard
things
like
well.
I
would
switch
to
microservices
when
your
organization
is
75
people,
but
there's
no
viable
justification
for
that
statement
without
a
significant
amount
of
additional
context
and
as
engineering
leaders
and
as
engineers,
the
more
we
let
ourselves
get
sucked
into
these
discussions
of
technology.