×
Copy
Open
Link
Embed
Share
Beginning
This slide
Copy link URL
Copy link URL
Copy iframe embed code
Copy iframe embed code
Copy javascript embed code
Copy javascript embed code
Share
Tweet
Share
Tweet
Slide 1
Slide 1 text
Taking Django Distributed Andrew Godwin @andrewgodwin Taking Django Distributed
Slide 2
Slide 2 text
Hi, I’m Andrew Godwin • Django core developer • Senior Software Engineer at • Needs to stop running towards code on fire
Slide 3
Slide 3 text
Computers hate you.
Slide 4
Slide 4 text
This makes distributed hard.
Slide 5
Slide 5 text
2001: A Space Odyssey Copyright Warner Brothers
Slide 6
Slide 6 text
It’s time to split things up a bit. But how? And why?
Slide 7
Slide 7 text
Code Databases Team
Slide 8
Slide 8 text
There is no one solution
Slide 9
Slide 9 text
Read-heavy? Write-heavy? Spiky? Predictable? Chatty?
Slide 10
Slide 10 text
Code
Slide 11
Slide 11 text
Use apps! They’re a good start! Ignore the way I wrote code for the first 5 years of Django.
Slide 12
Slide 12 text
Formalise interfaces between apps Preferably in an RPC style
Slide 13
Slide 13 text
Split along those interfaces Into separate processes, or machines
Slide 14
Slide 14 text
Inventory Payments Presentation
Slide 15
Slide 15 text
How do you communicate? HTTP? Channels? Smoke signals?
Slide 16
Slide 16 text
No content
Slide 17
Slide 17 text
No content
Slide 18
Slide 18 text
No content
Slide 19
Slide 19 text
No content
Slide 20
Slide 20 text
Databases
Slide 21
Slide 21 text
Users Vertically Partitioned Database Images Comments
Slide 22
Slide 22 text
Main DB Replica Replica Replica Single main database with replication
Slide 23
Slide 23 text
Partition Tolerant Available Consistent
Slide 24
Slide 24 text
Non-consistency is everywhere It’s sneaky like that
Slide 25
Slide 25 text
National Museum of American History
Slide 26
Slide 26 text
Load Balancing
Slide 27
Slide 27 text
Equally balanced servers Consistent load times Similar users
Slide 28
Slide 28 text
Split logic Different processor loads Wildly varying users
Slide 29
Slide 29 text
Reqs Time
Slide 30
Slide 30 text
Reqs Time
Slide 31
Slide 31 text
W E B S O C K E T S
Slide 32
Slide 32 text
W E B S O C K E T S ● They can last for hours ● There’s not many tools that handle them ● They have 4 different kinds of failure
Slide 33
Slide 33 text
Design for failure, and then use it! Kill off sockets early and often.
Slide 34
Slide 34 text
Team
Slide 35
Slide 35 text
Developers are people too! They need time and interesting things
Slide 36
Slide 36 text
Technical debt can be poisonous But you need a little bit to compete
Slide 37
Slide 37 text
Single repo? Multiple repos? Each has distinct advantages.
Slide 38
Slide 38 text
Teams per service? Split responsibility? Do you split ops/QA across teams too?
Slide 39
Slide 39 text
Ownership gaps They’re very hard to see.
Slide 40
Slide 40 text
Strategies
Slide 41
Slide 41 text
Don’t go too micro on those services It’s easier in the short term, but will confuse you in the long term.
Slide 42
Slide 42 text
Communicate over a service bus Preferably Channels, but you get to choose.
Slide 43
Slide 43 text
Work out where to allow old data Build in deliberate caching or read only modes
Slide 44
Slide 44 text
Design for future sharding Route everything through one model or set of functions
Slide 45
Slide 45 text
Expect long-polls/sockets to die Design for load every time, and treat as a happy optimisation
Slide 46
Slide 46 text
Independent, full-stack teams From ops to frontend, per major service
Slide 47
Slide 47 text
Architect as a part-time position You need some, but not in an ivory tower
Slide 48
Slide 48 text
2001: A Space Odyssey Copyright Warner Brothers
Slide 49
Slide 49 text
Maybe, just maybe, keep that monolith A well maintained and separated one beats bad distributed
Slide 50
Slide 50 text
Thanks. Andrew Godwin @andrewgodwin aeracode.org