Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

SaltConf14 - Brendan Burns, Google - Management at Google Scale

2,002 views

Published on

As a leading developer of highly scalable, large-scale Web services, Google was forced early on to develop systems to support the deployment and management of diverse workloads at an immense scale. As the broader developer community embraces cloud technologies we see significant parallels between the internal management infrastructure which Google has built over the last decade, and open source management technologies of today. This talk will describe Google's experience in managing large-scale compute services, draw parallels to open source efforts underway today, and sketch out how our past experience shapes our future development of the Google Cloud Platform.

Published in: Technology
  • Be the first to comment

SaltConf14 - Brendan Burns, Google - Management at Google Scale

  1. 1. Google confidential │ Do not distribute Management at Google Scale Converging managed infrastructure between Google and the Cloud community Brendan Burns Staff Software Engineer
  2. 2. Storage Cloud Storage Cloud SQL Cloud Datastore Compute Compute Engine App Engine App Services BigQuery Cloud Endpoints Google Cloud Platform
  3. 3. Google confidential │ Do not distribute For the past 15 years, Google has been building the world’s fastest, most powerful, highest quality cloud infrastructure on the planet. Images by Connie Zhou
  4. 4. We’ve had some practice
  5. 5. Declarative Management for sanity Containers for idempotency and reproducibility So, what have we learned? Task Introspection (or how I learned to forget about SSH)
  6. 6. A view into my life • Google engineer for 6 years • Search Infrastructure (Realtime Search, Google+ Search …) • Cloud Infrastructure • Build software to expect failure • Never had root@gooogle.com, despite web search oncall for 4+ years
  7. 7. Declarative Management for sanity Containers for idempotency and reproducibility So, what have we learned? Task Introspection (or how I learned to forget about SSH)
  8. 8. Imperative management leads to “Snowflake” Servers Declarative Management
  9. 9. Separate textual declaration from Physical (Virtual) Manifestation Declarative Management
  10. 10. Reasoning in a formal declaration (and version control) unlocks tremendous potential Declarative Management
  11. 11. Declarative configurations facilitate re-use Declarative Management
  12. 12. Declarative Management for sanity Containers for idempotency and reproducibility So, what have we learned? Task Introspection (or how I learned to forget about SSH)
  13. 13. Containers
  14. 14. Google has a long history with containers (Process CGroups, LMCTFY [https://github.com/google/lmctfy]) What containers are good for? Containers
  15. 15. Declarative Management for sanity Containers for idempotency and reproducibility So, what have we learned? Task Introspection (or how I learned to forget about SSH)
  16. 16. (or how I learned to forget about SSH) Containers don’t really have SSH (well, they can, but…) Still want containers to be self-contained Introspection
  17. 17. ? ? There’s an exciting road ahead...
  18. 18. Resources/Contact
  19. 19. Thomas Hatch, SaltStack CTO
  20. 20. The Top Six Things You Didn’t Know About SaltStack
  21. 21. 1. Fast, flexible comms protocol • SaltStack provides options • Different solutions for different problems • Flexibility and plug-ability • ØMQ – Super fast • SSH – For certain use cases – 50x faster than other other SSH-based tools • RAET – UDP or TCP – Even faster – More control over job queuing and prioritization – More infrastructure visibility
  22. 22. 2. Salt Virt • Doesn’t get much attention • Salt originally designed as a cloud controller (Butter) • A completely different approach to cloud management – Database free – Evolving but being used in production
  23. 23. 3. Declarative or imperative? Yes. • Stick a fork in this debate • Most flexible configuration management • Finite order execution is a core Salt design principle • 0.17 introduced more state ordering choice • Compiler and run time – Salt modularity – No sacrifice or compromise of speed
  24. 24. 4. Generic device automation • Minion proxy for network devices (Juniper, Arista, Broadcom, F5, etc.) • Not just executing CM routines • Finite device control w/ remote execution • Easy to communicate with and control these typically dumb devices • Stateful configuration and one-off queries • Integrated with standard Salt workflows and methodologies
  25. 25. 5. The Salt test suite • More stable Salt releases • Pedro Algarvio! • Running lives tests constantly on real infra – Jenkins – Spinning up VMs on Rackspace to run tests – Hooked into Docker containers • PyLint coverage (thx Hulu & LogiLab) • Test coverage doubled in three months
  26. 26. 6. The SaltStack name • Not SLC • FLOSS Weekly realization • Gimli, son of Gloin • Ubiquitous nature of Salt
  27. 27. Thank You

×