[MUSIC PLAYING]
BRUNO AZIZA: Welcome to another episode of Data Journeys.
This is where we come to learn from data leaders.
And today, I'm excited to talk to Bob.
Bob is the CTO of Choreograph.
This is a fast-growing organization,
really focused on data, five petabytes of data
under management.
We're going to talk about the work that they're doing.
Bob, thank you so much for talking to us today.
Let's get right into it.
What does Choreograph do?
BOB HAMMOND: Yeah, my pleasure.
Good to see you.
So Choreograph is the--
let's call it the data platform or the data enablement
arm of WPP.
So over the years, we've actually
produced a lot of really cool, really advanced both technology
stacks, also data products, as well,
and application services for WPP at our agencies.
And about a year and a half ago or so,
Mark Read decided that he wanted to bring the best of breed
technology and organizations together
collectively under Choreograph, which
is pretty cool, because, as you guys know,
the aggregation of data into a single point
and the enablement of that data at the application space,
there's nothing more powerful than that, right?
And the amount of-- as you mentioned,
the amount of data that we manage undercover
is very significant.
So being able to bring that all together and then
power that into the application space for WPP and our agencies
is just really remarkable stuff.
So we've been working on it now for about a year and a half
or so, bringing together basically
10 different applications and services
together under Choreograph's umbrella
and then working now to aggregate those
into a central platform that we're calling the Data
Cloud, which is going to power our applications and services
across WPP for our agency friends.
BRUNO AZIZA: That's outstanding.
So you're selling into agencies, obviously
large volume, a lot of intelligence
going into these solutions.
So tell us a little bit about the use cases.
How is the data prepared?
How is it consumed?
How does it work?
BOB HAMMOND: Yeah, really good question.
So we deal in multitudes of services and data types,
everything from data and identity type data to audience
generation, to the selection of audiences
based on campaign requirements, so building those audiences up,
extending those audiences through ML services,
such as lookalike and clustering,
and a bunch of other services, as well,
exporting that information in those data
sets into campaign planning platforms
so that our planners can actually put together
best of breed plans against campaign deliveries.
That goes into activation systems
which can activate campaigns setups and also audience setups
into the demand side platforms.
And if you don't know what a demand side platform is,
that's the engines that's run by Google, for instance,
to deliver the right campaign to the right person
at the right time for the most impact, all about campaign
performance, right?
So the activation of that information into Google's DSPs,
as we call them, and then data coming back into us
on the campaign execution side that
allows us to understand how we're performing against KPIs
and also being able to do analytical and visualization
work, as well.
So very much a full suite, everything
from data to audiences to campaign planning
to activation, and then the--
let's call it the loopback of data
back into our systems for campaign performance
and analysis.
Large, large data sets on the audience and identity side.
We've got over 2.1 billion profiles
under cover that is unified across third party ID spaces.
We also have high secure systems, as well,
that allow us to bring in consented, secure PII
information.
Of course, that is all undercover,
all secured within our systems.
That allows us to build profiles under those, as well.
Again those that PII information stays inside
of our premise in a high trust kind of environment.
It never gets outside.
But we deal in all sorts of different types of data,
and all the way into event and aggregate data on the campaign
performance side.
But billions of profiles under covers.
It's a global installation across 65-plus countries,
and all on GCP, on Google Cloud.
BRUNO AZIZA: So that's really amazing, a global platform
all the way from audience creation to activation.
Let's talk a little bit about the architecture.
How do you lay out those bricks to create
such a unique global and scalable architecture
for your business?
BOB HAMMOND: Yeah, great question.
And we're in the midst of modernizing this,
to a certain extent.
So when we brought Choreograph together,
we brought, as I mentioned, I think 10 different platforms
to bear in different areas--
audience platforms, campaign planning platforms,
activation platforms, analytical and visualization platforms.
And they all have their own data sets
associated with the application stack themselves, right?
Now what we're doing is bringing all of those data assets
together into a data cloud.
That allows us to, in a cleanroom environment,
or non-cleanroom environment, depending on the data types
that we're working with, bring data into the center
securely in a privacy manner that still allows
us to do the ML and data science work
centrally within our environments
and then power that data up into the application
space for a unified approach across WPP.
So we have individual platforms currently today,
but lots of work going on now to actually unify that
into a central platform.
BRUNO AZIZA: And you lifted this off from a previous system
onto Dataproc and then BigQuery and Bigtable.
Tell us a little bit about that process.
How did that go, and how should people approach that?
BOB HAMMOND: Yeah, no, that's a really good question.
And we're still doing it, actually.
Some of the systems that are part of Choreograph now
that came into us are still on prem, and we're in the midst
now of moving that into GCP, as well.
But we started this journey about 3 and 1/2 years
ago or so, when we had identity platforms that were on prem.
So we had North America, EMEA, APAC, and also
in China, all inside of physical data centers.
And what happened to us is we were in an explosive growth
phase.
We moved from kind of small services, a couple of customers
here and there, doing some really cool stuff.
But all of a sudden, it started to really ramp,
very much like a start up kind of
organization being successful in ramping quick.
What we found is that we just didn't have the flexibility
that we need.
This really wasn't a financial thing for us.
This was much more of an agile thing,
being able to increase capacity, decrease capacity in systems
that were no longer needed, and also
shifting different services and different capacity
around within the environments that we deal with.
If you have a physical infrastructure itself,
it's really, really difficult to do
that because you're bound inside of the machines
that you already have.
And any time my boss comes to me and said,
hey, we've got 5 more customers coming our way, what are you
going to do about it, it takes me 4 to 6 weeks
to actually rack and stack and do OSes and all that good kind
of stuff, right?
So we decided to go ahead and take
a look at the cloud environments to see what we can do.
Now, I'm a little old school.
I've been around doing this for, like, 30 years and so,
so I'm a data center guy, right?
I like physical data centers, and I've always
liked physical data centers.
So I was probably one of the biggest naysayer of all.
But I wanted to have a go at it, so we decided
to go ahead and start out by taking one of our largest
audience systems, which has 2.1 billion profiles undercover,
doing millions of transactions at the front door,
over 30,000 nodes, computers associated with this thing--
so large, large systems out there,
5.2 petabytes of data under covers.
I mean, it was big systems type of stuff.
And we decided to go ahead and lift and shift
this thing into GCP.
So what we decided to do was just
take a look at how many nodes we were running in the data
centers themselves, stand up exactly the same environment
inside of GCP, and give it a go.
So we stood it up.
We installed all the software.
We shifted the-- or actually, we split our data
pipe so that it went into our data centers,
but also into GCP.
We stood everything up, fired it all up, and voila, it worked.
It was pretty awesome, right?
And the reason why it was really, really good
is because of-- well, actually, let me
get to that in just a second.
We stood it up, really awesome, but the cost
was three times more expensive than what
our data center was at the day.
So we kind of took a step back and said,
OK, now we know that the cloud infrastructure works
and it can support us, but we needed
to figure out how to bring the cost under control.
So the first thing that we did is we re-platformed ourselves.
So we moved from highly clusterable third party
applications and services, and we reengineered that
into GCP services.
So this is things like Bigtable, BigQuery, Dataproc, GKE,
GCS, those types of things.
So we got off of Hadoop and went to Dataproc,
those types of things, re-engineered
all of those, reinstalled it all, fired it up,
and it still worked, which was awesome,
and our cost reduced by a third.
So that brought us back into the same territory
as our cost inside of our data centers.
But the most important thing, then-- so then everything
was good.
We fired it all up, and we cut everybody over.
We did the migrations.
We did APAC first, did EMEA second,
then we did North America third, very successful,
moved it all over, decommissioned
the data centers.
And then we did the most important step of all,
is we rightsized it.
So what I mean by that, and one of the reasons
why we picked GCP is GCP gives us
the ability to right size nodes against the requirements
of the application running on the nodes themselves.
So now we can go back in and say,
what exactly is this application consuming
on that particular node?
And we can dial down or dial up CPUs or main memories
or networks without actually having
to replatform that application.
So we rightsized it, and we actually cut our costs in half.
So we walked away after doing the lift and shift,
replatforming, rightsizing.
We actually reduced our costs from our physical data center
in half and still got better performance, much
more flexibility, so it was a great win all the way around.
BRUNO AZIZA: So I think this explanation is actually
a great transition into our next section, which
is best practices.
Obviously people listening to you
know this is not the first time you've done this.
So let's talk more about that.
What is a best practice?
Don't waste a migration sounds to be like one,
but how do you plan about that?
Do you have a different project plan?
Do you bring different types of people?
How do you make sure that you're not
wasting the opportunity of a good migration?
BOB HAMMOND: Yeah, yeah.
So the biggest key in all of this for us
was a really, really tight partnership with Google.
So we had some folks on the ground inside
of our engineering organization from Google
that basically sat next to us while we
figured this whole thing out.
Now, that was key because that allowed us to get
our questions answered quickly.
It's never perfect.
So we had issues here and there, but they
helped us figure things out.
Google engineering was really on us, as well, which was great.
So they helped us work through some issues
and that sort of stuff as we worked our way through.
But at the end of the day, having a really, really tight
partnership to help us move this stuff across and educate
ourselves was really, really paramount.
So we sat down--
and we're also very much we're going to do this ourselves
because at the end of the day, we have to own it,
and we're going to continue to run it ourselves
at the end of the thing.
So we never outsourced it.
We never used any contractors or consultants.
We did all of this stuff ourselves inside
of engineering, inside of QA, inside of technical operations,
network operations centers, all that sort of stuff.
We wanted to do it ourselves, because we
have to own it at the end.
Working really closely with Google, they ramped us quickly.
They educated us.
They solved some problems that we
had that we were trying to work our way through.
We actually were able to stand this thing up together
in partnership, which was great.
And then we worked together to cost reduce this thing
after we had it running.
And a few of us naysayers were convinced
that this thing was actually going
to work at the end of the day.
So the best practice is don't just lift and shift.
You have to re-engineer your platforms
to take the best advantage of the shared services, which
that's where you get the bang of the buck.
And then don't forget to rightsize
at the end of the day.
That's where you really save the money because you
can tune the nodes to the specific application itself
and only pay for what that application really needs
and not any overhead past that, right?
The other thing to remember, also,
is make sure that you have a really good program
around reservations.
And what I mean by that is, once your systems are running,
you really get a good understanding
of your consistency across cores and main memory and networks,
right, so that you can now go in,
reserve a particular capacity across a year.
And that way, you get higher discounts
against your computes, against your CPUs,
against your memories, because you're now reserving
that for a particular year.
So we put a lot of effort into really understanding
what our infrastructure looks like and how it runs on a day
to day basis.
And then we reserve ourselves across that year,
because we know we're going to need that capacity
at the end of the day.
BRUNO AZIZA: And having the ability to customize for that
is really important, too.
BOB HAMMOND: Really important.
BRUNO AZIZA: So let's talk about the opposite of that.
What is the thing that you've seen over the years--
might not be at the current company,
might have been before--
which is a typical mistake people
make that might make sense in the context,
but then, looking back, just slows down
your migration or your modernization project?
BOB HAMMOND: Yeah, no, absolutely.
I think it's two things.
And I have been at companies prior,
other large companies prior that have done this type of thing,
as well.
And I think the mistake that they made
was they only went in half way.
And what I mean by that is, is you have a platform,
and that platform is the platform
that you want to migrate from on prem
into GCP or into the cloud.
And a lot of them picked portions of the platform
but not the entire platform.
I think you really get the bang of the buck
when you can get that whole platform into the cloud itself
because you don't split it between on prem and the cloud,
and then have to pay for transit and coordination
between the individual environments themselves.
Go ahead and select your platform totality,
the ones that are encompassed and enclosed,
and move that entire thing into the cloud.
That way, you can get the advantage
across that complete environment and that complete platform
itself.
The other thing is a lot of folks
just do the lift and shift and they say, OK, I'm done.
I did a great job, pat myself on the back and I'm all done.
But that's only the start of it.
You need to take a look at the architecture
itself and understand what your architecture is
and how you can replatform into the shared services.
As I mentioned before, that's step one.
And then rightsizing is key.
Very few people understand the concept of rightsizing.
And you really need to take that step
to make sure that you get yourself all the way there.
BRUNO AZIZA: Bob, those were amazing points.
Thank you so much for spending the time with us today.
And I hope people are going to reach out to you to talk
to you more about your success.
In fact, to do that, just click on the link down below for more
stories just like this one.
Until next time, I'm Bruno Aziza.
[MUSIC PLAYING]