MicroservicePatterns.com

Suggestions

  • PagePattern catalogAll patterns by category.
  • LabCircuit Breaker and Retries labCrash a dependency and tune the breaker.
  • LabSaga labFail a step and watch the compensations run.
  • PagePractice questionsScenario questions with explanations.
  • PageDesign reviewCheck your own architecture for anti-patterns.
Teams and ownership · Foundation

You Build It, You Run It

The You Build It, You Run It pattern makes the team that builds a service also responsible for operating it in production, including deployment, monitoring and on-call, instead of handing it to a separate operations team.

Last updated

Use it when

  • Teams own services and want to release independently.
  • Production problems bounce between a development team and an operations team.

Avoid it when

  • The team is too small to share an on-call rotation fairly. Combine services into a larger team first.

Goes with

Stream-Aligned TeamHealth Check APIApplication MetricsService Template
Test yourself

What is the You Build It, You Run It pattern?

There is no handover to an operations team. The team that wrote the code deploys it, defines its dashboards and alerts, and is on call for it. A platform team still runs the shared infrastructure underneath, but each service's behaviour in production belongs to the team that owns it.

What problem does the You Build It, You Run It pattern solve?

When one team builds and another runs, the builders never feel the pain of slow queries, noisy alerts or fragile deploys, and the operators cannot fix the code. Feedback is slow and blame is easy. When the same team does both, operational problems are fixed at the source, and services are designed to be run.

How do you implement the You Build It, You Run It pattern?

  1. Give each service exactly one owning team, recorded in a service catalogue.
  2. Route each service's alerts to its owning team, and give that team its own on-call rotation.
  3. Let the team deploy whenever it chooses, through a pipeline the platform provides.
  4. Make it easy to see a service in production: dashboards, logs and traces come with the template.
  5. Hold blameless reviews after incidents and feed the fixes into the team's own backlog.

When should you use it?

  • Teams own services and want to release independently.
  • Production problems bounce between a development team and an operations team.

When should you avoid it?

  • The team is too small to share an on-call rotation fairly. Combine services into a larger team first.

What do you gain?

  • Operational problems are fixed by the people who can fix them
  • Faster feedback from production
  • Services designed to be operable

What does it cost?

  • On-call load for every product team
  • Teams need operational skills
  • Needs good tooling or it burns people out

What are common mistakes with the You Build It, You Run It pattern?

  • Giving teams the pager without the tools, access or authority to fix what pages them.
  • Services with no clear owner, so their alerts go nowhere.
  • Noisy alerts that wake people for things that do not need a human.

You Build It, You Run It in practice

Real-world example

Amazon

In the traditional model, developers hand finished software over the wall to a separate operations team, which runs it in production and deals with what goes wrong.

In a 2006 ACM Queue interview, Amazon CTO Werner Vogels described doing the opposite and summed it up as "You build it, you run it." He said that giving developers operational responsibility for their services had greatly improved the quality of those services, from both a customer and a technology point of view.

Sources: ACM Queue interview with Werner Vogels (AWS News Blog, 2006); A Conversation with Werner Vogels (ACM Queue, 2006)

Example decision record
Context
Production problems bounce between development and a separate operations team, and fixes take weeks.
Decision
Each team deploys, monitors and is on call for the services it builds, using platform-provided tooling.
Consequences
  • Operational problems are fixed at the source.
  • Teams carry on-call load and need alerts worth waking up for.

Test yourself on You Build It, You Run It

Teams and ownershipfoundation

Developers hand each release to an operations team. When the service slows down at night, operations restarts it, files a ticket, and developers look at it a week later. What change gives the fastest feedback?

2 questions involve this pattern. Practice all of them →

Done with You Build It, You Run It?

Saved in this browser only. See your progress →