An Introduction to Yelp's SOA Infrastructure

Video: https://vimeo.com/141231345

In this intro talk, I describe Yelp's "SOA Configs", a git repo containing the metadata to describe all of Yelp's internal services, and explain why it works so well for us.

Transcript

1. Yelp is (always) hiring! Talk to a Speaker or Recruiter if interested! Obligatory Welcome Slide! SF Devops Meetup Organizers Thank You!
2. Yelp’s Mission: Connecting people with great local businesses.
3. A Behind the Scenes Tour of Yelp's SOA Architecture
4. What Are We Going To Talk About? • YelpSOA Configs - linchpin of our stuff • Service Discovery (Smartstack)+ Docker • Mesos-based Deployment (PaaSTA) • Dynamic Monitoring (Sensu)
5. First - Terminology • Services ~= “microservices?” ◦ I don’t care how small your services are. • SOA == Service Oriented Architecture ◦ Opposite of a monolithic app architecture. Usually accompanied with teams (reverse Conway’s law?)
6. Yelp’s Architecture • Still has a significant amount of code in the monolith ◦ it “pays the bills” ◦ Treated mostly like any other service • Still though, lots of teams, lots of services ◦ Years of pushing for “the SOA dream”? • In AWS and Datacenter in 3 “super” regions (yes, hybrid) • We think we have some good “behind the scenes ideas”
7. What Would I Do If I Did It Again? 1. Have an idea 2. Make a git repo
8. YelpSOA Configs: The Big Idea • Let’s just use config files to be the source of truth about what our SOA infrastructure looks like instead of being in databases, zookeeper, or just from “whoever ran the deploy command last” • Be declarative instead of imperative • “Just a git repo”
9. YelpSOA Configs: Things We WON'T do • Let’s try not to be implementation specific • Let’s try not to do service discovery • No secrets in the config • All configs in one repo, no dev/prod split
10. Architecture: Good Ol Rsync + Cron Plain-ole git repo Normal Commits Rsync Pulls Machine generated files added Read-Only Slaves Most Servers At Yelp Most Servers At Yelp Most Servers At Yelp Read-Only Slaves Read-Only Slaves Most Servers At Yelp
11. Architecture: Mostly Doesn’t Matter • Git repo - Works fine • Gitolite for ACLs - Sure • Pre-receive hooks for validation - Cool • Cron Jobs to Deploy the Git repo - What else? • Rsync Fanout to distribute the files - Heh, fine • Yelp Puppet-Cron makes this easy and high- frequency: https://github.com/Yelp/puppet-cron
12. Demo: Seeing == Believing What does it look like when you have your services metadata in an easy-to-reach place?
13. Example Ideas of Things to Put In There • team data (ownership) • general service metadata (what is it?) • monitoring data (who should get alerts?) • deployments data (where should it run?) • routing data (where should it be advertised?)
14. Conclusion / Big Ideas • Every team has people with enough privileges to edit them • They are configs about the services, not for the services (they don’t exist in the code repo) • Super fast deployment. No code, only config. • Describe the concepts, not the implementation • Build the metadata and the tools will follow!
15. A. To describe how cool Yelp's SOA configs are B. To persuade viewers buy Yelp’s SOA configs enterprise product offering C. To Inspire viewers to build their own SOA configs - based on some of these ideas presented D. To bore viewers about how Yelp rsyncs YAML files around with cron jobs. Reading Comprehension Question: (what is the purpose of this talk?)
16. A. To describe how cool Yelp's SOA configs are B. To persuade viewers buy Yelp’s SOA configs enterprise product offering C. To Inspire viewers to build their own SOA configs - based on some of these ideas presented D. To bore viewers about how Yelp rsyncs YAML files around with cron jobs. Reading Comprehension Question: (what is the purpose of this talk?)
17. • Helps puppet-cron type for high-frequency crons: https://github.com/Yelp/puppet-cron • Gitolite for ACLS and hooks: http://gitolite.com/ • rsync + cron Tools used:
18. Questions