Software:You Build It You Run It

From HandWiki
Short description: Software development operating model


You Build It You Run It is an Operating model in which product teams build, deploy, operate, and support their own digital services. It is also sometimes referred to as Full Cycle Development[1], Operate What You Build[1] or On Call Developers[2]. It is foundational to DevOps or Agile software development. Originally developed in 2006 by Amazon CTO Werner Vogels, You Build It You Run It was designed to replace the traditional software development operating model with the purpose of creating a positive impact on operability.

Definition

You Build It You Run It is an operability model in software development which creates cross-functional teams, responsible for the development, testing, and production support of digital services[3]. It differs from the traditional model of development[4], where typically one team is responsible for build and deployment, and another for production support.

You Build It You Run It has been foundational to DevOps transformations. Like many DevOps principles, it emphasizes decentralization and autonomy, favoring cross-functional teams owning a solution end-to-end. It means redefining roles, streamlining service management processes, and building a fully automated toolchain from deployment pipeline to incident management.

Designed to break down the invisible wall[5] in software development and bring developers into contact with the day-to-day operation of their software and the customer it was a term coined by Amazon in 2006. During an interview with Amazon CTO Werner Vogels[6], he explained how this new operating model was “...a key enabler in creating teams that can innovate quickly with a strong customer focus. Each service has a team associated with it, and that team is completely responsible for the service—from scoping out the functionality to architecting it, to building it and operating it.”

History

1998 - Werner Vogels joins Amazon[7]. The company had a single US-based website selling only books and running a monolithic C application on five servers, a handful of Berkeley DBs for key/value data, and a relational database. That database was called "ACB" which stood for "Amazon.Com Books," a name that failed to reflect the range of their ambition.

Early 2000s - practices and roles were taking shape in the web-scale (large cloud service) companies. These were organizations that needed to re-think architectures, roles, and processes to support technology at unprecedented scale and speed. The early champions of the movement were Google, Amazon, Netflix, and Etsy.

It was realized that traditional software operating models couldn’t achieve the standards of deployment throughput, service reliability, and learning culture required for digital service management. This has more recently been validated in Forrester’s 2021 report titled ‘The Future of Technology Operations’[8].

Between 2001 and 2009, Amazon transitioned from building monolithic apps with large development teams to building microservice-based apps with their famous “two-pizza teams”[9].

'2006 - the term “You Build It You Run It” was coined in a conversation[7] between Jim Gray and Werner Vogels in ACM Queue. Vogels explained that Amazon should be viewed not just as an online bookstore, and publicly defined Amazon as a technology company. It was heralded that this new operating model resulted in a decrease in software bugs, and a dramatic increase in application stability.

2012 - Netflix recognised that changes in their team structure were needed. They invested significantly in improving the development and operations story for engineering teams and Full Cycle Developers was created[1].

2019 - Despite the impact of Microservices on software quality being mainly rated as positive, a report[10] concludes that applied DevOps practices and automation are still on a mediocre level and only very few companies strictly follow the You Build It You Run It principle.

Implementation

The implementation of You Build It You Run It requires comprehensive changes for people, processes, and technology.

You Build It You Run It is an operating model that is often merged with the subsequent rise of the collaborative DevOps movement[11]. Because of this there are currently no studies available on the adoption of You Build It You Run It, but it often comes within the adoption of DevOps principles in general. Like any big change that could disrupt workflows and surface unforeseen consequences, it makes sense that many organizations are cautious in their approach to decentralization. However in a 2017 Forrester report[12] 63% of organizations said they’d started implementation of DevOps and some form of You Build It You Run It, 27% had plans to look into this and only 1% expressed no interest in making a change.

Benefits

The benefits of You Build It You Run It[13] are there's no hard divide between siloed delivery and operations teams, which removes time-consuming handoffs, and diffusion of responsibility. The product manager is incentivised to constantly balance the prioritization of operational features alongside product features because they're accountable for service reliability. A product team is incentivised to build operability into their digital services because they're on-call out of hours for their own work.

