Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.
LEARNING TO BUILD
DISTRIBUTED SYSTEMS
THE HARD WAY
@iconara
NEW
and improved!
LEARNING TO BUILD
DISTRIBUTED SYSTEMS
THE HARD WAY
@iconara
NEW
and improved!
speakerdeck.com/iconara
Theo / @iconara
chief architect at BURT
FAILURE
embrace it
SCALE
how hard can it be? let’s worry about that later.
KNOW YOUR LIMITS
who’s the largest customer you could sign?
what would happen if you did?
BALANCE
“customer” is a really bad shard key,
find something that distributes evenly & uniformly
SCALE OUT, NOT UP
bigger boxes aren’t going to save you
<
START WITH TWO
OF EVERYTHING
going from one to two is the hardest,
force yourself to solve the scaling problem up front
START WITH TWO
OF EVERYTHING
you’ll solve the scaling problem,
and need less overcapacity
THREE
LIMITS
we’ll probably never run out of memory
BACK PRESSURE
what happens when the system is working at full
capacity? what happens next?
PRODUCTION = QA
production is where the weird shit happens,
can you test production traffic without
deploying to production...
MONOLITHS
running all the things on the same box is really fast.
what could ever go wrong?
1:4:9
DECOUPLE
UNTIL IT BREAKS
moving things to separate services means that you
will be able to scale them independently
PROCESSING
& STORAGE
separate processing from storage,
they almost never scale together.
SCALE
exponential scaling is also scaling,
but you want it as cheaply as possible
SCALE
your CFO may not agree that O(2n) = O(n)
GÖTEBORG,
DISTRIBUTED
@gbgdistr
meetup.com/gbgdistributed
KTHXBAI
@iconara
github.com/iconara
architecturalatrocities.com
burtcorp.com
Prochain SlideShare
Chargement dans…5
×

Learning to build distributed systems the hard way

584 vues

Publié le

Scandinavian Developer Conference 2013

Publié dans : Technologie
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Learning to build distributed systems the hard way

  1. 1. LEARNING TO BUILD DISTRIBUTED SYSTEMS THE HARD WAY @iconara NEW and improved!
  2. 2. LEARNING TO BUILD DISTRIBUTED SYSTEMS THE HARD WAY @iconara NEW and improved!
  3. 3. speakerdeck.com/iconara
  4. 4. Theo / @iconara
  5. 5. chief architect at BURT
  6. 6. FAILURE embrace it
  7. 7. SCALE how hard can it be? let’s worry about that later.
  8. 8. KNOW YOUR LIMITS who’s the largest customer you could sign? what would happen if you did?
  9. 9. BALANCE “customer” is a really bad shard key, find something that distributes evenly & uniformly
  10. 10. SCALE OUT, NOT UP bigger boxes aren’t going to save you <
  11. 11. START WITH TWO OF EVERYTHING going from one to two is the hardest, force yourself to solve the scaling problem up front
  12. 12. START WITH TWO OF EVERYTHING you’ll solve the scaling problem, and need less overcapacity THREE
  13. 13. LIMITS we’ll probably never run out of memory
  14. 14. BACK PRESSURE what happens when the system is working at full capacity? what happens next?
  15. 15. PRODUCTION = QA production is where the weird shit happens, can you test production traffic without deploying to production? =
  16. 16. MONOLITHS running all the things on the same box is really fast. what could ever go wrong? 1:4:9
  17. 17. DECOUPLE UNTIL IT BREAKS moving things to separate services means that you will be able to scale them independently
  18. 18. PROCESSING & STORAGE separate processing from storage, they almost never scale together.
  19. 19. SCALE exponential scaling is also scaling, but you want it as cheaply as possible
  20. 20. SCALE your CFO may not agree that O(2n) = O(n)
  21. 21. GÖTEBORG, DISTRIBUTED @gbgdistr meetup.com/gbgdistributed
  22. 22. KTHXBAI @iconara github.com/iconara architecturalatrocities.com burtcorp.com

×