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

PaaSTA - Yelp's Platform as a Service

Sponsored · Your Podcast. Everywhere. Effortlessly. Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.
Avatar for Rob Johnson Rob Johnson
February 24, 2016
90

PaaSTA - Yelp's Platform as a Service

A talk given at the Docker Dublin meetup February 24 2016

Avatar for Rob Johnson

Rob Johnson

February 24, 2016

Transcript

  1. - Rob Johnson - Operations Team at Yelp - Spend

    most of my time working on PaaSTA. Who Am I:
  2. Yelp’s monolith is ~3 million LoC (that’s just the Python).*

    Increasing number of developers. *as of 28/09/2015
  3. - Statically defined list of hosts to deploy a service

    on. - Operations handle deciding which hosts to deploy to.
  4. - Manually configure Nagios for each service. - Manual deployment

    system. Lots of rsync wrappers to push code around.
  5. We don’t want the operations team to be a blocker

    on the deployments of services. Service authors should be able to self administer their application, describing how it should be deployed.
  6. Configuration is declarative in its nature: it sets expectation of

    what the deployment of a system should look like. The tools we use should automate matching that expectation.
  7. We want configuration to have the same attributes as regular

    code. By storing configuration in a git repository, we get the same benefits we get in a regular project, and can use the same workflows.
  8. robj@dev22-devc:~/yelpsoa-configs (master) $ tree example_service/ example_service/ ├── chronos-mesosstage.yaml ├── deploy.yaml

    ├── marathon-PROD.yaml ├── marathon-STAGE.yaml ├── monitoring.yaml ├── port ├── service.yaml ├── smartstack.yaml └── status_port
  9. robj@dev22-devc:~/yelpsoa-configs (master) $ cat example_service/marathon-PROD.yaml --- canary: cpus: 0.1 deploy_group:

    prod.canary instances: 1 mem: 500 nerve_ns: main main: cpus: 0.1 deploy_group: prod.non_canary instances: 3 mem: 500
  10. Each of our slaves have attributes that describe their environment:

    super region, region, habitat,. By making Mesos aware of these, we can be smarter about how we deploy for higher availability.
  11. Service Authors can now make a decision on the priority

    for their service: - If we discover a ‘bigger’ latency zone, then we’re optimising for availability (all clients in the same latency zone can discover that instance). - If we discover at a ‘smaller’ latency zone, then we’re optimising for latency. (only clients in the same latency zone can discover that instance).
  12. - paasta check http://ascii.yelpcorp.com/a/be5a11 - paasta local-run http://ascii.yelpcorp.com/a/0e3b08 - paasta

    status http://ascii.yelpcorp.com/a/a1b5cf - paasta metastatus http://ascii.yelpcorp.com/a/08a87d
  13. PaaSTA https://github.com/yelp/paasta (Check out the Videos and PaaSTA Principles!) ◦

    Sensu: https://sensuapp.org/ ◦ Mesos: http://mesos.apache.org/ ◦ Marathon: https://mesosphere.github.io/marathon/ ◦ Smartstack: http://nerds.airbnb.com/smartstack-service- discovery-cloud/