You Build It You Run It has the following advantages at scale[14]:

  • Fast incident resolution
  • Short deployment lead times
  • Minimal knowledge synchronization costs
  • Focus on outcomes
  • Adaptive architecture
  • Product telemetry
  • Situational awareness
  • Fair on-call compensation

Drawbacks

Drawbacks[15] include high setup cost (it can take weeks or months to establish a new, streamlined change management process for digital services) and delays and complications that come with moving change approvals, accountability for production deployments, and creating a new change approval process within an organization. The other challenge is that organizations still need some centralisation. Leadership needs access to reports and documentation and business stakeholders expect updates. They want to see incident metrics like mean time to resolve and mean time to acknowledge. They expect clear incident updates, incident postmortem reports, and remediation work.

Cultural change

Organizational culture is a strong predictor of IT and organizational performance. The You Build It You Run It cultural shift[16] focuses on the small and multidisciplinary team that work independently and take collective accountability of the software product that they are making. Everything the team does is designed to make customer's lives better with experience.

There is also a shift to smaller processes that can fail but can transform the smaller failure into large successes and also build faster processes.

In You Build It You Run It, the team has skills and experience in both development and operations. Developers do not think of roles but think and believe in competencies.

The You Build It You Run It learning culture is predisposed to act on insights. When there is an incident of consequence, the priority for an on-call product team is to acquire a deep understanding of the problem and its resolution, and then broadcast the accumulated knowledge across the organization.

See also

References

  1. 1.0 1.1 1.2 "Full Cycle Developers at Netflix — Operate What You Build". https://netflixtechblog.com/full-cycle-developers-at-netflix-a08c31f83249. 
  2. "Building a Healthy On-Call Culture". https://developers.soundcloud.com/blog/building-a-healthy-on-call-culture. 
  3. "You Build It You Run It Playbook - Introduction". https://you-build-it-you-run-it.playbook.ee/introduction. 
  4. Stoica, Marian; Mircea, Marinela; Ghilic-Micu, Bogdan (December 2013). "Software Development: Agile vs. Traditional". Informatica Economica 17. doi:10.12948/issn14531305/17.4.2013.06. https://www.researchgate.net/publication/269506170_Software_Development_Agile_vs_Traditional. 
  5. "Transform the Invisible Wall (San Francisco 2014)". https://videos.itrevolution.com/watch/524583167/. 
  6. "A Conversation with Werner Vogels". https://queue.acm.org/detail.cfm?id=1142065. 
  7. 7.0 7.1 "A Second Conversation with Werner Vogels". https://dl.acm.org/doi/fullHtml/10.1145/3434571.3434573. 
  8. "The Future Of Technology Operations". https://www.forrester.com/report/The-Future-Of-Technology-Operations/RES154099?objectid=res154099. 
  9. "Two-Pizza Teams". https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/two-pizza-teams.html. 
  10. Bogner, Justus; Fritzsch, Jonas; Wagner, Stefan; Zimmermann, Alfred (March 2019). "Microservices in Industry: Insights into Technologies, Characteristics, and Software Quality". 2019 IEEE International Conference on Software Architecture Companion (ICSA-C). doi:10.1109/ICSA-C46971.2019. https://ieeexplore.ieee.org/abstract/document/8712375. 
  11. "Is ‘you build it, you run it’ living up to the hype?". https://www.atlassian.com/incident-management/devops/you-built-it-you-run-it. 
  12. "2018: The Year Of Enterprise DevOps". https://www.forrester.com/blogs/2018-the-year-of-enterprise-devops/. 
  13. "Benefits of You Build It You Run It". https://you-build-it-you-run-it.playbook.ee/what-is-you-build-it-you-run-it/benefits. 
  14. Smith, Steve. "You Build It You Run It at scale". https://www.stevesmith.tech/blog/you-build-it-you-run-it-at-scale/. 
  15. "Drawbacks of You Build It You Run It". https://you-build-it-you-run-it.playbook.ee/what-is-you-build-it-you-run-it/drawbacks. 
  16. "What is DevOps Culture?". https://staragile.com/blog/devops-culture.