The Perfect DevOps Storm

The Perfect DevOps Storm

Organisation, process and technology change at scale.


Paul Gillespie

November 10, 2017


  1. The Perfect DevOps Storm Organisation, Process and Technology Change at

  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” 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. We are hiring!