Little Important Things in Distributed Architectures by Andres Jaan Tack

Transcript

1. Little Important Things
 in Distributed Architectures Early decisions that help us delight our users. Andres Jaan Tack Riga Dev Day 2016
2. About Me • Born around Chicago, Illinois, U.S.A. • Studied Computer Science
 Specialized in Operating Systems, Concurrent Systems
 University of Illinois at Urbana-Champaign, B.S.
 University of Wisconsin–Madison, M.S. (Michael Swift) • June, 2010: Moved to Estonia, joined Skype
 Developed infrastructure for Skype-to-Skype and Skype-to-PSTN call signaling.
 Participated in migrating Skype’s support infrastructure to the cloud. • April, 2015: Joined Twilio
 as a Tech Lead
3. About Twilio • We provide cloud-based communication APIs
 We provide the engine,
 you provide the experience. • Developer-Focused
 Developers make business decisions; we can help! • >500 Employees worldwide • Cloud-Native, Global
 Easy to manage, pay-as-you-go, works with existing infrastructure.
4. About our Team in Tallinn We build distributed IP communications software.
 (specifically):
5. About You Yes, you!
6. I claim that You Are Building a
 Distributed System
7. Because what is a distributed system? (Besides terrifying.)
8. 
 “A collection of
 independent computers
 that appear to its users as a
 single coherent system”

9. But I build _____!
 
 Surely, I’m not…
10. I am a 
 server
11. the illusion of a single,
 coherent system.
12. The distributed nature
 of our applications is
 driven by the features
 our customers love and demand!

13. Features we demand: “Liveness” When the state or the data changes, we want to see it: • Quickly • Efficiently
 (weak wifi?) • Automatically
 (push, not pull!)
14. How embarrassing…
15. Features we demand: “Offline Mode”
16. Not really chat-specific. • “Notification” of new data or signals. • Ability to work on data offline. • Sharing your status with others. • Pushing many data through a small pipe.
17. The core connecting thread… Live data.
18. Data. Which is… that is concurrently represented and manipulated on multiple clients. VJCVCTGRTQDCDN[OQDKNG @
19. How to manage live data sustainably. Little decisions now make a huge difference later.
20. use continuous natural numbers for ordering data. Don’t insertAt(2, ) insertAt(2, ) insertAt(2, ) insertAt(2, ) Alex Bob insertAt(2, ) insertAt(2, ) !!
21. use continuous natural numbers for ordering data. use them for gap detection, if you need to do so. Don’t ✔ Do Voilá, thing #1. Voilá, thing #3. Wait, what about #2?
22. build total orderings. Don’t This is certainly an order, but is it really the only reasonable one?
23. build total orderings. Don’t Total ordering is unnecessarily strict. 1. Wake up. (A beautiful new day!) 2. Turn off alarm. (Boy I’m hungry!) 3. Proceed to bathroom. (Ah come on…!) 4. Brush teeth. (So. Hungry.) 5. Take shower. (This is stupid.) 6. Get dressed. (Is soap edible?) 7. Proceed to kitchen. (Oh thank god.) 8. Eat something. (!!!) 9. Walk out front door. (Hmm, brush teeth again?)
24. build total orderings. Don’t In Data-centric Systems, total orderings mean retries for no good reason. Can I be after blue? Nope, yellow was faster. Nope, red has better internet. What about after yellow? After Red? …
25. build total orderings. Don’t build partial orderings. ✔ Do ✔
26. Karl O’Livvy: Should we show them how we make the sausage? Michelle: Absolutely not! Inappropriate. Danielle: No! But what will I show my users?
 Graphs are too complex! Data != Representation
27. You can always form a Total Ordering from a Partial Ordering! Timestamps! Random GUIDs! Karl O’Livvy: Should we show them how we make the sausage? Michelle: Absolutely not! Inappropriate. Danielle: No! 0x789 0x123 0x234 ≼ Karl O’Livvy: Should we show them how we make the sausage? Michelle: Absolutely not! Inappropriate. Danielle: No! 12:00.50 12:01.12 12:01.13 ≼
28. delete things. Don’t ✔ Do mark things deleted. QTCVNGCUVPQVGCIGTN[ @
29. ✔ Do mark things deleted. That’s information! • History of actions taken • Record of possible alternative intent • Opportunity to retrospectively
 re-interpret and recover.
30. ✔ Do mark things deleted. • History of actions taken • Record of possible alternative intent • Opportunity to retrospectively
 re-interpret and recover. And these things generally don’t cost much!
31. We need to be focused on Value.
32. ✔ Do use natural numbers for gap detection, not data order. ✔ Do build partial orders, not total orders. ✔ Do mark as deleted, i.e.
 manipulate data monotonically.
33. We need to be focused on Value.
34. We need to be focused on Delighting our users.
35. Andres Jaan Tack Tech Lead Twilio, Inc. Tallinn, Estonia