►
From YouTube: How to Scale Cloud Adoption whilst Building a World Class Developer... - H Marzook & R Sanghavi
Description
How to Scale Cloud Adoption whilst Building a World Class Developer Experience - Hibri Marzook & Ruchir Sanghavi, Contino
Speakers: Ruchir Sanghavi, Hibri Marzook
In 2021 the majority of organizations have built a cloud foundation of some sort (eg. Landing Zones, Scaffold) in order to securely consume Cloud at scale. However, the majority of said organizations find themselves crippled with the following challenges:
- Developers still find these environments unusable
- Cloud foundations do not evolve in line with the requirements of the development teams
- Old fashioned Centre of Excellence's have turned into the ivory towers of the cloud world.
In this talk, Hibri Marzook & Ruchir Sanghavi will explore how to build upon one's cloud foundations to put in a developer-centric engineering-based methodologies focusing on:
- World-class developer experience
- Building modern team topologies that don't hinder progress
- Engineering practices that are key to ensure long term cloud adoption
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
A
A
B
Hey
everyone
rasheer
here
account
principal
at
continent,
and
so
I
love
building
great
teams
to
enable
engineering
culture.
I
have
a
real
passion
for
developer
experience
and
particularly
how
that
can
help
accelerate
public
cloud
adoption
and
that
helps
best
teams,
adapt
advocate
for
best
engineering
practices
and
enabling
transformation
with
the
devops,
agile
and
a
lean
approach.
B
B
And
really
what
that
means
is
you
know
the
the
notion
of
you
know:
look
mile,
no
hands
right,
it's
enabling
your
developers
within
your
organization
to
be
able
to
to
you
know
cycle
on
their
own,
and
that
could
relate
to
a
whole
bunch
of
underlying
capabilities
that
you
can
enable
as
part
of
your
enterprise.
You
know
so
as
a
developer.
I
want
to
be
asking
questions
like.
Can
I
independently
build
version,
deploy
and
release
my
code?
Is
there
a
definition
of
done
that
the
entire
team
is
is
creating?
B
Do
I
have
dedicated
scrum
master
in
my
feature
team
to
inspect
the
top
and
attach
to
agile
values?
You
know:
is
there
a
visibility
in
terms
of
dora
metrics
that
allows
us
to
capture
throughput
and
stability,
and
these
are
all
you
know
these
capabilities,
the
underlying
capabilities
that
should
be
at
disposal
for
a
developer,
to
really
learn
and
understand
and
enable
their
journey
throughout
the
stlc
in
place.
B
So
you
know
who
are
the
devs
in
the
developer
experience
you
might
ask
really
it's
the
question
back?
Is
you
know
as
a
developer?
Are
you
are
you
the
person
who's
building
the
platform?
Are
you
a
person?
You
know
who's
building
on
top
of
that
platform
by
different
layers,
you
might
be
operating
that
platform
and
just
interacting
with
it
or
you
might
be,
you
know,
building
and
running
and
owning
things
on
on
the
platform
and
all
of
those
people.
B
And
really
you
know,
why
is
this
important
because
in
reality
many
organizations
have
what's
called
the
wall
of
confusion
and-
and
it
often
leads
to
a
very
high
friction
environment?
And
you
know
there
could
be
sure
feedback
loops
that
get
cut
across
because
we
don't
know
who
the
responsibility
lies
in
and
there
might
also
be
the
debuff.
The
debugging
loop
might
be
broken,
so
you
might
be
able
to
debug
it
and
deploy
in
your
local
environments.
But
as
soon
as
you
actually
get
into
tests,
you
can't
do
certain
things.
B
B
This
could
have
even
a
more
dreading
effect
on
the
entire
organization,
because
you
might
end
up
with
dysfunction
and
demotivated
teams.
You
might
get
developers
who
are
burnt
out
as
an
organization.
You
might
struggle
to
retain
the
the
best
developers
that
you
have,
because
another
competitor
is
offering.
All
of
these
capabilities
could
lead
to
toxic
culture,
low
levels
of
productivity,
backlog,
sort
of
just
increasing
in
terms
of
size.
Your
technical
debt
could
be
going
on
going
up
and
delivery
of
features
keep
pushing
out.
You
know
the
next
all
we'll
do
in
the
next
release.
B
A
A
A
platform
has
layers,
and
this
quite
understanding
these
layers
is
early
on
is
quite
important.
So
the
bottom
most
layer,
a
platform
layer
exists
to
enable
all
the
productions
building
on
it,
and
the
product
teams
enable
users
and
users
in
turn
enable
the
organization
to
achieve
its
goal.
So
the
bottom
layers
always
enable
the
layer,
above
it.
A
A
Most
of
all,
the
platform
team
exists
to
enable
product
teams
to
deliver
fast,
and
this
is
a
boundary
that
you
have
to
be
aware
of
the
product
focused
team,
build
and
own
and
run
their
products.
They
own
the
product,
governance.
They
don't
own.
The
governance
around
any
of
the
shared
components
they
own
the
product
risk,
the
platform
team
and
the
platform
don't
own
any
of
the
risk
associated
with
the
product.
A
A
A
A
What
should
they
care
about
so
taking
those
layers
boundaries
in
the
shared
responsive
model?
This
is
an
example
using
the
azure
cloud
adoption
framework
architecture
to
show
you
what's
the
size
of
the
playing
field
for
the
dev
teams
and
the
and
the
platform
teams.
So
if
you
look
at
the
blue
blue
parts,
that's
the
platform
team
responsibility,
so
quite
a
lot
of
things
that
the
platform
team
needs
to
be
responsible
for
and
if
you
look
at
the
green
bits,
that's
the
productive
responsibility.
A
So
you
can
see
that
this,
this
good
developer
experience
is
in
a
tightly
controlled
space.
It's
not
a
wild,
it's
not
a
wild
west.
It's
not
developers
running
running
and
across
all
over
the
landscape
and
changing
things
and
understanding
these
boundaries.
The
constraints
space
that
developers
playing
helps
you
to
constrain
the
developer
experience
and
make
that
constrained.
Dev
experience
awesome.
A
So,
to
help
get
started
with
the
developer.
Experience
enable
continuous
delivery
by
default.
This
is
a
core
engineering
practice
that
helps
scale
to
scale
cloud
adoption
and
give
a
good
development
experience
so
to
get
to
continuous
delivery.
One
of
the
tricks
I
like
to
use
is
to
build
a
working
skeleton,
and
this
is
the
first
thing
I
build
and
deploy
it's
a
simple
system.
A
It's
a
tiny
implementation
of
the
system
that
performs
a
small
end-to-end
function
doesn't
need
to
use
the
final
architecture,
but
it
should
link
together
the
main
architectural
components
so
that
the
architecture
can
start
to
evolve.
So
what
I
do
is
I
take
the
system
and
try
to
deploy
it
all
the
way
to
production
environment.
A
The
organization
has
and
don't
bother,
building
any
other
functionality.
Until
this
is
improv,
it's
got
no
usable
functionality,
so
it
should
have
very
little.
Risk
should
be
easy
right,
so
deploying
this
walking
skeleton
helps
you
to
explore
all
the
roadblocks
that
your
organization
has
on
the
path
to
production.
A
So
if
it's
really
hard
and
there's
a
lot
of
friction
in
deploying
a
very
simple,
simple
system,
it's
going
to
be
very
hard
there'll,
be
more
friction,
deploying
anything
anything
more
complex,
so
deploying
the
working
skeleton
helps
you
validate
the
develop
experience
and
test
what
it's
actually
like,
and
we
do
that
because
only
prod
matters
you
only
get
accurate
feedback
when
actual
users
use
the
software.
You
built
everything
before
that
has
questionable
value.
Can
you
test
in
production?
A
If
you
do,
if
you
can
do
so,
leverage
canary
deploys
feature,
switching
rolling
releases,
monitoring
and
synthetic
transactions
to
help
achieve
this.
Most
importantly,
learn
to
differentiate
between
deployment
and
release
deployment.
The
simulation
installation
of
a
new
version
and
a
release
is
getting
the
new
version
of
your
users.
A
So
the
only
environment
that
should
be
permanent
is
prod.
Everything
else
should
be,
should
be
temporary.
So
to
get
this
right,
pay
attention
to
the
time
spent
on
boarding
time
spent
waiting
between
transitions
to
environments
cycle
times
a
number
of
times.
A
team
has
interact
with
another
team,
so
a
good
level
experience
it's
just
not
about
what
happens
on
the
developer,
desktop
it's
the
whole
journey
of
a
developer,
getting
what
they've
built
out
to
a
production
environment
and
into
the
hands
of
users.
A
And
then
pay
attention
to
feedback,
loops
feedback
loops
are
things
we
should
focus
on
when
if
we
are
doing
congest
delivery
and
using
pipelines,
our
pipelines
are
full
of
signals.
We
live
in
feedback
loops,
whether
we
like
it
or
not.
We
can
choose
to
act
on
them
or
ignore
them
at
our
apparel
and
by
not
listening
to
these
feedback
loops
by
not
listening
to
the
difficulties
we
have
with
our
pipeline
the
wait
times
the
slowness
things
breaking
the
interactions
we
need
to
have
with
other
people.
A
Shorter
feedback
loops
and
a
good
developer
experience
help
us
connect
with
the
user,
so
the
developer
experience
doesn't
really
shouldn't
really
focus
on
fast
deployment.
It
should
find
a
way
to
get
faster
feedback.
It's
important
to
keep
that
conversation
going
and
that's
what
a
good
experience
brings
to
the
table.
It
helps
the
developer.
A
B
Yeah
thanks
april,
so
the
the
one
of
the
other
bits
that
I
also
wanted
to
talk
about
was
enabling
discovery,
visibility
and
self-service,
and
what
that
what
that
means
is
effectively
to
go
to
the
next
slide.
Please
debris
it
is
about
giving
developers
visibility
right,
and
this
is
really
crucial
to
unlocking
a
lot
of
where
the
bottlenecks
could
arise.
As
a
developer
working
in
a
cross-functional
team,
I
want
to
have
full
visibility.
I
I
don't
want
to
be
locked
out
of
cloud
4
tools.
B
You
know
if
that
can
play
around
safely,
get
get
hopefully
get
you
know:
read-only
access
to
production
environments
and
getting
access
to
metrics
alerts
and
non-sensitive
blogs,
allowing
the
team
my
team
to
make
their
own
dashboards
effectively,
and
these
are
all
you
know,
giving
the
developers
visibility
onto
the
entire
sdlc
across
the
organization
is
really
a
crucial
element
that
you
can
use
to
unlock
some
of
these.
Some
of
these
problems,
and
really
the
kind
of
the
idea
here
is
to
not
lock
them
out
and
one
way
of
really
kicking.
B
B
And-
and
this
then
comes
to
our
final
point
really
on
you
know,
so
how
do
we
scale
cloud
adoption
and
development
experience,
and
that
takes
me
to
you
know
what
makes
a
good
developer
experience
and
just
the
next
slide
there
please
yeah!
Thank
you.
Yes,
what
makes
a
good
developer
experience
so
good
developer.
B
Experience
really
is
all
about
reducing
the
friction
in
using
cloud
and
potentially
across
the
entire
route
to
life,
and
in
that
context,
and
it's
specifically
in
the
context
of
the
organization
and
it
it
encourages
that
sorry
previously
still
thank
you
yeah.
It
encourages
exploration
of
cloud
features,
so
you
know
you're
able
to
within
a
good
developer
experience
developers
able
to
kind
of
explore
what's
available
in
terms
of
the
cloud
features
and
developers
can
bring.
B
You
know,
trial
things
out
fell
fast,
so
they
can
recover
quickly
and
other
tricks
are
around
qe
strategy.
You
know
in
terms
of
quality
engineering,
what
is
the
testing
strategy?
Where
does
the
test
period
fit
in
in
terms
of
our
development
practices,
and
it's
not
just
across
the
application,
but
also
across
the
infrastructure
layer
and
having
a
focus
on
automation
and
testing
so
more
and
more
that
can
shift
left,
enabling
a
culture
of
communities
of
practice.
B
So
there's
a
culture
of
learning
and
continuous
improvement
is
another
great
enabler
that
you
can
have
in
the
organization
to
adopt
developer
experience
and
engage
your
developers
and
the
best
way
to
do
any
of
these
initiatives
is
by
starting
school
and
the
state
of
devops
2019
report.
One
of
the
one
of
the
things
that
was
found
across
the
industry
in
terms
of
methodology
that
worked
best
is
really
the
templating
methodology.
B
A
So
well
a
good
developer
experience.
What
it
does
is
when,
when
you
get
that
right,
it
creates
an
environment
of
psychological
safety.
You
release
the
developer
from
having
all
these
anxieties
about.
Are
they
doing
the
right
thing?
Are
they
talking
the
right
people?
What
happens
when
they
make
make
mistakes?
A
Now,
if
you
take
that
all
the
way
and
give
them
good
dev
experience
and
created
psychological
safety,
you
help
developers
and
development
teams
to
be
their
best
selves
and
when
they,
when
they
are
their
best
selves
and
they
learn,
and
that
creates
some
new
ideas
and
creates
innovation,
and
it's
also
for
a
developer
not
to
have
not
to
worry
about
all
of
the
things
that
could
go
wrong
and
all
the
things
they
have
to
do.
If
that's
all
built
in
by
default,
it
reduces
the
cognitive
load
for
the
team.