►
From YouTube: How We Migrated Our Monolith to K8s and Became a High Performin... Mauricio Salatino & Tracy Miranda
Description
Don’t miss out! Join us at our upcoming events: EnvoyCon Virtual on October 15 and KubeCon + CloudNativeCon North America 2020 Virtual from November 17-20. Learn more at https://kubecon.io. The conferences feature presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
How We Migrated Our Monolith to K8s and Became a High Performing Team - Mauricio Salatino, Camunda/LearnK8s & Tracy Miranda, CloudBees
Migrating your existing architecture from a monolith to microservices is a challenging task. Not only the technology landscape is different and overwhelming, but you also need a solid plan to bring the rest of the team along in the journey. This talk shares our real-life journey and the lessons learned from migrating a monoliths open-source project to microservices while adding in CI/CD best practices. We looked at specific best practices from the Accelerate book and show how those became reality within our team. The focus of this is: - Best practices for refactoring monoliths into microservices - Understanding how you can leverage tools such as Kubernetes, Helm, Jenkins X, and Zeebe to develop cloud-native applications - Pitfalls you should avoid and how you can learn from our mistakes
https://sched.co/Zen3
A
B
A
A
A
You
know
taking
a
monolith
and
applying
the
different
principles,
and
how
do
you
get
to
a
place
where
you
can
deal
effectively
with
all
the
challenges
that
come
up
because
there
there
are
many,
so
we'll
walk
you
through
those
a
real
world
kind
of
example,
and
and
show
you,
you
know
how
the
different
principles
might
apply
in
what
you're
doing
okay.
So
that's
what
we
have
lined
up.
So,
let's
kick
it
off
with
the
principles.
A
Okay,
so
when
we
talk
about
high-performing
teams,
we're
really
fortunate
in
the
industry
today
to
effectively
have
a
book
about
it,
so
the
accelerate
book
written
by
nicole
forsgren,
jazz,
humble
and
gene
kim,
like
I
think
for
many
of
us.
We
consider
this,
like
the
bible
for
high
performing
teams
and
how
to
build
and
scale
your
tech
organization.
A
Now
this
is
the
companion
book
that
dives
deeper
into
what
many
of
you
may
have
seen
is
the
state
of
devops
reports
that
have
come
out
annually
for
for
the
last
number
of
years,
and
these
as
a
set
have
a
huge
wealth
of
information
and
the
best
thing
about
them
is
it's
all
scientifically
backed.
So
this
is,
you
know
real
good
research
about
the
best
ways
to
to
do
things.
So
it's
you
know,
I
think,
when
we
talk
about
books
that
kind
of
transform
industries.
A
So
if
I
were
to
summarize
kind
of
some
of
the
the
key
things
so,
first
of
all,
high
performers
are
at
the
very
very
top
level.
They
talk
about
elite
performers
and
there
are
four
quantifiable
measures
that
are
used
to
determine
whether
your
team
fits
in.
You
know
that
elite
performer
bucket
and
one
of
the
key
things
about
the
research
showed
like
two
of
the
measures,
are
all
about
speed.
A
A
So
these
are
the
how
you
would
measure
your
performance,
but
this
talk
is
not
about
kind
of
the
the
outcomes.
I
think
there's
many
other
places
where
it's
covered
about
how
you
can
go
about
measuring
this
for
your
team.
But
what
we're
going
to
focus
on
today
is
going
to
be
more
the
process.
What
are
the
things
you
need
to
do
and
how
do
you
go
about
getting
to
a
good
state
with
these
metrics.
A
A
A
A
Typically,
monoliths
and
monoliths
in
themselves
are
not
bad,
but
they
are
specific
characteristics
of
a
monolith
which
can
make
some
of
these
principles
much
harder
to
to
do.
For
example,
you
know
being
able
to
have
the
loosely
coupled
architecture,
so
different
people
can
work
on
different
things.
A
A
B
Yes,
perfect,
so
when
you
start,
when
you
talk
about
jenkins,
no
matter,
if
it's
the
old
one
or
jenkins
x
you
it's
all
about
pipelines,
right,
like
continuous
integration,
pipelines
to
start
from
source
and
ended
up
with
something
that
is
being
built
right
when
you
work
in
kubernetes,
that's
a
little
bit
more
of
things
that
you
need
to
do
in
the
pipeline.
You
now
need
to
take
care
of
building
containers
and
also
packaging
kubernetes
manifests
in
into
home
charts
if
you
are
into
using
helm
in
jenkins
sex.
B
What
you
get
is
a
couple
of
pipelines
that
are
provided
by
default
for
different
type
of
projects
for
different
type
of
services,
using
different
frameworks,
different
languages,
and
that
allows
you
to
go
fast
because
you
need
to
spend
less
time
thinking
about
all
the
steps
in
the
pipeline
and
you
can
spend
more
time
just
writing
your
code
in
genting.
Sex
pipelines
go
a
little
bit
beyond
that,
because
it's
not
only
doing
ci,
but
it's
a
big
part
of
jenkins
x
is
doing
continuous
delivery
and
continuous
deployment.
B
So
after
you
render
your
pipelines,
what
you
do
is
you
use
continuous
delivery,
continuous
deployment
and
githubs
in
order
to
make
sure
that
whatever
you're
building
can
be
run
inside
the
kubernetes
cluster,
and
this
is
done
using
githubs.
So,
basically,
when
you
install
jenkin6
by
default,
you
create
two
environments,
the
staging
environment
and
the
production
environment,
and
when
you
run
a
pipeline,
you
use
front-based
development
in
order
to
create
a
release.
So
every
time
that
you
change
master
the
master
branch
in
your
repository,
you
are
just
going
to
generate
the
release
of
your
source
code.
B
B
You
can
easily
revert
back
to
the
previous
state
by
by
just
reverting
a
commit
in
that
repository,
but
I
can
keep
talking
about
jenkins
x
or
I
can
show
you
an
example
that
I've
been
working
on.
So
I
created
a
simple
example
just
to
represent
this
journey
from
going
from
a
monolith
into
a
cloud-native
application
in
running
on
top
of
kubernetes,
and
that's
basically
a
simple
example
of
a
conference
site
that
it's
been
composed
by
four
microservices.
B
The
front
end:
the
call
for
proposals,
the
agenda
and
the
email
service.
Let's
take
a
look
at
how
the
application
looks
like
I
will
be
posting
this
link
into
the
chat
just
so
you
can
just
play
around
with
the
application
if
you
want
to
while
this
session
is
live.
So,
let's
take
a
look
at
that,
so
first
of
all,
the
application
is
again
composed
by
four
services
that
are
running
at
the
same
time.
This
is
how
the
application
looks
like,
and
you
can
see
that
I'm
linking
to
the
versions
of
each
of
these
different
services.
B
I
also
have
a
back
office
for
the
committee
of
the
conference
to
accept
or
decline
proposals
that
we
are
receiving
and
as
part
of
the
normal
flow,
I
will
be
sending
emails
about
the
approval
of
the
or
the
rejections
of
the
of
the
proposals
right,
so
there's
another
service
that
basically
will
going
to
be
sending
those
emails,
and
you
can
see
that's
version
27
in
there.
So
now
I
have
different
servers
running
with
different
versions
and
they
are
all
interacting
and
they
are
working.
B
So,
let's
try
just
to
submit
a
simple
proposal
in
order
to
see
you
know
the
normal
flow
of
the
application
by
default.
The
application
is
basically
communicating
better
by
using
by
using
rest
calls.
So
we
will
talk
a
little
bit
about
that
later
in
the
challenges
section,
so
I
will
just
send
a
proposal.
B
B
I
will
accept
it
for
now
just
to
see
that
I'm,
you
know
sending
an
email
saying
that
I
was
approved
so
I
can
see
I
can
tell
the
logs
of
my
email
service
and
see
that
yes,
an
email
was
sent
approving
my
my
proposal
right
and
as
I
would
expect,
because
my
proposal
was
approved.
I
can
see
that
it's
posted
there
in
the
agenda
for
monday
11
a.m
for
the
conference,
so
that's
pretty
much
the
normal
and
the
happy
path
of
the
application.
So
that's
how
it
should
work.
B
Now,
let's
talk
a
little
bit
about
what
happens
when
you
need
to
make
a
change
right
again.
Now
you
don't
have
a
single
application.
You
have
four
different
services,
so
let's
say
that
I
want
to
make
a
change
into
the
front
end
right,
so
I
have
the
front
end
and
the
api
gateway
which
just
which
are
hosted
together
and
my
application
is
running
in
this
staging
environment
inside
jenkins
x.
So
what
I'm
clicking
in
this
link?
I
can
go
exactly
to
the
release
that
was
created
for
my
front-end
application.
B
B
I
don't
know
what
that
means,
but
I
will
just
try
to
do
it,
and
I
will
do
that
by
cloning,
this
repository
and
sending
a
pull
request
with
my
changes
right,
so
I
will
send
a
pull
request
with
my
changes
and
as
soon
as
I
push
the
pull
request,
checking
sex
by
default.
Provide
me
this
concept
of
a
preview
environment
where
my
pull
request.
Content
is
going
to
be
built
and
it's
going
to
be
automatically
published.
So
you
can
see
there
that
there
is
a
new
version
of
the
ui
that
I
can
already
test
right.
B
I
can
test
live
in
an
environment
and
I
can
link
to
the
existing
services
if
I
want-
or
I
can
just
instantiate
new
services,
if
I
want
to
do
that,
that
can
be
done
as
well.
So
now
I
will
send
a
test
proposal
to
see
if
my
website
is
a
little
bit
more
friendly
or
not,
and
we
will
see
if
my
manager
is
happy
or
not
based
on
the
results
right.
I
can
share
this
with
other
teams
as
well
for
them
to
validate
and
comment
on
my
pull
request.
B
So
if
I
go
there
to
the
pull
request
in
github
merge
the
request
now.
What
I
would
expect
is
that,
because
there
is
a
new
change
in
master,
the
pipelines
will
run,
they
will
generate
now
version
73
yep
we
have
72
before
now
we
have
version
73
and
after
the
pipelines
run,
I
would
expect
to
have
that
into
my
staging
environment,
and
we
will
take
that.
B
We
will
take
a
look
at
that
in
the
second
demo,
but
let's
go
back
a
little
bit
to
to
accelerate
right,
like
let's
think
about
more
about
the
technical
challenges
that
we
will
have
and
some
of
the
business
visibility
problems
that
may
arise
if
we
don't
tackle
them
soon
enough.
So
I
decided
to
highlight
two
technical
problems
or
challenges
that
I
faced
before,
because
I
think
that
they
are
time
consuming
and
I
don't
have
enough
time
to
cover
more
in
detail
problems.
B
So
let's
talk
about
those
so
for
the
first
one
is,
there
is
no
application.
As
I
showed
you
before.
I
have
like
four
services
running
in
an
environment.
They
are
running
inside
the
kubernetes
namespace
and
they
all
have
different
versions.
They
are
all
been
dealt
with
by
or
created
by
different
teams,
so
we
want
to
empower
teams
to
be
able
to
release
as
many
you
know,
changes
as
they
can
into
these
services
as
fast
as
possible,
right
and
with
jenkins
x.
B
We
achieve
that
by
having
them
in
separate
repositories
and
and
with
different
pipelines
that
are
continuously
deploying
into
the
staging
environment,
but
there
is
no
application,
no
concept
of
application
anymore.
We
just
have
a
bunch
of
services,
some
solution
that
we
found-
and
we
found
it
very,
very
useful-
is
to
use
helm
in
order
to
aggregate
these
versions.
So
we
can
have
a
parent
help
chart
that
basically
will
contain
these
specific
versions
for
the
services
and
by
using
that
we
can
quickly
take
one
version
of
this
application
and
deploy
that
in
different
clusters.
B
If
we
need
to-
and
we
will
have
like
all
the
sets
controlled
by
that
we
can
version
those-
we
can
tag
those
and
we
can
release
those
for
people
or
and
other
things
to
consume.
Following
on
this,
this
topic,
it
is
related
with
this
topic,
adding
application
infrastructure
right.
How
do
you
decide
if
you
want
to
use
kafka
or,
if
you
add,
to
a
data
like
a
database
for
your
services?
How
do
you
decide
if
you
want
to
run
it
inside
your
kubernetes
cluster
or
as
a
managed
service?
B
I
saw
a
lot
of
teams
spending
a
lot
of
time
by
switching
and
not
having
clear
guidelines
on
how
to
do
that,
and
for
me,
it's
really
really
important
that
you
streamline
that
decision.
So
the
more
clarity
that
you
have
around
this
or
when
do
you
maintain
things
inside
your
infrastructure
or
use?
Something
is
provided
by
a
cloud
provider,
for
example,
it's
an
extremely
important
thing
to
do
in
order
to
go
faster.
B
One
of
the
main
problems
that
I've
seen
people
dealing
with
is
understanding
process
state
right
like
how
do
you
understand
how
many
you
know,
proposals
are
pending,
how
many
proposals
have
finished
the
entire
flow
of
the
application
and
they
are
ready
to
go.
They
are
ready
to
present
in
your
conference
and
how
do
you
deal
with
you
know
think
when
things
goes
wrong
right,
that's
the
next
one.
B
So
how
do
you
avoid
inconsistent
states,
of
course,
that
we
want
to
avoid
inconsistent
states
and
you
can
there
are
like
tons
of
tools
to
do
that,
to
identify
when
something
is
going
wrong,
but
how
do
we
push
that
information
to
the
stakeholders
again
using
logs
using
tracing?
That's
all
good!
This
is
just
asking
a
question
of
okay.
How
do
you
expose
that
to
other
teams?
Let's
say
the
marketing
team
or
resources
team?
Whatever?
How
do
you
do
that?
Usually
in
general,
think
about
that
again
now
more
questions?
B
How
do
you
deal
with
changing
something
that
it's
big
right
like?
Do
you
want
to
introduce
a
change
that
will
impact
all
the
services
and
it
will
involve
multiple
teams
who
owns
that
change?
How
do
you
coordinate
that
change?
Those
are
super
important
questions
to
answers
and
the
more
procedures
that
you
have
around
it,
the
better
that
the
faster
that
you're
going
to
be
able
to
make
these
decisions.
B
So,
in
this
case,
what
I'm
trying
to
highlight
here
is
that,
instead
of
sending
an
email,
when
you
know
when,
when
the
the
proposal
was
accepted
or
rejected,
what
we
want
to
do
is
we
want
to
send
an
email
with
a
confirmation
link
for
the
speaker
that
was
accepted
to
confirm
before
publishing
the
proposal
to
the
agenda
right.
So
we
want
confirmation-
and
we
want
the
commitment
from
the
speaker
to
move
forward.
Think
about
how
would
you
implement
that
change?
B
Which
team
that
you
know
owns
these
services
is
going
to
be
in
charge
of
applying
that
dealing
with
edge
cases.
It's
also
super
important.
So
what
we've
seen
so
far?
It's
just
a
happy
path
of
the
application,
but
what
happens
when
things
go
wrong
right?
You
need
to
understand
and
make
sure
that
every
team
understand
how
to
deal
with
these
exceptional
cases.
Let's
say
that
we
recognize
that
the
speaker
is
not
answering
any
of
our
emails
or
or
not
meeting
any
deadlines.
How
do
you
deal
with
that
situation?
Right?
B
One
possibility
might
be
sending
a
notification
trying
to
get
in
contact
with
the
speaker
and
if
he
or
she
is
not
answering,
we
will
just
remove
them
from
the
agenda
right.
That
might
be
one
possibility.
But
again,
how
do
you
deal
with
this?
How
do
you
share
this
information
across
teams
and,
finally,
dealing
with
time?
Sensitive
actions
is
something
super
important
that
we
have
seen
many
many
many
times
in
almost
every
application
right.
Do
you
need
to
you
need
to
have
timers.
You
need
to
have
reminders.
B
This
is
super
super
common
requirement,
but
from
an
architectural
point
of
view,
and
for
teams
usually
to
decide
which
mechanism
to
use
it's
complicated
in
this
case,
what
I'm
trying
to
show
here
is
that
we
want
to
make
sure
that
we,
you
know,
review
proposals
in
the
first
three
days
after
we
receive
them
right,
and
in
this
case
we
need
to
send
notifications
if
that's
not
happening,
so
we
meet
some
kind
of
slas
for
our
customers,
in
this
case
the
potential
speakers.
How
do
you?
B
How
would
you
usually
implement
that
you
know
how
many
new
services
do
you
need?
What
kind
of
infrastructure
do
you
need?
Do
you
want
to
use?
How
do
you
integrate
your
services
with
an
existing?
You
know
component,
that
does
that
for
you
and
how
do
you
make
sure
that
you
garbage
collect
these
things
when
they
are
no
longer
needed
right?
B
So
let
me
talk
a
little
bit
about
cv,
which
is
a
workflow
engine,
basically
for
microservice
orchestrations,
and
it
provides
some
answers
to
these
questions
and
it
basically
push
harder
on
that
business
visibility
side
to
make
sure
that
other
stakeholders,
not
only
technical
people,
can
understand
how
your
applications
are
behaving
and
when
things
go
wrong,
you
can
also
see
that.
So,
let's
take
a
look
at
that
in
the
in
the
architect.
B
From
the
architecture
point
of
view,
it
looks
pretty
similar
to
you
know,
changing
communications
from
rest
to
use
some
kind
of
like
messaging
or
pops
up
mechanism,
where
your
services
now
will
need
to
connect
to
the
workflow
engine,
which
is
a
distributed
workflow
engine
that
it's
called
civi
and
it's
running
these
models
that
basically
represent
the
flow
of
action
right
like
what
are
the
steps
that
we
need
to
go
through
in
order
to
accept
or
reject
the
proposal.
In
this
case,
every
time
that
we
receive
a
new
proposal,
we
will
kick.
B
We
will
create
a
new
instance
of
this
model
that
will
be
executed
by
cv
and
cv.
While
it's
executing
is
sending
data
to
elasticsearch
this,
definitely
by
just
having
a
model
there.
We
are
clear
on
the
steps
that
we
are
executing
and
we
can,
you
know,
share
that
information
with
other
people
that
doesn't
need
to
be
a
technical
person.
So,
let's
take
a
look
at
how
cv
can
help
that?
First
of
all,
let's
take
a
look
at
the
application.
Now
we
are
in
version
73.
B
That
basically
means
that
our
business
cat
is
ready
to
say.
Thank
you
to
us.
If
we
submit
a
proposal
and
of
course
that's
that's
there
already,
and
I
have
two
versions
of
the
application
we're
working
with
rest
and
the
other
one
is
using
kamunda
cloud
which
is
running
this
workflow
engine
in
the
cloud
as
a
managed
service
as
before,
I
can
decide
to
install
it
in
my
own
kubernetes
cluster
or
I
can
create
it
as
a
managed
service.
B
In
camunda
cloud,
I
created
a
cv
cluster
and
now
I'm
communicating
my
services
with
that
cluster
in
kamuna
cloud,
you
have
tools
in
order
to
visualize.
What's
going
on
right
like
and
understand
exactly
what's
going
on
and
as
you
can
see
here,
there
is
a
model
that
is
representing
that
and
it's
also
highlighting
the
instances
that
are
pending.
B
If
you
remember,
I
created
one
to
test
the
business
cat
and
I
can
accept
or
reject
this
one
and
but
in
the
dashboard
we
can
see
how
many
instances
were
created
and
how
many
instances
have
finished
and
have
been
completed
in
each
of
these
paths.
How
many
were
rejected
now
one
and
how
many
were
completed
now?
Five
right,
if
I
reject
the
the
one
that
I've
submitted
for
the
business
cap,
there
will
be
two
rejected
right
and
that's
basically
what
I'm
trying
to
demonstrate
in
here.
B
So
understanding
process,
state
understanding
where
things
are
it's
extremely
important
and
using
this
kind
of
tools
will
help
you
to
understand
almost
in
real
time.
What's
going
on
with
your
applications,
and
if
you
have
more
doubts,
you
can
of
course
drill
down
in
each
of
these
instances
understand
which
path
was
taken.
How
much
time
did
it
take
to
complete?
B
B
This
is
a
simple
example,
but
let's
talk
a
little
bit
about
avoiding
inconsistent
states
when
things
go
wrong
right,
let's
say
that
one
service
is
down
and,
of
course
we
will
do
our
best
to
make
sure
that
services
don't
go
down.
But
in
this
case
we
will
simulate
that
the
agenda
service,
the
one
that
is
hosting
all
the
accepted
presentations,
is
down
right.
How
do
we?
How
can
we
push
something
into
it
if
it's
down
or
if
it's
not
responsive?
B
Well,
we
can't
and
again
I'm
not
saying
that
you
need
to
replace
tracing
or
logging
or
monitoring.
I'm
just
saying
that
by
adding
tools
like
this
on
top
of
those
tools
will
help
you
to
propagate
that
information
to
the
business
side
as
well,
so
to
people
to
other
teams
that
might
be
interested
in
understanding
what's
going
wrong
or
if
we
have
a
problem
with
the
speaker
and
and
how
how
they
can
deal
with
that
as
well.
B
B
I
will
create
a
new
proposal
with
this
wrong
payload
and
I
will
need
to
make
a
decision,
so
I
can
push
it
to
the
agenda
and
then
the
application
will
fail.
So
let's
go
ahead
and
create
that
proposal
with
with
the
fail
payload.
In
this
case
the
title
is
fail,
so
it
will
fail.
I'm
just
simulating
that
to
show
what
the
tool
can
give
you
and
what?
How
can
you
use
the
tool
in
order
to
share
that
information
with
other
teams?
You
can
see
the
business
caddy
there
is
there.
B
So
that's
true,
that's
the
new
version
up
and
running
already.
So
let's
go
back
to
the
to
the
back
end
to
the
back
office.
So
we
can
accept
that
and
at
this
point,
if
I
accept
that
we
I
will
try
to
push
it
again
to
the
agenda
and
that's
where
it's
going
to
fail.
So
if
we
go
to
the
dashboard
again,
we
will
see
that
now.
B
B
So
I
can
see
that
there
is
an
incident
here.
I
can
quickly
have
like
this
summary
in
the
in
the
main
screen
with
the
dashboards,
where
I
can
see
the
error,
so
I
can
get
the
technical
error
and
share
with
my
technical
team
if
I
want
to,
they
probably
have
this
already,
but
there
is
a
way
to
correlate
between
the
logs
and
the
tracing
and
the
incidents
in
here,
and
I
also
can
see
you
know
who
was
involved
in
this
incident
right.
B
So
I
can
see
the
email
there
inside
the
payload
of
the
the
you
know
the
potential
speaker
that
was
affected
by
this
incident,
which
basically
means
that
I
can
you
know
like
marketing
or
hr
or
someone
can
get
in
touch
with
the
speaker
to
say
there
is
a
problem
with
your
proposal.
We
are
trying
to
fix
it.
Bear
with
us,
if
you
don't
see
it
in
the
agenda
right
so
again,
the
whole
idea
of
enabling
other
teams
empowering
other
teams
with
the
right
data,
so
they
can
do
the
work.
B
Of
course
you
can,
there
is
not
much
that
you
can
do
if
the
service
was
down,
you
can
keep
retrying
from
this
user
interface,
but
in
normal
cases
at
least
you
will
have
an
indication
of
what's
going
on
and
if
there
is
an
incident
and
if
the
incident
is
still
there
or
not,
as
you
can
see
that
the
incident
was
fixed,
so
now
we
can
move
forward.
This
was
completed.
This
was
published
to
the
you
know.
This
was
published
to
the
the
agenda,
so
next
step
is
to
update
flows
right.
B
So
let's
talk
a
little
bit
about
what
happens
when
you
need
to
update
the
flow
like
again,
this
will
involve
multiple
services
and
it
will
change
the
behavior
of
the
application
workflow
engines
in
general.
They
are
built
with
the
concept
of
dealing
with
multiple
versions
right,
because
we
want
to
enable
people
to
experiment
and
to
change
things,
because
we
know
that
reality,
changes
and
systems
and
software
get
more
and
more
complex
and
software
will
evolve.
So
we
provide
these
tools
where
you
can
just
change
this
model
and
change
the
order
of
action
right.
B
So
in
this
case
we
were
publishing
first
to
the
agenda
and
then
sending
an
email.
We
will
change
that
now
to
help
the
situation
where
we
want
to
ask
a
confirmation
from
our
speakers.
So
basically
that's
what
I'm
doing.
I
am
you
know,
sending
an
email,
maybe
with
a
link
for
the
speaker
to
confirm
and
commit
to
present,
and
the
next
step
is
to
wait
for
that
speaker.
Confirmation
right
when
the
speaker
clicks
yeah.
B
B
And
finally,
this
the
last
thing
that
we
need
to
do
of
course,
as
you
might
expect,
is
to
define
what
kind
of
message
are
we
waiting
for
right
in
this
case
it's
speaker
confirmation
and
we
will
need
to
have
some
kind
of
correlation
to
say,
yeah.
This
message
of
the
speaker.
Confirmation
is
related
to
this
proposal
id
that's
why
I'm
using
proposal
id
there
in
order
to
move
the
right
flow
forward
when
when
we
receive
that
notification?
B
So
if
I
save
this
now,
we
have
now
two
different
versions
of
the
flow
right
and
again,
this
will
help
us
to
explain
to
the
business
side
of
yesterday.
The
application
was
working
in
this
way
right
and
the
application
is
currently
using
version,
one
of
the
flow,
but
you
know
tomorrow
we
can
decide
to
say
okay,
we
can
try
version
two
with
this
new
flow
with
the
speaker
confirmation
and
we
can
enable
our
teams
to
experiment
on
doing
av
testing,
for
example,
running
different
versions
and
see
which
version
works
better
right.
B
If
you
have
any
problem,
we
can
always
roll
back
to
the
previous
version,
and
you
know
you
can
basically
add
more
versions.
The
more
changes
that
you
want
to
add.
This
is
promoting
also
like
this
idea
of
keep
evolving,
keep
improving
all
the
time
right
and
build
this
kind
of
knowledge
base
of
cases,
and
that
brings
me
to
the
next
topic,
which
is
dealing
with
edge
cases
right
in
the
same
way
that
we
are
dealing
with
the
normal
happy
path.
For
our
you
know,
proposals
we
want
to
make
sure
that
we
document.
B
First
of
all,
you
know
how
to
deal
with
things
that
are
not
as
happy
as
the
happy
path
right.
So
in
this
case,
what
I'm
representing
is
the
use
case
that
I
mentioned
before,
like
a
speaker
completely
disappears,
and
we
need
to
recognize
when
that
happens.
So
then
we
can
trigger
the
following
steps
in
this
case:
sending
an
email
waiting
for
some
kind
of
confirmation
from
the
speaker
and
if
the
speaker
after
three
days
doesn't
respond
to
that,
you
know
request.
B
We
will
probably
remove
that
his
press,
his
or
her
presentation
from
the
agenda.
If
we
get
a
confirmation,
we
might
book
up,
you
know
meeting
to
just
make
sure
that
they
are
going
to
present
or
not.
So.
By
doing
this,
we
not
only
document
how
to
deal
with
this
edge
case,
but
we
also
have
a
list
of
edge
cases
that
we
are
dealing
with
and
finally
dealing
with
time.
As
I
mentioned
before,
it's
quite
a
common
requirement
that
workflow
engines.
They
already
provide
tools
for
that
right.
B
So
let's
say
that
we
want
to
make
sure
that
we
review
a
proposal
in
the
first
three
days
after
we
receive
it.
That's
quite
a
common
thing
to
do
right.
So
if
you
see
here
in
the
model,
we
can
even
make
it
explicit
right
like
we
can
add
that
time.
You
know
temporal
dimension
into
the
model
and
we
can
add,
you
know
time-based
actions.
So,
in
order
to
do
that,
what
we
can
do
here
is
we
can
use,
drag
a
timer
node.
B
That's
what
I'm
doing
now,
so
I'm
going
to
drag
a
timer
node
into
into
the
the
model,
and
I
will
basically
ask
for
the
engine
to
trigger
a
notification
when
that
timer
is
due
right.
I
can
set
the
duration
for
that
timer,
let's
say
three
days
so
if,
after
three
days,
the
decision
was
not
made,
this
timer
will
be
triggered
and
by
triggering
that
timer
I
can
decide
to
cancel
the
flow
or
just
to
keep
it
running,
and
in
this
case,
because
just
it's
just
a
notification,
I
will
just
keep
it
running.
B
B
A
Hey
yeah,
thanks
for
that
mauricio
and
yeah,
just
going
in
as
we
conclude
and
yeah
we'll
be
happy
to
take
any
questions
I'll.
Take
you
back
to
the
capabilities
of
accelerate
so
check
these
out.
If
you've
read
the
book,
read
it
again
and
I
just
want
to
finish
on
one
additional
one,
which
is
not
too
related
and
that's
number
24
in
the
list,
which
is
transformational
leadership,
because,
regardless
what
you've
seen
here
at
the
end
of
the
day,
it's
about
bringing
bringing
about
change
to
your
team.
A
So
I
think
by
the
fact
that
you're
attending
this
talk,
you
already
see
the
vision
set
out
between
accelerate
and
cloud
native,
tooling
and
transformational
leadership
is
all
about.
You
know,
I
don't
you
don't
have
to
be
the
manager
or
the
top
person,
but
you
just
need
to
have
these
qualities
where
you
can
go
inspire
others
bring
them
together
to
make
the
change
and
then
just
be
supportive
in
the
sense
of
empathy
and
personal
recognition.