Project Bedrock, A New Foundation For The Future

In November 2019 Zoopla kicked off a huge programme of work that involved most of our Product and Technology department. That programme led to fundamental changes to how Zoopla.co.uk works and how the teams that build it operate. This is the highly summarised story of that programme.

Prior to Autumn 2019 Zoopla’s Product and Technology department was largely organised around the projects being tackled at the time. Work had recently been completed that enabled the team to start building new products in Javascript. This allowed Zoopla to grow it’s Javascript capability and a raft of new products were built. While that project achieved significant success it soon became clear that it still took too long to build new products. Experimentation was complicated and relied on custom tooling and some out-of-band coordination and management.

These were the conditions that led to the programme known as Bedrock. Bedrock was officially launched at a Town hall event in November 2019 where it was announced that some new teams would be forming to address the following issues:

• Simplifying contributing to and deploying Zoopla’s portals
• Continuing the migration of workloads from EC2 to ECS
• Building a new rendering stack including integration of a new headless CMS stack and a new multi-variate testing tool
• Decoupling front-end and back-end development
• Enable rapid new development for search-based scenarios

The Product and Technology leadership team had some experience with re-platforming, modernisation and microservice migrations. We’d also read a lot of other companies' experiences of modernising their technology stack. There seemed to be a theme - re-platforming was commonly a multi-year journey that might never actually complete.

So rather than focusing on refactoring, decomposing or strangling our old technology stack it was decided instead to focus on the developer experience, and set out to build a simple, modern, technology stack that did everything a software engineer expected it should. We would focus on making it easy to work on and change. If we were unsure we would follow the Principle of Least Astonishment.

I’ll list some of the technology we’ve implemented but don’t expect any surprises (see the point above). The web application is React with Next.js. It deploys to AWS ECS, our SCM is an on-premise implementation of Gitlab and so we use Gitlab CI to deploy. We configure our infrastructure with Terraform. We love the tech we’ve chosen. It's easy to work with, if an engineer gets stuck they can search for solutions online, and of course we’ve got our internal slack channels for specific questions such as about failing tests or why certain choices were made.

The first major change we released which was built on our new stack was the search page. The new page brought together capabilities from the mobile web and desktop pages into a single solution, with very few other changes. Even so, the page built on our new tech stack improved our bounce rates and conversion rates and increased the amount of time customers spent using the page so it was a win for our engineers and our customers.

Since we migrated our first pages to the new stack at the end of last year we’ve been feverishly migrating capabilities over to it. All the high traffic pages, where we’ll benefit most from experimentation, are migrated now. Speaking of experimentation we chose and implemented Optimizely, and we now have multiple experiments running at any one time - something that would have been impossible before. Just being able to easily configure, run and learn from experiments has driven huge improvements in engagement.

The final component of the new stack is Contentful CMS, it’s implemented and the most important articles have been migrated over to it but we haven’t even begun to scratch the surface of Contentful’s capabilities yet.

It used to take between 3 and 14 days to onboard new engineers with the old tech stack, it’s now common for new engineers to make useful commits on their first or second day at Zoopla.

Rather than tackle refactoring a monolith or trying to strangle out services we decided to focus on the developer experience of building new products. This allowed us to show results more quickly and improve the portal while also reducing the cognitive burden on engineers which in turn allows them to innovate the next generation of products.

[Post image by Ivan Bandura on Unsplash]