Upgrade to Pro — share decks privately, control downloads, hide ads and more …

How New Relic builds software: a biological approach to architecture

How New Relic builds software: a biological approach to architecture

When building resilient, fault-tolerant, scalable systems, we focus quite a bit on the particular technologies involved. Can it scale horizontally? Is Samza better than Storm? Is this library thread-safe? It turns out that, even though those questions matter to the stability of the system, they don’t matter as much as the people building the system. Humans choose the stack, write the code, and write the bugs, too. They create the weird edge cases that cause the system to fall over at the worst time.

At New Relic we’ve taken an unusual approach to building software: we draw heavily from biological metaphors like mutation and natural selection, and focus on a human-centric approach to define our architecture. Rather than trust a few armchair architects to make the decisions, we put the power in the hands of the teams wrestling with the code. We have many strategies to ensure cohesiveness across the architecture and scalability for the business, the engineering organization, and the software, but it takes a little leap of faith and a lot of trust to move to a process like ours.

I’ll share how our process works, and how we manage the growth without going off the rails, while increasing system stability.

Delivered to the European Broadcasting Union DevCon15.

Brent Miller

October 07, 2015
Tweet

More Decks by Brent Miller

Other Decks in Programming

Transcript

  1. HOW NEW RELIC BUILDS SOFTWARE: A BIOLOGICAL APPROACH TO ARCHITECTURE

    Brent Miller
 Principal Software Engineer & Architect
  2. @foliosus bit.ly/nr-architecture-evolution “A single conversation with a wise man is

    better than 10 years of study.” 與君一席談,勝讀十年書
  3. @foliosus bit.ly/nr-architecture-evolution TEAM ORGANIZATION 1. Assigned architects for each team

    2. An anchor engineer on each team 3. Quarterly state-of-the-world meeting
  4. @foliosus bit.ly/nr-architecture-evolution PROCESS 1. Assigned architects for each team 2.

    Anchor engineer on each team 3. Quarterly state-of-the-world meeting with each team 4. Architects are technical product managers 5. All projects need architect sign-off 6. Public record of decisions 7. Public, consultative decision making 8. Daily office hours 9. Experiments
  5. @foliosus bit.ly/nr-architecture-evolution PROCESS 1. Assigned architects for each team 2.

    Anchor engineer on each team 3. Quarterly state-of-the-world meeting with each team 4. Architects are technical product managers 5. All projects need architect sign-off 6. Public record of decisions 7. Public, consultative decision making 8. Daily office hours 9. Experiments