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

Stop Building Services, Episode I: The Phantom ...

Stop Building Services, Episode I: The Phantom Menace

A 45 minute talk about how to make architecture decisions, and case studies of building services; presented at at ArrrrgCamp 2015

Rachel Myers

October 02, 2015
Tweet

More Decks by Rachel Myers

Other Decks in Programming

Transcript

  1. Monoliths are big Monoliths are hard to change Monoliths don’t

    work for big teams Monoliths make apps slow
  2. Monoliths are big Monoliths are hard to change Monoliths don’t

    work for big teams Monoliths make apps slow Monoliths aren’t web scale
  3. Monoliths are big Monoliths are hard to change Monoliths don’t

    work for big teams Monoliths make apps slow Monoliths aren’t web scale
  4. 1. Make our product more resilient and fault tolerant. 2.

    Encourage understanding, debugging, and changing code. Architecture should:
  5. 1. Make our product more resilient and fault tolerant. 2.

    Encourage understanding, debugging, and changing code. 3. Help teams work together. Architecture should:
  6. 1. Make our product more resilient and fault tolerant. 2.

    Encourage understanding, debugging, and changing code. 3. Help teams work together. Architecture should:
  7. The Ruby # This class encapsulates behavior for hats that

    are for # sale as well as hat samples we might sell. class Hat belongs_to :votable_hat, class_name: :Hat # Public: Adds a Hat to a Cart # Returns the Hat def add_to(cart) … end # Public: Vote for a sample Hat # Returns a Hat def vote_yes(user) … end end
  8. The Ruby # This class encapsulates behavior for hats that

    are for # sale as well as hat samples we might sell. class Hat belongs_to :votable_hat, class_name: :Hat # Public: Adds a Hat to a Cart # Returns the Hat def add_to(cart) … end # Public: Vote for a sample Hat # Returns a Hat def vote_yes(user) … end end
  9. The Ruby # This class encapsulates behavior for hats that

    are for # sale as well as hat samples we might sell. class Hat belongs_to :votable_hat, class_name: :Hat # Public: Adds a Hat to a Cart # Returns the Hat def add_to(cart) … end # Public: Vote for a sample Hat # Returns a Hat def vote_yes(user) … end end
  10. 1. Drew the wrong lines for services; reinforced complexity 2.

    Mixed Service and Library strategies Failures:
  11. 1. Make our product more resilient and fault tolerant. 2.

    Encourage understanding, debugging, and changing code. 3. Help teams work together. Architecture should:
  12. 1. Make our product more resilient and fault tolerant. 2.

    Encourage understanding, debugging, and changing code. 3. Help teams work together. Architecture should:
  13. 1. Make our product more resilient and fault tolerant. 2.

    Encourage understanding, debugging, and changing code. 3. Help teams work together. Architecture should:
  14. 1. Make our product more resilient and fault tolerant. 2.

    Encourage understanding, debugging, and changing code. 3. Help teams work together. Architecture should:
  15. 1. Make our product more resilient and fault tolerant. 2.

    Encourage understanding, debugging, and changing code. 3. Help teams work together. Architecture should:
  16. 1. Make our product more resilient and fault tolerant. 2.

    Encourage understanding, debugging, and changing code. 3. Help teams work together. Architecture should:
  17. class RepositoryController < ApplicationController areas_of_responsibility :repos … end class OrganizationsController

    < ApplicationController areas_of_responsibility :orgs, :abilities … end Team Responsibilities:
  18. Service Service Service Service Best Star Wars Memes Best Star

    Wars Memes Best Star Wars Memes Best Star Wars
  19. Service Service Service Service Best Star Wars Memes Best Star

    Wars Memes Best Star Wars Memes Best Star Wars
  20. 1. Required uniformly redeploying several apps 2. Made it harder

    to change assets 3. Finding source code is tricky Failures:
  21. 1. Make our product more resilient and fault tolerant. 2.

    Encourage understanding, debugging, and changing code. 3. Help teams work together. Architecture should:
  22. 1. Make our product more resilient and fault tolerant. 2.

    Encourage understanding, debugging, and changing code. 3. Help teams work together. Architecture should:
  23. 1. Make our product more resilient and fault tolerant. 2.

    Encourage understanding, debugging, and changing code. 3. Help teams work together. Architecture should:
  24. 1. We should use evidence 2. Criteria to look for

    3. Case Studies 4. Conclusions
  25. 1. Untangle code before trying to extract it 2. Don’t

    create more single points of catastrophic failure How to SOA:
  26. 1. Untangle code before trying to extract it 2. Don’t

    create more single points of catastrophic failure 3. Build together the parts that will need to change togther How to SOA: