►
Description
From Commercial to Open Source Cloud Foundry in the Enterprise - Rachael Wonnacott, Fidelity
International
Fidelity’s PaaS supports business critical applications such as retail websites and trading systems, while offering a six-9s SLA across both the UK and Asia. A key driver in their cloud strategy has always been to deliver features to developers in a cost effective way. The transition to using open source Cloud Foundry has afforded Fidelity the autonomy to tailor releases to meet the rising demand from developers. Fidelity would like to share their experience focusing on the deployment and migration decisions (running two CFs in parallel, migrating applications with zero down-time, and the benefits of a single deployment mechanism). In addition, to explore the ongoing implications for the globally distributed PaaS team who operate it (increased responsibility, utilisation of the open-source community, and the change in workload) and ask - 'Is the platform sustainable?'
https://cfseu18.sched.com/event/FRzD/from-commercial-to-open-source-cloud-foundry-in-the-enterprise-rachael-wonnacott-fidelity-international
A
Engineers
can
throw
okay
so
before
we
get
started
today,
I
thought
it
was
personal
I
set
the
scene
and
for
those
of
you
who
perhaps
haven't
seen
us
at
summit
before
tell
you
a
little
bit
more
about
fidelity
international.
We
are
a
privately
owned
company,
founded
in
1969,
offering
both
investment
solutions
that
are
our
own
and
those
of
others.
A
A
We
started
our
cloud
foundry
journey
about
four
years
ago,
when
we
were
a
technology
driven
organization
that
was
looking
to
reduce
our
time
to
market.
It
was
really
as
simple
as
that
and
the
appeal
of
cloud
foundry
lied
in
that
it
lets
the
app
developers
only
care
about
the
applications
and
the
data
without
caring
about
the
underlying
infrastructure.
But,
additionally,
we
really
like
that
cloud.
Foundry
is
governed
by
a
foundation
and
would
give
us
the
opportunity
to
go
open-source
at
a
later
date.
A
Last
year,
the
disruptive
principles
that
underpin
our
path
service
were
nominated
for
an
award
at
the
financial
services
technology
Awards
we
presented
at
summit
two
years
ago
with
a
keynote
on
how
we
put
our
product
team
together.
So
we're
a
DevOps
team
and
last
year
are
really
wonderful.
Product
mohamad,
who
sadly
isn't
with
us
today,
was
awarded
the
clouds.
A
So
in
the
beginning
it
was
really
difficult
for
us
to
know
what
the
future
of
the
platform
would
be.
What
would
the
adoption
of
the
platform
be
like?
We
were
introducing
a
very
new
concept
into
what
I
would
argue
was
a
very
traditional
landscape
and
it
was
difficult
to
estimate
how
many
applications
would
want
to
migrate
and
of
those
that
did
at
what
rates
would
they
want
to
migrate?
What
would
the
traditional
landscape
mean
for
us?
How
would
we
transform
from
traditional
deployment
methodologies
to
cloud
native
ones?
A
Ultimately,
our
entire
journey
has
been
underpinned
by
one
theme,
and
that
theme
here
is
capability,
so
when
I
say
capability,
what
do
I
mean?
I
mean
two
things:
I
mean
the
capability
of
the
platform
team
and
I
mean
the
capability
of
the
developers
and,
as
I
said
in
the
beginning,
it
was
difficult
to
confirm
what
it
would
mean
for
us
to
run
a
cloud
foundry
platform.
So
we
wanted
to
ask
ourselves
some
questions
so
how
highly
available
would
this
platform
be
in
practice?
What
monitoring
should
we
put
in
place?
A
A
Over
the
first
two
years,
it
became
very
apparent
that
a
path
was
very
popular.
Many
existing
business,
critical
applications
have
migrated
to
the
platform,
and
it
was
a
really
popular
choice
also
for
greenfield
projects.
So
we
had
a
bit
of
a
challenge,
and
this
challenge
is
something
that
I
will
affectionately,
call
the
bloat.
Hence
the
pufferfish,
and
by
the
bloats
I
mean
a
swell
of
platform
utilization.
When
our
legacy
apps
first
began
to
move
to
the
cloud,
they
were
not
optimized
to
be
run
in
the
cloud.
For
a
couple
of
reasons.
A
We
had
monolithic
architectures,
we
were
utilizing
memory
intensive
languages,
we
had
long
release
cycles,
we
even
had
separate
development
and
testing
teams,
and
people
were
quite
uncomfortable,
with
the
concept
of
spinning
up
and
up
and
down
on
demand,
both
their
applications
and
also
their
dev
environments,
and
this
kind
of
meant
that
we
had
this
really
big
peak
load.
This
swell
of
the
platform
over
time
with
experience
and
education,
people
started
to
split
out
their
applications
into
micro
services,
which
was
fantastic.
A
However,
with
this
came
a
demand
who
split
out
these
larger
orgs
that
had
previously
been
representative
of
apps
into
smaller
org
spaces
that
were
representative
of
shared
micro
services
that
could
be
consumed
by
multiple
applications,
which
is
great
but
the
problem
with
our
original
licensing
model.
This
was
very
expensive.
A
So
how
could
we
encourage
good
behavioral
change
when
it
came
at
a
price
for
the
app
developers
so
over
those
first
two
years
that
I've
just
been
talking
about
we'd
built
a
great
confidence
in
ourselves
as
a
platform
team
and
our
ability
to
manage
the
platform
and
the
demand
for
the
pars
was
showing
absolutely
no
signs
of
slowing
down.
So
we
needed
a
solution
that
would
scale
more
favorably
with
our
organization.
So
we
started
to
investigate
what
it
would
mean
to
fully
adopt
open
source
cloud
foundry.
A
A
So
really,
how
do
we
do
it?
A
move
to
open-source
was
a
huge
risk
and
this
risk
needed
to
be
evaluated
and
from
an
enterprise
perspective
as
an
FCA
regulated
company,
with
very
little
appetite
for
risk.
We
were
traditionally
accustomed
to
using
vendors
and
making
use
of
support
contracts,
so
open
source
felt
very
uncomfortable.
The
two
main
concerns
that
we
had
were
one:
how
will
we
take
code
from
the
internet
and
package
it
for
internal
use
and
how
would
we
support
this
platform
as
a
standalone
team?
A
Our
platform
hosts
Triple,
A
plus
rated
applications,
and
therefore
we
really
have
to
ask
the
questions
of
security
for
what
it
would
mean
to
code
in
the
open
and
that
involved
conversations
with
both
legal
and
security
teams,
and
they
gave
us
a
list
of
things
that
we
would
have
to
be
able
to
do
so.
We
could
have
no
degradation
in
the
service,
no
introduction
of
risk.
We
needed
to
be
able
to
maintain
our
security
assurance.
There
could
be
no
change
in
the
headcount
and
no
downtime
during
the
transition.
A
A
A
Additionally,
as
a
team
and
as
a
company,
we
were
keen
to
give
back
to
the
community.
We
are
silver
members
and
in
the
early
days
when
we
were
looking
at
open
source,
we
were
making
customizations
on
our
local
that
we
weren't
able
to
share
with
the
community
by
making
upstream
pool
requests.
So
this
is
something
that
we're
doing
now.
So
if
you
want
to
check
us
out
on
github
by
all
means,
please
do
right,
so
it
was
more
than
just
the
open
source
community.
A
It
was
about
trust
and
we,
the
platform
team,
trusted
the
Cloud
Foundry
code.
So
if
you
consider
this
from
an
architectural
perspective,
the
open-source
platform
would
really
be
no
different
to
the
commercial
one.
The
only
difference
we
could
see
was
that
the
responsibility
to
package
and
release
the
platform
would
now
be
ours,
and
initially
people
were
quite
nervous
about
this,
as
they
thought
that
it
would
bring
change
to
the
platform,
but
actually,
from
the
perspective,
the
developers
they
should
have
seen
no
change
whatsoever.
So
what
about
security?
A
How
would
we
secure
taking
the
code
from
the
internet?
A
lot
of
people
have
asked
us
about
this
today.
So
this
is
a
point
I
want
to
highlight.
Actually
I
would
argue
that
our
approach
to
security
is
now
infinitely
more
flexible
that
we
are
with
open-source.
This
new
responsibility
to
package.
Our
own
releases
makes
it
possible
for
us
to
choose
to
upgrade
individual
components.
Therefore,
if
we
are
to
you
hear
about
a
security
or
notice
security
fix
for
vulnerability
in
a
component
upstream,
we
are
able
to
upgrade
just
that
component.
I,
don't
have
to
wait.
A
We
don't
have
to
wait
as
a
team
for
a
vendor
to
package
a
release.
We
can
update
just
that
component
and
this
reduces
the
time
it
takes
us
to
secure
our
platform.
Equally,
we
can
make
the
executive
decision
on
what
components
to
upgrade,
and
when
do
we
want
to
do
a
large
release
and
upgrade
all
components
in
one
go
or
do
we
prioritize
individual
components
that
have
known
defects
or
vulnerabilities?
Equally,
if
there's
a
customer
demand
or
a
development
demands
for
a
particular
component,
we
can
also
upgrade
that
to
meet
their
needs.
A
We
are
now
autonomous
in
our
ability
to
prioritize
and
schedule.
So
hopefully
some
of
you
will
recognize
this.
So,
in
addition
to
demonstrating
that
there
were
no
architectural
differences
between
the
commercial
and
the
open-source
platform,
we
needed
to
be
able
to
demonstrate
that
we
could
deploy
and
operate
the
platform
ourselves.
A
commercial
Cloud
Foundry
will
have
an
assured
upgrade
path,
so
we
need
to
be
able
to
replicate
this
ie.
We
needed
to
be
able
to
reliably
deploy,
monitor
and
upgrade
the
platform.
A
So
at
this
point
we
were
using
another
open-source
tool
called
concourse
to
run
automated
monitoring
jobs
against
our
platform,
and
we
could
already
see
the
benefits
at
this
stage
of
concourse
as
a
tool
that
it's
of
automation
and
we
could
see
the
pent
potential
to
use
it
for
what
it's
really
intended,
which
is
C
ICD
pipelines,
and
when
we
started
writing
our
pipelines
from
scratch.
We
had
a
look
and
assess
our
current
environment.
A
So
back
in
2015
in
the
Frankfort
summit,
we
had
a
presentation
about
how
we
deploy
Cloud
Foundry
to
two
datacenters
and
have
that
highly
available
across
Multi
datacenter.
We're
now
actually
deploying
to
six
different
datacenters
internationally,
and
because
we
do
this,
we
are
able
to
temporarily
offline
a
data
center
so
that
we
can
make
changes
to
it,
be
that
maintenance
or
upgrades
and
reroute
all
out
traffic
to
the
other
side.
So
there's
no
interruption
to
the
service
for
our
customers
right.
A
This
is
my
favorite
slide,
so
there
are
only
two
things
in
our
world
and
those
two
things
are
configuration
and
code,
and
both
of
these
things
should
be
version
controlled,
peer-reviewed
and
stored
in
get
everything
we
do
as
a
team
follows
on
from
those
principles,
if
you
take
anything
away
from
my
talk,
please
remember
this
slide,
so
our
deployment
pipeline
is
the
core
unit
of
everything
that
we
do
day-to-day.
This
pipeline
is
using
Concours,
which
is
a
CI
CD
system
with
the
pipeline
as
declarative
configuration,
we
practice
pair
programming.
A
So
any
change
is
viewed
and
re
reviewed
by
multiple
engineers,
a
pair
to
write
the
codes,
a
pair
to
review
the
pool
request.
So
in
theory,
that's
four
sets
of
eyes
and
by
storing
everything
in
get
we're
provided
with
a
full
audit
trail.
So
what
was
merged
when
was
it
merged
and
by
whom?
So
we
are
both
confident
that
any
change
we've
made
has
gone
through
multiple
checks,
but
also
that,
if
we
needed
to,
we
can
recover
to
any
known
state
at
any
time.
A
Okay,
so
there
are
several
prerequisites
that
you
need
to
meet:
to
deploy
a
Cloud
Foundry
platform.
Some
of
them
are
here
so
there
are
IP
ranges:
VM
folders
storage
assignments,
perhaps
C
sed
system,
and
when
we
were
running
a
commercial
platform,
we
were
meeting
these
prerequisites
manually,
mostly
using
a
GUI
which
unfortunately
left
us
open
to
making
mistakes,
and
it
also
did
not
provide
us
with
that
audit
trail.
So
we
really
wants
to
find
a
way
to
automate
this
and
make
everything
either
configuration
or
code.
A
So
we
did
that
by
building
our
own
automation,
tooling
and
then
using
Concours,
and
you
can
see
some
boards
here
as
a
CI
CD
mechanism
to
deploy
it.
This
means
we
now
have
a
set
of
configuration
which
provides
us
with
both
a
higher
level
of
deployment
confidence,
but
also
that
previously
mentioned
audit
trail
and
as
an
FCA
regulated
company.
This
is
something
that's
really
crucial
from
us
for
us
from
a
security
perspective.
A
A
We
have
something
I
hope
you're
familiar
with,
which
is
idempotency.
So
the
concept
that
multiple
identical
requests
have
the
same
effect
as
making
a
single
request.
So
anytime
we
want,
we
run
this
pipeline.
We
know
that
it's
following
exactly
the
same
process:
it's
executing
exactly
the
same
tests
and
therefore
producing
exactly
the
same
platform.
So
this
and
by
writing
our
pipeline
as
a
series
of
asynchronous
jobs.
We
can
rerun
any
individual
step
without
affecting
the
end
state
of
the
platform.
A
So
to
go
back
to
my
previous
slide
about
the
things
we
had
to
meet
to
run
open
source,
we're
not
introducing
any
unexpected
change
and
thereby
we
re
running
a
job.
There's
no
introduced
risk
and
this
is
a
sort
of
a
inbuilt
error,
recovery
method.
So
with
any
system
something
might
fail-
and
we
must
engineer
for
said
failure,
and
we
can
be
confident
that
we
can
recover
quickly.
So
idempotency
can
bind
with
this
ability
to
rerun
individual
steps
means
we
have
effective.
Inbuilt
error,
recovery,
okay,
so
this
is
our
deployment
pipeline.
A
It's
very
big,
so
you
probably
can't
read
anything.
That's
partly
deliberate,
but
I
haven't
going
to
go
through
what's
half
a
day
on
screen,
so
the
very
first
step
of
our
pipeline
is
a
lock,
and
that
means
that
only
a
single
execution
can
happen
at
any
one
time
and
that's
helping
us
to
ensure
that
idempotency
I've
just
meant
so
only
one
set
of
configuration
will
be
running
through
at
any
one
time.
A
So
if
we
do
rerun
any
individual
job,
we're
not
introducing
any
new
state
or
any
new
risk,
but
we
then
have
a
step
that
checking
for
configuration
change
for
concourse.
That's
all
happening
automatically
and
we're
going
to
send
notifications
to
our
users
to
alert
them
of
any
maintenance
or
outbreak
that
happens
via
email.
That's
the
third
step
along
our
datacenter
is
then
marked
offline
in
the
load,
balancer
configuration.
So
that's
going
back
to
the
point.
A
I
mentioned
about
operating
out
of
two
days
sensors
and
we
now
need
to
deploy
bosh
because,
of
course,
we're
using
bosh
to
deploy
cloud.
Foundry.
We've
also
recently
started
making
user
cred
hub
to
dynamically,
generate
our
credentials,
and
then
we
provide
Bosch
the
cloud
configuration
to
generate
the
manifests
for
the
CF
databases.
Now,
by
listing
all
of
these
things,
what
I'm,
hoping
you're
taking
away
is
a
lot
of
stuff
has
to
happen
before
we
can
even
consider
deploying
cloud
foundry.
A
Okay,
so
when
we
were
using
a
commercial
cloud
foundry,
we
were
relying
on
their
acceptance,
tests
of
which
we
didn't
have
any
visibility,
whereas
now
that
we're
using
open
source
and
the
open
source
acceptance
tests,
we
actually
have
gained
a
greater
understanding
of
the
platform
so
for
any
failing
test.
I
can
look
at
what
failed
the
error
message
and
thereby
gain
a
greater
understanding
of
the
behavior
of
that
particular
component.
So
for
each
service.
On
our
platform,
we
have
three
synchronous
steps
which
I
have
summarized
here,
so
that's
interpolate,
deploy
and
then
test.
A
We
have
known
state
at
all
times
in
the
form
of
these
controlled
configuration
files.
Hopefully
you're
sensing,
a
theme
and
the
interpolate
step
reads
this
config
so
that
it
to
Porsche
can
deploy
it
in
a
required
state
which
can
then
be
redeployed
to
a
known
state.
Should
it
be
required
to
do
so?
So
if,
for
some
point
at
some
point,
so
the
internet
wasn't
working,
we
could
just
rerun
the
job
and
everything
would
be
fine
for
confidence
in
our
deployment.
A
We
actually
pushed
lightweight
test
applications
to
perform
simple
integration
tests
that
we
can
validate,
that
we
are
able
to
still
push
an
app
and
bind
said
service
to
the
app
I
know.
It
sounds
really
basic,
but
you're,
never
too
good
for
the
basics.
Any
example
apps
and
services
are
torn
down
afterwards
to
make
sure
that
we're
not
introducing
extra
load
to
the
platform.
A
Additionally,
we
have
our
own
custom
acceptance,
tests
which
check
the
behavior
of
components
such
as
Doppler
in
the
logo,
gate
system
and
also
test
components
which
are
unique
to
our
business
requirements.
We're
currently
offering
operating
a
shared
logging
solution,
and
while
it
is
known
they're,
not
all
logs
are
guaranteed
to
make
it
to
their
destination.
It
is
important
that
a
certain
threshold
do
so.
We
are
monitoring
our
local
gate
system
and
to
end
by
deploying
an
application
that
emits
no
logs,
and
then
we
check
to
see
how
many
reach
their
side.
A
I'm
not
going
to
spend
too
much
time
talking
about
it,
but
it
is
worth
mentioning
that
we're
also
utilizing
Prometheus
to
capture
our
platform
metrics.
So
how
can
we
safely
make
changes
to
our
tests?
Well,
all
our
configuration
is
managed
by
git,
so
we
can
do
all
of
our
testing
on
branches,
and
this
means
that
we
can
utilize
that
same
deployment
pipeline
for
testing
our
code
before
we
even
raise
any
pull
requests
and
we
can
check
the
behavior.
A
The
the
merge
change
is
automatically
picked
up
by
our
CI
environment
and
if
it
makes
it
through
the
CI
environment
successfully,
that's
automatically
picked
up
by
staging
one
and
so
on.
If
it's
successful
in
staging
one,
it's
automatically
picked
up
by
staging
2
at
each
stage.
Here
our
deployment
is
tagged
to
say
that
it
was
successful.
The
entire
commit
sorry,
the
entire
release,
including
all
of
its
commit
references
for
every
single
component
that
has
been
deployed
as
tagged
and
the
men
could
be
fed
into
subsequent
pipelines.
A
And
that
way
we
can
ensure
consistency
from
pipeline
to
pipeline
if
everything
makes
it
through
ci
staging
one
staging
to
we're,
then
highly
confident
for
it
to
pass
into
non
production,
which
is
part
of
our
runtime
environments,
represented
just
here,
however,
to
minimize
disruption.
We
do
often
choose
to
make
releases
by
grouping
a
set
of
changes,
but
again
because
we
run
the
platform
we
can
choose
how
and
when
we
do,
that.
Something
I
would
like
to
call
out.
A
Is
this
GPG
signing
up
here,
so
we're
using
GPG
commit
signing
to
indicate
a
release
version
for
deployment
into
the
runtime
environments,
which
is
essentially
our
product
owner
seal
of
approval
and
as
an
extra
level
of
security?
Only
certain
members
of
the
team
have
the
correct
admin
privileges
to
be
able
to
do
so.
A
So
how
do
we
tag
successful
deployments?
So
the
reason
that
we're
doing
that
is
that
we
want
to
know
that
the
code
has
been
successful
and
the
code
that
we
deploy
into
higher
level
environments,
ie
non
prods
and
prod.
We
need
to
be
completely
confident
they've
been
testing
that
they
work,
so
nothing
that
goes
into
a
higher
level.
Environment
hasn't
already
succeeded
in
a
lower
one,
and
tagging
also
provides
a
complete
audit
trail.
I
know
that
I've
mentioned
order
a
few
times,
but
it's
very
important.
A
There
we
go,
we
can
also
see
who
merged
the
change,
so
if
we
did
have
to
hold
anybody
accountable
for
anything
that
is
possible
okay,
so
what
you
saw
on
the
other
slide,
isn't
quite
accurate
things.
Actually
look
a
little
bit
more
like
this.
If
you're
good
at
counting
you'll
notice,
24
CF
foundations,
we
actually
have
26,
so
we've
got
all
of
our
dev
M's
on
the
left.
A
We
have
that
CI
staging
one,
the
staging
two
scenario
that
I've
just
walked
you
through
and
then
you've
got
a
bit
more
of
an
accurate
picture
of
our
runtime
environment.
On
the
right.
The
clocks
represent
a
two
day:
wait,
which
is
just
an
extra
level
of
security,
to
make
sure
that
we're
happy
that
what
happened
in
non
prods
can
then
go
into
production.
A
These
26,
Cloud,
Foundry
foundations,
are
spread
across
the
UK
and
Asia
and
they're
all
deployed
using
that
same
deployment
pipeline.
We
are
making
use
of
the
stopover
resource
from
our
friends
engineer,
better
he's
on
his
phone,
so
automatically
pin
our
conquers
pipelines
to
specific
versions
of
resources,
and
this
allows
us
to
reuse
that
same
pipeline
yeah
more
for
all.
Our
different
environments,
we
don't
like
to
add
code,
we
always
want
to
minimize
code,
and
this
way
we
can
basically
ensure
consistency
across
to
everything.
A
Okay,
so
you've
heard
about
how
we're
doing
the
deployment.
But
how
do
we
make
the
transition
okay?
So
we
chose
to
run
to
cloud
boundaries
in
parallel,
the
commercial
cloud
and
the
cloud
foundry
one
well,
the
open
source,
Cloud
Foundry
one,
and
this
of
course
meant
an
increased
cost
of
running,
and
we
also
needed
to
invest
in
some
new
infrastructure
since
we
run
our
CF
on
virtualized
infrastructure
internally.
A
Despite
this
overhead
deploying
to
cloud
foundries
allowed
us
to
directly
compare
the
behavior
of
both
of
the
platforms
and
to
ensure
confidence
that
there
would
be
no
degradation
of
service
or
introduction
of
risk
and
by
running
them
both
at
the
same
time.
It
basically
gave
us
the
time
to
do
that.
How
do
we
ensure
that
we
were
capable
of
doing
this
direct
comparison?
Well,
when
we
built
our
open-source
platform,
we
chose
components
that
match
the
build
of
the
current
version
of
the
commercial
one.
A
Where
possible,
we
ran
exactly
the
same
test
suite
against
both
platforms,
and
we
also
utilize
the
open
source,
Cloud
Foundry
acceptance
test
to
have
even
more
coverage
to
what
we
originally
had
of
the
commercial
platform.
And
additionally,
we
asked
our
lovely
app
developers
to
push
to
both
platforms
during
a
migration
period
so
that
we
could
do
a
direct
comparison
of
performance
so
that
all
the
developers
were
happy
that
there
would
be
no
change
for
their
experience
or
the
customer
experience
when
using
their
applications.
A
This
is
meant
to
be
the
migration
period
so
due
to
a
hot
architecture
already
being
set
up
across
two
days,
centers
apps
were
actually
already
written
to
be
deployed
to
separate
Cloud
Foundry
foundations,
so
that
was
really
useful
for
us.
The
network
routing
that
was
already
there
actually
enabled
us
to
be
able
to
push
twice
to
two
different
platforms,
so
we
didn't
need
to
engineer
anything
fresh.
A
It
was
also
therefore
reasonable
for
us
to
ask
our
developers
to
push
to
another
platform
in
addition
to
where
they
were
already
pushing,
and
we
were
also
quite
prepared
for
moving
our
security
groups
as
we
had
an
existing
plugin
plugin.
That
means
that
our
developers
can
directly
push
their
security
group
configuration
alongside
their
apps.
So
what
I
really
want
to
highlight
here
is
that
we
didn't
do
a
lot
of
engineering
here
for
the
migration.
A
Our
app
teams
were
mostly
using
some
form
of
CI
or
CD
workflows
to
deploy
their
apps,
we're
not
prescriptive
and
what
they
choose
to
use.
So
in
general,
it
was
as
simple
as
asking
them
to
add
the
new
foundation
to
their
workflows.
The
key
here
for
the
migration
was
actually
communication,
not
technology,
so
we
need
to
ensure
that
our
developers
knew
well
in
advance
about
what
they
would
need
to
do
to
deploy
their
apps
and
to
educate
them
on
the
use
of
open
source.
A
There
was
a
lot
of
nervous
energy
and
we
needed
to
make
sure
that
everyone
was
happy
with
the
move.
We
have
numerous
different
product
teams
and
it's
quite
hard
to
get
them
to
agree
to
do
everything
all
at
the
same
time,
so
in
general,
coordinating
a
large
number
of
people
is
not
easy,
especially
when
they're
spread
across
the
globe
operating
two
different
schedules
and
in
different
time
zones.
So
what
we
wanted
to
have
was
a
mechanism
whereby
we
would
still
be
able
to
complete
the
switchover,
even
if
one
product
team
wasn't
ready.
A
A
Okay.
So
how
do
we
migrate
security
and
service
settings
that
hasn't
rendered
very
nicely?
I
apologize?
It
would
be
unreasonable
customer
experience
to
ask
developers
to
make
requests
for
all
of
their
services
again,
not
to
mention
a
large
volume
of
work
for
us
to
recreate
them,
and
thankfully
we
were
able
to
automate
this,
and
it
was
quite
simple.
We
simply
wrote
scripts
that
queried
the
UAA
database
and
then
repopulated
all
of
that
in
the
open
source
platform.
A
All
the
previous
configuration
had
an
audit
trail
and
had
product
owner
approval,
so
it
was
simply
a
copy
and
paste
exercise
really
and
the
only
real
complexity
was
making
sure
that
we
could
automate
it
by
writing
the
plug-in
as
a
way
of
ensuring
that
everything
had
been
copied.
We
checked
that
all
the
commands
went
through
successfully
and
anything
that
didn't
go
through
was
recorded
in
a
retrials
file,
which
was
just
that
retried
and,
as
a
very
final
pass
over.
A
We
checked
a
few
things
manually,
but
for
the
most
part,
everything
was
automated
end
to
end
okay,
I.
Imagine
the
question
that
you're
all
asking
is:
how
long
did
this
take
us?
Well,
not
actually
that
long.
So
our
inception
period
start
is
at
the
end
of
January,
early
February
and
by
the
end
of
October.
We
completely
switched
off
our
commercial
platform,
so
the
go
live
for.
The
platform
was
really
at
the
end
of
July
and
between
July
and
September.
A
We
are
encouraging
all
of
our
app
developers
to
migrate
to
both
sides
and
then
at
the
beginning
of
September,
we
were
expecting
all
of
our
app
developers
to
have
moved
their
apps
across.
We
left
that
month
period
there
essentially
to
predict
that
there
would
be
some
stragglers,
I
think
in
any
organization
you're
going
to
have
people
running
late,
so
we
had
that
there
as
a
fail-safe
and
any
of
those
people
were
caught
by
the
redirector
app.
A
So
a
long
story
short
I'd
want
to
highlight
that
if
you're
thinking
about
going
open-source
and
you're
currently
using
a
commercial
platform,
we
were
already
in
a
really
good
place.
We
were
very
comfortable
with
running
the
platform.
We
were
very
comfortable
with
the
software.
There
was
a
lot
of
trust,
trust
in
the
Cloud
Foundry
code,
trust
in
ourselves
to
run
the
platform,
and
we
were
very
open
that
it
was
a
big
risk.