I attended YOW! Sydney 2014 and thought some people might get something useful out of my notes. These aren’t my complete reinterpretations of every slide, but just things I jotted down that I thought were interesting enough to remember or look into further.

Beth Skurrie (@bethesque) from DiUS, Evan Bottcher (@evanbottcher) from Thoughtworks and Jon Eaves (@joneaves) from REA group spoke about migrating realestate.com.au to a microservices architecture. (Slides, Video)

Why REA migrated to microservices

They started by talking about why they started doing microservices:

They had a long release cycle,
they were doing coupled releases,
with coupled rollbacks,
and they had a long defect fix time.

How do you get self-empowered teams to change the whole architecture?

However, there was a realisation that changing things at REA is a bit hard, partly because the teams are very self-empowered, they’re trusted, and they value their independence.

In order to convince teams that trying a new architecture was a good idea, they came up with a vision of where they wanted to go, which included:

rapid deployment
fault tolerant systems
discoverable services
independent services (otherwise you’re back to deploying everything!)

The “microservices” term was just coming into vogue and seemed to align with their goals, but it wasn’t entirely clear to them what it was.
They defined their plan for how they would divide their systems into services:

Narrow responsibility for each service.
Small codebase. Not measured in lines of code, but in terms of “design compactness”. Their metric: a service should be able to be re-written from scratch and deployed in 2 weeks.
There is no #3

In order to communicate the vision across the team, they documented their strategic goals, archictural principles and design and delivery practices.

They made sure they followed Martin Fowler’s First Law of Distributed Object Design: “Don’t distribute your objects.”

Embedded Ops + Microservices at REA

They were already in the middle of decentralising the Operations team to embed them into development teams. However, access to Production was still ‘all or nothing’, and that didn’t fit with the way responsibilities were being carved up. So, they sectioned off part of production for each team so that the team could have access to Production, but only their bit, resulting in “team-managed infrastructure”.

Teams live by the mantra:

If you build it, you support it.

They found it was taking significant time to create new services, so they created a template project that could be cloned to start new services. They didn’t start from scratch to write this template, but created it based off existing, well-functioning services.

Microservices + Integration Testing Pain

Integration testing became a huge pain point. They did a 5 Whys on themselves and asked:
What is the value of integration testing? Why are we doing it? -> to find bugs
why? -> because consequences in production are high
why? -> because it takes time to fix things in production
why? -> because we don’t know about the bug for a while
why? -> because we’re not monitoring the right things
… or because communication between teams isn’t working
… or because the cause isn’t known

They decided it’s much easier for the Ops people to monitor the business functions of the software when the Ops people are Dev people, embedded in the Dev team. (They still have a team called ‘Delivery Engineering’, but they aim to remove hurdles, not do deployments.)

With all that, they threw away integration tests.

Instead, they had service-level tests with mocks, but they were aware that mocks often make assumptions about how the mocked side works. To have a safe test, you need to check that those assumptions are correct, which leads to “test symmetry”: one test that makes assumptions, and another that tests the assumptions themselves. Test symmetry could be maintained manually, but that’s open to human error. Hence, they ended up inventing pact, a ruby tool for ensuring test symmetry with consumer-driven contract testing.

Challenges with Microservices at REA

Some of the challenges they’ve encountered during this journey were:

Sharing things is hard.
Sharing is a form of coupling. (GL: I would say “can be”, not “is”)
They think about themselves in squads, tribes and whole team (similar to Spotify?), and are wary of sharing things across those boundaries.
They tried something called “Service Custodianship” (I assume they were referring to using the open source custodian model for teams wokring across boundaries) and found it hard to achieve.

Final Word: Use With Care

They left everyone with a note of caution: Microservices are extremely fashionable. It is a fantastic long-term strategy for a large organisation, but it’s not the solution for a 3 month project.