2 May 2023

You Build It, You Run It!

Who the hell are you?

Ex:Kayak

VMwareEverbread

Alex PopovSkyscannerSite Engineering Lead, SofiaEstimated Pricing Tribe Lead

nobody reads these…

“You build it, you run it. This brings developers … into day-to-day contact with the customer. This customer feedback loop is essential for improving the quality of the service.”, Werner Vogels, CTO Amazon

Source: ACM Interview with Werner Vogels, June 2006

Not My Problem!

“Bad behavior arises when you abstract people away from the consequences of their actions.”Jez HumbleSource: There is no such thing as “DevOps Team”!

42!

What does YBYR mean?

Engineers are responsible for the full release cycle!

• Definition of requirements (w/ Product)• Code (MVP style)• Data (w/ Data Eng)• Testing and Automation (w/ Test Eng)• Continues Delivery Pipelines (w/ Dev Enablement)• Infrastructure (w/ INFX/Cloud Ops)• Ops/Monitoring/Availability (w/ Dev Ops)

Yes!

PROS:

Faster delivery of features is a highly successful practice!

• Fewer PROD failures• Much faster recovery• Much more frequent releases• Delivery is sustainable• Higher performance• Testing is done at scale and performs far better

Source: State of Dev Ops Report 2015

S**t!

CONS:

There is no silver bullet!

• It is a Culture thing• Requires a change in ‘mind set’ across the organization• No ‘one size fits all’• Depends on the context and the environment• Requires a sync between leadership/process/organization• Works best if everyone is following the practices behind it• Disrupts delivery

We Know What Works

The Goal:

• Release as fast as possible the new features you produce• A commit should end up on PROD in minutes

• What is released should fail rarely• The system should not allow bad code to propagate to PROD

• When something fails, recovery should be fast (automated)• Monitoring is key. Automated reaction to a failure is a must

• Testing should be fully automated• No team of testers can scale to cover all that needs to be

covered. Manual testing cripples CD and fast releases• Whether a release stays, or is reverted, should be automated• Decisions should be data driven. Blue/Green deployments

• The right metrics are the key. Store as much data as possible and use it to automate all steps in a release cycle

No Silver Bullet!

The How:

• Everyone knows what works. Nobody has it perfect.• Depends on context/business/environment.• Remove all non software engineering roles? ‘ You f**ing nuts?• Frameworks/tooling are the key.• Focussed specialists should coach, not do.• Possible but not easy.• Not being perfect is no blocker.

Hmmm…

So shall we do it?

• Absolutely!• It will be hard.• It will take time.• It will make things worse before they get better.• Once in place, you can grow exponentially.

Thank you!Follow us: @codevoyagershttp://www.codevoyagers.comhttp://www.skyscanner.net

Mail: Alex.Popov@Skyscanner.net@long404