Learning to Build Distributed Systems the Hard Way

Scandinavian Developer Conference 2013

Transcript

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