Distributed Systems Introduction

Delivered at Campaign Monitor Dev Camp 2014. A very brief introduction to a very broad topic.

Transcript

1. DISTRIBUTED SYSTEMS INTRODUCTION Dev Camp 2014
2. SCIENCE! ▸ 10 years ▸ 16 billion kilometres ▸ 510 million kilometres from Earth ▸ 65000 kilometres per our ... and the Rosetta spacecraft's Philae lander touched down on comet 67P/C-G this morning
3. MARK "MARK I" LANGSWORTH Militant pedant, janitor and soapbox aficiando Also a developer on Team Argonauts
4. DISTRIBUTED SYSTEMS A distributed system is a software system in which components located on networked computers communicate and coordinate their actions by passing messages. The components interact with each other in order to achieve a common goal. -- Andrews (2000). Dolev (2000). Ghosh (2007)
5. ▸ Many components ▸ Network messaging ▸ Collaboration towards a common goal
6. SYSTEMS ARE not APPLICATIONS We're taught to be application developers with an application mindset Remember your first programming lecture at school...
7. IF YOU THINK LIKE AN application developer ▸ The system is atomic ▸ The system is finished ▸ Business logic is centralised ▸ The network doesn't matter
8. OUR AIM 1. Logical separation, facilitating physical separation. 2. Separation allows fault tolerance and scale. Contention kills both. So how do we group and delineate our components? Services thinking!
9. SERVICES HINT: THEY'RE NOT JUST A BUNCH OF COMPONENTS
10. TENANTS OF A service ▸ Autonomous ▸ Explicit boundaries ▸ Expose schema and contract ▸ Compatibility is determined by policy
11. VERTICAL PARTITIONING rules ▸ Along lines of business volatiliy ▸ Data lives in proper "islands of consistency" Follow the data
12. MORE VERTICAL PARTITIONING rules ▸ If messages are big, boundaries are likely wrong ▸ If you see duplicate data between services, go back to the business ▸ Don't name a service until the end, names are misleading ▸ Don't work bottom up
13. WHAT HAPPENS AT Amazon IF... 1. 15% discount for a certain class of books? 2. A customer changes their shipping address? 3. The government changes the rate of GST? (assume GST applies to below AUD$1000)
14. WHAT HAPPENS AT a bank IF... You deposit a cheque and then view your bank balance?
15. SOLUTIONS FOR scale ▸ Design for maintenance upfront ▸ Design for upgrades Versioning is hard, technology won't save you ▸ Reuse is based on a fallacy
16. ROUND 'EM UP ▸ Don't think like an application developer anymore ▸ Think about business rule and data volality ▸ Data consistency rules ▸ Business modelling, not entity modelling
17. Fin :)
18. COUPLING together
19. SYSTEMS COUPLING 1. Platform coupling (interoperability) 2. Temporal coupling (synchronicity) 3. Spatial coupling (topology)
20. PLATFORM COUPLING ▸ Standards-based protocols to improve interoperability
21. TEMPORAL COUPLING ▸ caching ▸ split inter-service communications and handling (pub/sub versus request/response) ▸ manage consistency explicitly (acceptable "staleness") This is a business concern!
22. SPATIAL COUPLING ▸ delegate to something else eg messaging ▸ load balancing (at first logical, then physical)
23. COUPLING RULES ▸ Don't mechanically reduce all coupling. Zero coupling is impossible. ▸ Be concerned when we're breaking a pattern All code should be roughly the same quality.
24. THE NETWORK matters
25. FALLACIES OF NETWORKED COMPUTING ▸ The network is reliable ▸ There's no latency ▸ Bandwidth is unlimited ▸ The network is secure
26. FALLACIES CONTINUED ▸ The topology won't change ▸ Administrators will know what to do ▸ Transport is free ▸ Networks are homogeneous
27. Exeunt, stage left