►
Description
Lightning Talk: Did Micro-services Kill CICD? - Michael Pereira, Northwestern Mutual
Speakers: Michael Pereira
The rise in popularity of micro services has brought a lot of benefits to the software development world, but also created drawbacks that make it harder to deploy applications to production though a CICD pipeline. Can we find a good middle-ground that works for everyone?
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
A
A
What
we
can
definitely
say,
though,
is
that
microservices
had
a
strong
impact
on
cd,
but
before
we
dive
into
it,
a
quick
recap
on
the
situation
at
hand
for
those
that
may
be
lucky
enough
to
have
escaped
it.
They
may
not
know
that
monoliths
were
the
main
type
of
applications
before
there
were
no
clouds
containers
communities
so
creating
a
new
application
on
deploying
it
was
always
a
big
endeavor.
A
Instead,
it
was
much
easier
to
keep
bloating
this
sequence.
So
actually,
as
you
can
see,
it
was
a
single
big
application
on
everyone
supporting
it.
If
you
need
to
create
a
new
feature,
you
would
either
spend
a
lot
of
time
trying
to
react
things
around
to
edit
cleanly
or
just
quickly.
Add
it
to
the
pile
of
existing
sparky
codes
and
middle
of
it.
A
Different
teams
maintain
different
parts
of
the
meritek
application,
but
no
one
person
really
understands
the
entirety
of
the
application,
since
it's
so
complex
and
especially
because
the
boundaries
of
the
different
domains
are
aren't
really
clear.
You
can
see
that
everything
is
kind
of
mixed
together
anyway.
At
some
point,
features
are
deemed
ready
and
get
integrated
into
the
main
codebase
at
this
stage
is
now
the
job
of
dci
cd
pipeline,
the
one
that
makes
or
break
releases
to
build
a
product.
A
A
lot
of
time
is
spent,
maintaining
it
how
the
time
is
spent
figure
out
who
broke
the
build
or
the
test
since
so
many
changes
are
integrated
at
once,
it's
difficult
to
integrate
change,
so
it's
not
done
very
frequently
by
some
miracle.
Someone
manages
to
fix
the
build
on
the
complex
deployment
process
of
the
commander
begins
and
after
enough
time
spent
wondering
what
went
wrong
in
the
3000
line.
Strong
deploy
share
script,
it
ends
up
doing
the
job.
A
A
Each
of
those
services
that
is
on
csd
pipeline,
but
none
of
those
pipelines
are
really
providing
value
because
it's
simply
impossible
to
ship
each
piece
individually,
there's
just
too
much
risk
of
breaking
something.
So
we
need
another
encompassing
pipeline
to
ship.
The
whole
thing
driven
from
the
top
of
the
I'll
go
repo
and
it
was
always
a
pain
because
it
was
a
lot
of
time
spent
figuring
out
which
version
to
ship
one.
A
A
A
It's
quite
simple,
really
keep
related
code
in
the
same
first
story
well
code
that
makes
sense
to
go
together.
Otherwise,
you
can
go
crazy
and
can
easily
recreate
a
giant
monorepo
for
the
entire
company.
That's
probably
not
what
you
want
to
be
doing,
but
it's
a
problem
that
I
see
quite
frequently.
We
we
think
about
composability
and
decrypting
services,
and
we
forget
that
the
we
price,
the
repository
boundary,
is
not
easy
to
overcome.
A
So
keep
your
your
life
simple
and
instead
of
dividing
your
product
into
three
repositories,
just
creates
two
different
subfolders
in
a
single
repository
each
one
of
its
own
container.
As
you
can
see,
I
know
that
most
people
expect
to
find
docker
files
at
the
root
of
the
repository.
But
if
you
move
it
down
one
level
in
a
logical
way,
it
doesn't
really
break
much
and
it's
not
unexpected.
A
A
It
doesn't
necessarily
mean
that
your
ui
should
be
not
coded
and
that
you
can
call
the
backend
functions
directly
without
going
through
the
http
layer.
So
if
you
keep
that,
you
you're
sure
that
your
services
are
decomposed,
but
it
shouldn't
require
you
to
synchronize
several
csd
pipelines
together
to
be
able
to
release
a
single
change
into
production.
A
It's
not
always
easy
to
follow
for
sure
that
people
cannot
leverage
abstraction
tools
like
communities
to
run
the
application
and
they
have
to
provision
the
underlying
infrastructure
onto
which
their
application
runs
themselves.
We
have
to
store
this
entire
form.
I
have
seen
people
try
to
mix
complex
star
from
code
with
their,
not
so
simple
application
or
inside
of
a
single
pipeline.
A
I
think
that
the
results
can
speak
for
themselves.
In
this
case,
you
can
guess
from
the
number
of
stages
that
it
it
is
quite
the
pipeline
and
it
is
reflected
in
the
overall
pipeline
time
more
than
five
hours.
Sometimes
up
to
six.
You
can
see
why
that
pipeline
was
abandoned,
because
it
would
just
take
too
long
to
to
make
any
change
at
best.
You
can
make
a
change
in
the
morning.
A
A
A
Anyway,
remember
that
if
you're
choosing
to
use
microservices
you're,
creating
independently
deployable
services
around
business
domains
and
replacing
your
appendices
on
method,
signatures
or
libraries
with
remote
api
calls
over
http,
so
it
can
have
some
impact
on
the
network.
On
the
other
hand,
remember
that
you
can
recreate
monoliths,
that
that
makes
sense
and
stay
measurable
if
you
have
a
small,
a
small
team
and
clear
domain.
A
If
you
expect
your
your
service
interface
to
change,
if
you
don't
need
to
scale
each
of
those
domain
and
it
can
be
just
a
simpler
deployment,
topology
so
microservices
didn't
kill
csd
yet,
but
they
kind
of
make
it
made
it
worse.
In
some
cases,
so
don't
throw
the
monoliths
away
just
now,
you
can
start
cutting
it
into
micro
services,
but
you
can
keep
them
into
a
minor
repo
until
you
are
ready
until
you
really
need
to
decouple
things
even
further.