►
Description
Lessons Learned from Corelogic's Year of Agile Development with Cloud Foundry - 01 Richard Leurig 720p
A
A
Several
of
them
are
down
here
in
the
front
row
brando
from
devops,
william
and
erik
from
the
infrastructure,
architecture
and
security
areas,
and
then
Tim
Steele,
one
of
our
senior
architects
and
software
engineers.
Who's
been
involved
with
cloud
foundry
since
we
started
the
project
February
4th
of
last
year
on
our
first
product
we
developed
on
cloud
foundry.
A
Really
what
that
means
for
us
is
discernible
differences
in
analytics
data
platforms
and
data
enabled
solutions
that
service,
the
mortgage,
lending
space,
capital
markets,
the
real
estate
space
specifically
to
Realtors
and
multiple
listing
services,
as
well
as
in
the
insurance,
and
to
some
degrees,
energy
and
oil
and
gas
and
our
spatial
businesses.
A
little
background.
Corelogic
looks
at
everything
from
a
property
level
viewpoint,
we
have
characteristics,
analytics
information
and
risk
modeling
around
properties,
all
things
related
to
a
property.
Everything
from
how
you
pay
your
real
estate
taxes.
A
Every
year
we
pay
a
hundred
and
eleven
billion
dollars
in
real
estate
taxes
on
behalf
of
mortgage
lenders
and
borrowers
of
theirs
to
relist
to
23,000
taxing
real
estate
or
taxing
jurisdictions
across
the
United
States
every
year.
We
also
service
the
insurance
industry
by
delivering
underwriting
information
for
construction
reconstruction
value
costs
for
a
property.
A
So
if
you
own
a
property
own
a
house-
and
you
have
to
ensure
that
property
for
reconstruction
in
case
of
old
fire,
we
maintain
on
the
zip
code
level
all
of
the
information
required
to
reconstruct
a
certain
type
of
house
in
a
certain
zip
code
on
behalf
of
insurance
companies.
We
also
manage
the
mobile
and
platform
areas
for
the
multiple
listing
services
in
the
United
States.
Sixty-Five
percent
of
the
multiple
listing
services
in
the
United
States
either
use
our
mobile
platform
or
our
hosted
service
platform
from
an
application
perspective.
A
So
if
you've
bought
a
house,
you've-
probably
really
you
know
either
had
your.
If
you
sold
a
house,
the
Multiple
Listing
Service
has
had
your
house
on
that
listing
service
on
it's
usually
through
CoreLogic.
If
you've
bought
a
house,
you've
probably
received
information
on
the
houses
that
you
were
gonna
buy
and
they
were
from
CoreLogic.
A
So
about
two
to
two
and
a
half
years
ago
we
embarked
upon
a
journey
to
look
at
what
is
our
next
generation
platform
going?
To
look
like
the
first
thing
we
did.
Is
we
looked
at
the
landscape
of
all
of
the
applications
that
CoreLogic
had
and,
as
you
can
see,
like
many
enterprise,
large
enterprises,
we
had
a
number
of
applications,
a
number
of
technologies.
A
In
fact,
we
found
that
while
we
were
surveying
the
landscape,
there
wasn't
a
technology
that
we
didn't
like
almost
every
database,
every
operating
system
every
you
know
everything
that
you
could
possibly
imagine
that
had
grown
up
organically
over
time
from
a
number
of
acquired
companies.
We
had
grown
up
through
acquisition,
like
many
of
you
probably
have,
and
so
we
ended
up
with
a
lot
of
different
technologies,
and
so
we
we
said
well,
this
is
kind
of
a
mess,
so
we
have
two
alternatives.
A
You
know
we
were
trying
to
build
new
products
that
were
creative
and
innovative.
We
were
using
innovation
as
a
technology
enabler
for
our
business
in
order
to
bring
new
products
to
market
in
a
much
faster
manner.
The
problem
was
with
you
can
see
by
burdened
with
all
of
these
technologies
and
although
the
cost
associated
with
these
technologies
building
efficient
new
products
was
very,
very
difficult
for
us,
so
we
said
okay,
what
do
we
want?
Well,
the
first
thing
we
did
is
we
looked
at
the
industry
and
we
said
things
have
changed
quite
a
bit.
A
Everything
as
a
service
is
a
norm.
Now
you
know
these
big
mainframes
iSeries.
You
know
big
monolithic
applications,
that's
not
the
norm.
We
had
to
look
at
as
data
services
for
our
business.
How
do
we
serve
up
data
on
a
property
to
a
product
without
having
to
go
to
ten
different
databases
or
ten
different
applications
that
we
historically
have
had?
How
do
we
build
a
services
platform
so
that
we
can
have
common
services
like
storing
a
document?
A
We
store
literally
billions
of
documents
and
images
based
on
the
businesses
that
we're
in,
but
we
do
it
about
50
or
60
different
ways.
We
do
security,
authentication
on
our
web
portals,
a
hundred
and
twenty
eight
different
ways.
So
we
said:
okay,
we're
gonna,
do
that
do
it
differently?
What
are
people
in
the
future?
Doing
and
I
coined
the
phrase
when
we
started
talking
to
different
vendors,
we
don't
want
five
years
ago.
We
want
five
years
from
now.
Where
are
things
going?
How
can
we
develop
this
as
a
service?
A
How
can
we
focus
our
developers
on
the
secret
sauce
of
core
logic
and
less
on
this
behemoth,
monolithic,
monolithic
infrastructure
that
we
have
so
we
looked
at
some
design
principles
and
we
said
what
are
we
trying
to
build
for?
Well,
we
want
our
developers
no
longer
focused
on
tweaking
settings
and
web
logic
or
understanding
how
Red
Hat
Linux
works
or
OS
400
or
db2
or
ADA
base,
or
any
of
those
myriad
of
other
things
that
we
had.
A
We
want
user
experience
framework
where
our
users
have
a
better
experience
in
consuming
products
from
CoreLogic,
especially
in
their
businesses,
because
our
customers
are
not
predominantly
consumers,
but
there
are
other
businesses.
We
want
two
components
separated
from
the
application.
Really,
when
you
look
at
this,
it's
it's
kind
of
like
a
service-oriented
architecture,
but
we
landed
upon
micro
services
as
being
a
new
paradigm
that
we
wanted
to
move
to.
We
looked
at
the
flexibility
enabled
by
standard
technologies.
If
you're
developing
things
with
standard
technologies,
developing
new
products
will
be
quicker.
A
We
looked
at
reusability
and
all
of
the
illah
T's.
You
know
we
wanted
it
kind
of
from
from
a
resiliency
perspective.
From
every
perspective
we
wanted
to
be
from
the
very
beginning.
You
can
imagine
with
this
legacy
of
applications,
every
application
did
not
have.
Dr
did
not
have
business.
Continuity
was
not
elastic
to
any
of
our
our
demands
from
a
compute
perspective.
A
We
wanted
that
built
in
and
we
wanted
to
run
on
multiple
infrastructures
as
a
service,
so
we're
primarily
a
vmware
shop,
but
we
wanted
to
be
take
the
opportunity
to
move
things
to
AWS
if
we
wanted
or
any
other
new
infrastructure
as
a
service
that
came
about,
we
basically
created
an
architecture
model,
there's
a
lot
more
detail
behind
this
architecture,
model
kind
of
in
a
reference
architecture
type
of
framework,
but
from
a
from
a
user
perspective.
This
is
how
it
looks.
We
wanted
engagement
with
our
users
through
mobile
and
through
web
to
be
common.
A
A
We
engaged
a
number
of
Technology
experts
and
we
looked
at
a
number
of
things
from
I
mean
I
have
to
tell
you.
There
were
some
legacy
technology,
vendors
that
had
a
pretty
good
story
and
we're
able
to
do
pocs
on
applications
that
we
wanted.
But
when
you
pull
back
the
covers
and
looked
at
what
those
technologies
were,
there
were
five
or
ten
year
old
technologies.
They
couldn't
run
in
cloud,
they
couldn't
elastically
scale.
It
was
a
very,
very
big
problem
for
some
of
the
legacy
vendors
that
we
talked
to.
A
We
also
talked
to
some
of
the
emerging
technology:
vendors
Oracle
I
mean
Google
Salesforce
and
what
FORSCOM
had
to
offer
AWS
we
talked
to
about
how
we
could
use
AWS
and
AWS
services
to
build
this
platform.
We
stumbled
across.
Quite
frankly,
we
we
didn't
quite
understand
why
EMC
was
contacting
us
when
we
embarked
upon
this
two
years
ago,
because
they
didn't
really
have
a
good.
What
I
called
elevator
pitch.
You
know
they
said
trust
us.
A
We
also
were
a
very
big
Red,
Hat
customer,
so
we
started
to
look
at
things
like
open
shift
and
OpenStack
from
the
Red
Hat
perspective
and-
and
we
looked
at
the
whole
thing,
including
market
adoption-
and,
to
be
honest,
you
know,
none
of
the
emerging
technologies
at
that
point
had
huge
market
adoption.
We
ran
POCs
and
they
were
very
close
between
red
hat
and
pivotal,
but
we
felt
like
there
was,
like
a
360
degree
view
that
pivotal
brought
to
bear
on
this.
This
was
more
than
just
a
technology
transformation.
It
was
a
business
transformation.
A
It
was
how
we
could
deliver
products
faster.
Cloud
Foundry
was
a
huge
part
of
that.
This
is
Cloud.
Foundry
Summit
and
we'd
be
remiss
and
not
saying
without
Cloud
Foundry
underlying
what
we're
doing
you
know,
a
lot
of
the
things
that
we've
been
able
to
do
in
the
last
year
wouldn't
be
possible,
but
we
also
engaged
pivotal
from
a
pivotal
labs
perspective
and
a
pivotal
big
data
suite
perspective.
A
So,
since
2014
we
embarked
upon
our
first
project,
our
first
product
February
4th
of
2014
originally
using
our
legacy
technologies.
That
product
was
going
to
go
to
market
about
right
now,
using
twice
as
many
software
engineers
and
using
an
entire
QA
team.
It
was
going
to
take
to
this
day
after
February
4th
for
us
to
launch
the
product
and
get
revenue
in
the
door.
We
started
February
4th
to
2014,
we
went
production
live
July,
1st
2014.
We
used
six
software
engineers
paired,
we
used
one
user
experience
designer
and
we
used
one
product
manager.
A
A
All
three
of
those
have
been
completed,
we're
building
two
new
products.
Now
that
will
go
to
market
soon,
probably
by
mid-year
and
we're
building
two
of
the
big
components
of
our
architecture
now
on
cloud
foundry,
one
of
which
is
the
the
biggest
of
which
is
our
engagement
services
through
my
CoreLogic.
A
So
what
we're
doing
is
we're
bringing
to
bear
and
looking
at
personas
of
the
individual
customers
that
use
our
systems
and
we're
trying
to
get
from
27
different
portals
over
a
hundred
different
security
authentication
methods
down
to
a
single
portal,
but
with
a
unique
experience
for
every
single
customer
that
logs
on
and
we're
building.
All
of
that
and
the
first
version
of
that
is
actually
being
built
right
now
on
Cloud
Foundry
from
an
architecture
perspective,
it's
a
little
hard
to
read
that,
but
we've
redacted
any
useful
information
from
this
that
you
might
use.
A
A
We
originally
thought
that
we
were
going
to
run
Cloud
Foundry
foundation
in
the
front
end
in
a
DMZ
type
of
environment,
we're
a
very,
very
secure
company.
You
can
imagine
working
with
underwriting.
You
don't
want
your
information
lost,
so
we
were
going
to
create
kind
of
a
DMZ
tear
within
fountain
with
using
foundation.
Instead,
we've
gone
to
an
Apache
type
of
a
DMZ
environment
tips
to
basically
isolate
our
Cloud
Foundry
applications
from
the
Internet.
A
We
we
are
still
using
Oracle
RAC
big
debate
inside
of
our
company.
Oracle
RAC,
as
you
know,
is
not
a
cloud
foundry
service.
You
can't
dynamically
provision,
Oracle
RAC
and
you
know
we
still
have
the
encumber
meant
from
an
agile
perspective
from
Oracle
RAC
on
the
backend,
but
we
have
some
very,
very
high
volume
transaction
databases.
A
From
from
the
perspective
of
Dell,
we're
running
the
infrastructure
in
the
Dell
VMware
environment,
on
our
Dell
private
cloud,
it
has
been
a
little
bit
of
a
unique
experience
because
we
had
out
sourced
to
Dell,
so
we
had
Dell
involved
with
trying
to
figure
out
how
to
put
Cloud
Foundry
on.
We
had,
of
course,
the
people
from
pivotal
that
we're
helping
us,
and
then
we
had
our
team
coming
up
the
learning
curve
last
year
about
this
time
on
how
we
were
going
to
deploy
this
into
a
Dell
environment.
All
of
that
we've
done
successfully.
A
So
lessons
learned
there's
a
number
of
them
here
and
I'm
going
to
go
through
them
really
quickly
and
highlight
some
things
for
the
positives.
It's
all
the
things
you
can
imagine
ease
of
application
to
deployment
and
scalability
we've
literally
at
the
push
of
a
button,
can
scale
up
condo,
safe
right
now,
support
for
configurability
of
frameworks
prepackaged
in
the
build
packs.
Of
course,
we're
trying
to
err
on
the
side
of
standardizing
and
keeping
the
build
packs
without
any
customization
pivotal
support
for
Cloud
Foundry
has
been
outstanding.
A
They've
just
been
with
us
side
by
side
every
step
along
the
way.
When
we
first
went
live,
you
know
we
literally
had
mobile
phone
numbers
and
different
things
from
the
firm
pivotal.
It
was
just
a
very,
very
good
experience
and
continues
to
be
a
good
experience.
I
wonder
what
it'll
be
like,
though,
when
we
have
a
thousand
people
on
Cloud,
Foundry
or
10,000
people
on
Cloud,
Foundry
and
then
but
I'm
hoping
it'll
stay
the
same
as
that
goes
from
an
upgrade
perspective.
They
literally
are
push
of
the
button
and
very
straightforward.
A
The
hardest
thing,
though,
that
we're
finding
is
that
we
have
to
push
them
into
foundation
at
the
same
time,
so
we're
running
multiple
applications.
So
it's
a
little
bit
of
scary
when
you're
used
to
an
environment
where
you
do
rolling
or
kind
of
staged,
upgrades
across
an
applications,
portfolio,
easy
integration
with
a
lot
of
the
tools
that
we
use,
including
spunk,
spunk
and
app
dynamics
on
the
areas
for
improvement.
A
Recoverability
is
very
good,
but
there's
still
some
concerns
we
have
about,
and
we
have
a
very
lengthy
discussion
about.
You
know
some
of
the
things
that
we
found
our
applications
automatically
restart
when
they
have
a
problem
which
is
great,
but
sometimes
that
doesn't
work
as
well
as
we
it
would
expect
or
as
we
would
expect
it
to
work,
we
would
like
a
health
dashboard
that
looks
at
the
entire
ecosystem.
A
lot
of
people
have
developed
those
on
their
own
we'd
like
it
as
part
of
the
product.
A
We
need
more
well.
Backups
is
a
good
another
good
one
to
touch
upon
the
documentation
says:
do
backups
often
do
lots
of
backups
and
then
there's
a
lengthy
process
that,
if
you
followed
it
would
take
a
half
a
day.
So
we
automated
that
process,
and
you
know
we're
able
to
do
it
in
a
very
short
period
of
time,
but
it
really
doesn't
come
out
of
the
box
with
the
product
or
with
Cloud
Foundry.
At
this
time
we
need
finer
grained
controls
around
security,
it's
just
basically
for
our
industry
and
our
business.
A
It's
too
broad
right
now.
We
have
to
give
too
broad
of
kind
of
remit
to
a
number.
The
people
working
on
the
system
today
and
the
admin
function
does
not
allow
us
to
look
at
the
details
of
those
at
the
level.
We
want
in
a
very
easy
and
seamless
way,
so
it's
kind
of
like
security
needs
to
come
up
the
learning
curve
a
little
bit
in
the
Cloud
Foundry
world.
A
The
other
thing
is,
we
have
environment
variables
that
sometimes
inadvertently,
because
of
the
way
the
system
works
and
the
pass
works
are
inadvertently
exposed
out
to
tools
like
app
dynamics,
so
things
that
we
don't
want
necessarily
to
be
in
logs
or
out
in
an
app
dynamics.
World
are
actually
exposed
there
in
the
clear
areas
of
interest
for
us
well,
very
quickly.
A
We
continue
to
look
at
how
do
we
balance
between
a
Cloud,
Foundry
world,
agile
development
and
quickly
deploying
with
all
of
the
enterprise
standards?
We
have
the
cab,
the
change,
the
change
process,
so
we're
trying
to
converge
our
change
process
and,
what's
required
by
our
industry
and
by
our
customers,
in
with
this
agile
notion,
with
this
Cloud
Foundry
notion
of
quick
development
with
a
platform
as
a
service
and
deploying
it
quickly.
A
The
other
thing
is
to
be
honest:
we
have
a
really
really
difficult
time
telling
our
business
users
right
now
how
much
an
application
is
going
to
cost
and
that's
because
with
the
elastic
compute,
with
the
ability
to
scale
up
our
applications,
but
also
because
they're
sharing
a
lot
of
the
same
environment
and
before
we
very
costly.
But
we
had
individual
environments
for
all
these
applications.
Now
we're
putting
all
of
these
products.
A
Core
logic
has
into
kind
of
the
Cloud
Foundry
bucket
doing
business
cases
and
explaining
and
articulating
what
the
allocation
or
how
does
how
to
spread
the
money
out
is
very
difficult,
still
and
very
immature
in
this
environment.
For
us
network
planning
took
us,
probably
the
bulk
of
the
time
it
always
seems
to
from
a
DNS
security
perspective.
A
The
one
thing
I
wanted
to
note
here
is
we're
now
looking
at
taking
the
legacy,
applications
and
moving
them
over
to
Cloud
Foundry.
So
that's
not
what
we
started.
That's
now
where
we
are
and
we're
starting
to
deploy,
Cloud
Foundry
into
things
like
AWS
and
vCloud
air
and
have
a
hybrid
environment
for
our
applications.
So
that's
a
big
focus
for
us
in
2015.
A
A
A
A
A
So
we
still
believe
in
the
micro
services
infrastructure
at
Cloud
Foundry,
but
we're
interfacing
with
a
lot
of
third
parties
on
a
lot
of
downstream
legacy
applications.
And
so
we
believe
there
has
to
be
a
blended
approach
to
the
two.
It
can't
be
all
one
or
all
the
other
and
believe
me,
there's
religious
camps
on
both
sides
and
they're
all
in
here
from
core
logic
and
I'm.
Sure
many
of
you
are
there
and
we
seem
to
be
on
the
side
of
yeah.
A
A
A
Okay,
so
the
question
was:
are
they
green
field
applications
or
were
they
transitioned
over
from
that
from
a
legacy
environment?
On
all
of
the
applications?
I
listed
were
Greenfield
new
products
for
us
that
were
written
entirely
on
Cloud
Foundry,
but
in
each
case
they
interfaced
it
with
back-end
services
and
other
things
that
existed
for
us
that
they
had
to
interoperate
with,
but
they
were
all
greenfield
type
of
applications.
A
As
I
said
this
year,
we're
gonna
look
at
taking
legacy
actual
legacy,
applications
without
major
rewriting
and
try
to
move
those
over
to
the
Cloud
Foundry
environment,
but
our
goal
was
speed
to
market
of
new
products
and
being
more
competitive.
So
for
us
it
was
building
new
products,
not
necessarily
just
a
cost.
Rationalization
play
we're
trying
to
go
down
both
past
this
year.
A
B
A
I
think,
as
we
grow
the
the
Cloud
Foundry
application
portfolio,
there
is
still
ongoing
kind
of
review
of
the
infrastructure
and
I
don't
know
Eric.
If
you
want
to
point,
you
know
talk
about
that,
but
from
a
bottleneck
perspective,
we're
pretty
confident
on
what
we're
doing
right
now,
we've
added
the
three
out
of
the
three
products
in
and
they're
being
used
in
production.
But
Eric
do
you
want
to
elaborate?
We.
B
Requires
intervention,
so
we'd
like
to
see
that
in
part
of
the
evolution
we
are
also
likely
to
be
running
more
than
one
foundation
in
the
future,
to
set
to
segregate
out
sensitive
data
from
less
sensitive
data,
primarily
also
to
you
know,
because
we
are
trying
to
build
enterprise
class
applications
and
really
a
pass
on
top
of
a
pass
right,
authentication
and
teittleman
services
document
storage.
We
anticipate
running
multiple
foundations
within
each
datacenter.
A
B
You
definitely
need
to
augment
it
with
monitoring.
So
now
you
you
get,
you
get
a
DMX
endpoint,
but
you
have
to
have
some
place
to
send.
That
and
AppDynamics
gives
us
visibility
into
the
applications
that
we
wouldn't
otherwise
have.
So
you
absolutely
need
you
need
to
build
a
monitoring
framework
around
founder.
A
Okay,
so
anyway,
I
appreciate
everyone
like
I,
said:
there's
a
lot
of
people
here
from
core
logic.
This
is
all
about
collaboration
and
sharing
information.
We've
got
every
aspect
of
our
stack
here
from
resource
perspective.
We're
very
excited
about
what
we're
doing
we're
very
excited
to
hear
about
what
all
of
you
are
doing.
So.
Thank
you
very
much
and
have
a
great
summit.