The Perfect DevOps Storm

Organisation, process and technology change at scale.

Transcript

1. The Perfect DevOps Storm Organisation, Process and Technology Change at Scale
2. About Me Paul Gillespie (@bigpg) Senior Principle Engineer Developer Enablement Tribe Lead at: A global travel search site Founded in 2003 in Edinburgh Serving over 60M travellers a month
3. Some Terminology Squad The atoms of our organisational structure. An autonomous team with a clear mission and specific goals. E.g. Web Infrastructure or Flying Pandas. Tribe A grouping of aligned squads with a common mission and high level goals aligning to company strategy. E.g. Developer Enablement, Market Place Engine, Central Growth Enablement The process of providing services/tools/processes to support product engineering, growth, commercial activities and employees at Skyscanner
4. What is the perfect DevOps storm? The convergence of a large number of changes impacting organisational structure, delivery/operational processes and technologies in a comparatively short period of time
5. But why… Software Delivery Process (we want this to be fast) In many cases these changes have been to increase our speed of execution Product Engineering Squads Travellers Product Feedback
6. Change timeline at Skyscanner 12 major changes to organisation, process and technology from late 2013 through to the present Doesn’t include changes to product features, how our users use Skyscanner (e.g. shift to mobile), industry trends, etc
7. 2014 #1 Moving to Continuous Delivery (started in 2013) #2 Pivoting to Open Source Languages and Tooling #3 Squadification #4 Log all the things A busy year for changes and includes the biggie which was squadification…
8. 2015 #5 Betting on the cloud (AWS) #6 Experiment backed product development Its looks like it was a quiet year…
9. 2016 #7 The age of enablement #8 Micro-services become the new old thing #9 10K deploys a day #10 You build it, you run it Back to our normal rate of change…
10. 2017 #11 On sh*t we are building Distributed Cloud Native Services and we need a better environment for our micro-services # 12 Principles and Standards Oh yeah time for some bleeding edge tech!
11. Lessons Learnt A non-exhaustive list of things we wish we had known over the last couple of years Your mileage may vary…
12. Organisation #1 Your organisational structure is an artificial construct It needs to evolve and adapt and is most definitely not static #2 “With great power comes great responsibility” – Uncle Ben “Autonomy without accountability is just vacation” – Kent Beck
13. Organisation #3 Autonomy != Ability #4 Dedicated enablement squads/tribes for the win Developer Enablement Tribe Central Growth Tribe Data Tribe Employee Enablement Tribe Internal Growth Tribe …
14. Organisation #5 Change Fatigue is a very real problem It is very easy to inflict un-intended technical debt on a large number of squads #6 Continuous improvement is a core competency for everyone Journeys not destinations
15. Organisation #7 If you build it they will come…maybe It is very easy in enablement to think you know best as you were once your customer #8 You build it, you run it, you most definitely own it But you don’t need to operate everything in your production stack
16. Process #9 Engineering standards are an enabler No matter what XKCD says... #10 It is better to be restrictive at first (for standards) It is easier to give than to take away… “Embrace constraints” https://gettingreal.37signals.com An example micro-service production standard (“All” refers to our service classification scheme)
17. Process #11 Measure what you preach Tracking adoption of enablement processes, services and standards #12 Internal open-source scales delivery There will always be some feature that requires changes outside of the originating squad’s services
18. #13 Codify your standards for successful adoption The best standards are the ones that you get for free J Technology Logging Metrics Cred Management Healthchecks Testing Tracing Service Logic Product … “Mshell” lets squads create new services quickly at Skyscanner and follows the “Iceberg” design principle
19. #14 Micro-services are not an excuse… To write another book… or pad your CV… or get a speaking gig J Technology
20. Technology #15 Not all the technologies please Less is sometimes more… Some of the technologies in use at Skyscanner in 2016 WTF!
21. Wrapping up Yes we have weathered the DevOps Storm! Continuous improvement is a journey not a destination Use your autonomy responsibly and think about your customers Think about the standards you would like to see adopted Invest in enablement as earlier as you possibly can Change is the only constant so learn to work with it
22. https://www.skyscanner.net/jobs/ We are hiring!