Upgrade to Pro — share decks privately, control downloads, hide ads and more …

The Two Sides to Google Infrastructure for Everyone Else

The Two Sides to Google Infrastructure for Everyone Else

My talk from Velocity Santa Clara. The format was a debate. Between myself. Looking at the pros and cons around adopting software and practices from other organisations wholesale, using the GIFEE meme as an example.

Gareth Rushgrove

June 22, 2016

More Decks by Gareth Rushgrove

Other Decks in Technology


  1. Taking opposing viewpoints on the same issue, as a way

    of exploring it in-depth Gareth Rushgrove
  2. The talk is split into two parts; a For part

    and an Against part Gareth Rushgrove
  3. I’d like to explore: - Technical practice evolution - How

    we adopt software - The organisational context Gareth Rushgrove
  4. Successful companies will look like Google in the future, so

    we should adopt Google-like software and practices today Gareth Rushgrove
  5. You’re probably: 1 Struggling with distributed systems 2 Missing out

    on machine learning 3 Wondering how to scale operations Gareth Rushgrove
  6. (without introducing more risk) GFS = HDFS BigTable = HBase

    Protocol Buffers = Thrift or Avro (serialization) Stubby = Thrift or Avro (RPC) ColumnIO = Parquet Dremel = Impala Omega = Mesos Blaze = Pants or Buck FlumeJava = Crunch Logsaver = Scribe or Flume Millwheel = Storm or Samza? Borgmon/Monarch = Graphite Dapper = Zipkin 2014 from @avibryant, @joshwills, @skamille, @marius, @wickman Gareth Rushgrove
  7. - Orchestration - Logging - Configuration - Self-healing - Storage

    Gareth Rushgrove - Load balancing - Service discovery - Scaling - Batch workloads - Lots more
  8. - Nearest neighbour - Linear regression - Recurrent neural networks

    - Multilayer perceptron - Lots more Gareth Rushgrove
  9. SRE: Have software engineers do operations Gareth Rushgrove Dan Luu,

    ex Google ” “ http://danluu.com/google-sre-book/
  10. (without introducing more risk) Gareth Rushgrove Dev SRE Ops From

    http://web.devopstopologies.com/ by Matthew Skelton
  11. The unfamiliar: - Error budget - Strong software engineering skills

    - 50% operations work cap Gareth Rushgrove
  12. So much of the information in the SRE book makes

    PERFECT sense if you’re Google Gareth Rushgrove John Vincent, Ops Hero ” “
  13. <1% of US workers are software engineers or programmers Gareth

    Rushgrove US Bureau of Labor Statistics 2002. 1,069,000 jobs in working age population of 185million
  14. Goal of SRE team isn’t zero outages – SRE and

    product devs are incentive aligned to spend the error budget to get maximum feature velocity Gareth Rushgrove Dan Luu, ex Google ” “ http://danluu.com/google-sre-book/
  15. What if you’re operating an air traffic control system or

    a nuclear power station? Your goal is probably closer to zero outages Gareth Rushgrove
  16. bringing a software engineering perspective to a problem isn’t always

    the best or right solution Gareth Rushgrove ” “ John Vincent, Ops Hero
  17. If a human operator needs to touch your system during

    normal operations, you have a bug. The definition of normal changes as your systems grow Gareth Rushgrove Carla Geisser, Google SRE ” “
  18. What is normal for Google may not be suitable for

    your organisation Gareth Rushgrove
  19. Your startup with a single-purpose application does not have the

    luxury of having your operations team say I’m sorry you’re over your error budget Gareth Rushgrove John Vincent, Ops Hero ” “
  20. The technology we run, and how we run it, are

    interlinked Gareth Rushgrove
  21. (without introducing more risk) The field of Sociotechnical Systems suggests

    that all human systems include both a technical system and a social system Gareth Rushgrove https://en.wikipedia.org/wiki/Coevolution#Technological_coevolution
  22. (without introducing more risk) Better outcomes are usually obtained by

    a reciprocal process of joint optimization, through which both the technical system and the social system change Gareth Rushgrove https://en.wikipedia.org/wiki/Coevolution#Technological_coevolution